prefer Python for new scripts?

[Tom Yu]

I propose that we move toward preferring Python for new scripts in the
source tree.  Scripts in our tree are written in many languages,
including Python, Perl, Tcl/Expect, Bourne shell, and others.

Anecdotal evidence suggests that it is easier to write maintainable
Python code than maintainable Perl code, and that newcomers find
Python an easier language to learn than Perl.

I'm not suggesting that we rewrite all our scripts in Python, just
that we prefer it in the future.  Reasons to not choose Python for new
work would include extending existing scripts, etc. that are written
in another language.  For example, the Tcl/Expect/Dejagnu testing
frameworks we have are somewhat cumbersome, and I plan to replace them
with something more consolidated, but any modifications or extensions
to them should still be written in the currently used Tcl/Expect
language.

I have looked at a Python-based testing framework called QMTest, which
appears somewhat promising, as a replacement for Dejagnu.  It hasn't
had a release since 2007, but this is not inherently a bad thing.

Please provide feedback on these suggestions.  Thanks.

--
Tom Yu
Development Team Leader
MIT Kerberos Consortium
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Zhanna Tsitkova]

You have my vote, of course.
Also, back in February, when I initially proposed Python for our testing framework, we discussed what version of Python should be used - 2.3, 2.5 2.6 or 3.0 - and the question is still open. I prefer 2.6+ and would not go below 2.5.
Any strong preferences with regard to version choice?

Thanks,
Zhanna

 
________________________________________
From: krbdev-bounces@... [krbdev-bounces@...] On Behalf Of Tom Yu [tlyu@...]
Sent: Thursday, October 29, 2009 11:32 PM
To: krbdev@...
Subject: prefer Python for new scripts?

I propose that we move toward preferring Python for new scripts in the
source tree.  Scripts in our tree are written in many languages,
including Python, Perl, Tcl/Expect, Bourne shell, and others.

Anecdotal evidence suggests that it is easier to write maintainable
Python code than maintainable Perl code, and that newcomers find
Python an easier language to learn than Perl.

I'm not suggesting that we rewrite all our scripts in Python, just
that we prefer it in the future.  Reasons to not choose Python for new
work would include extending existing scripts, etc. that are written
in another language.  For example, the Tcl/Expect/Dejagnu testing
frameworks we have are somewhat cumbersome, and I plan to replace them
with something more consolidated, but any modifications or extensions
to them should still be written in the currently used Tcl/Expect
language.

I have looked at a Python-based testing framework called QMTest, which
appears somewhat promising, as a replacement for Dejagnu.  It hasn't
had a release since 2007, but this is not inherently a bad thing.

Please provide feedback on these suggestions.  Thanks.

--
Tom Yu
Development Team Leader
MIT Kerberos Consortium
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Tom Yu]

Zhanna Tsitkova <tsitkova@...> writes:

> You have my vote, of course.
> Also, back in February, when I initially proposed Python for our testing framework, we discussed what version of Python should be used - 2.3, 2.5 2.6 or 3.0 - and the question is still open. I prefer 2.6+ and would not go below 2.5.
> Any strong preferences with regard to version choice?

I think our minimum Python version requirement should be based on
whatever versions ship with operating systems we care about.  For
example, Mac OS 10.5 ships with 2.5.1; Debian-stable ships 2.5.2; RHEL
4 ships 2.3, I think, which has been problematic in the past
(Linux-Athena 9.4 was based on RHEL 4, but that is quite ancient at
this point.); RHEL 5 ships 2.4.x: not sure how much people still care
about that.  I'm not sure what ships on modern releases of Solaris,
but the Solaris 10 (3/05?) box I'm using has Python 2.3.3.

Scripts that are required in the build process but not in the test
suite should require lower versions of Python, to be friendlier to
non-developer users and sysadmins who are building from source.  (Note
that we currently already require Perl for the build process.)

Given that much of my current work environment is on Mac OS 10.5, I
would be biased toward using Python 2.5 as a minimum, but may update
my opinion based on additional information about what Python versions
various operating systems ship.
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Jeffrey Altman-2]

Using python permits you to use buildbot.

One of the challenges of using python is finding a version that works on
all of the platforms and applications that you require.  If you care
about Windows you have 32-bit support for just about any version from
2.4 through 3.0.  64-bit support on the other hand is only available for
2.6 and 3.0.   If I remember correctly some of the buildbot dependencies
require 2.5.

Jeffrey Altman


Zhanna Tsitkova wrote:

> You have my vote, of course.
> Also, back in February, when I initially proposed Python for our testing framework, we discussed what version of Python should be used - 2.3, 2.5 2.6 or 3.0 - and the question is still open. I prefer 2.6+ and would not go below 2.5.
> Any strong preferences with regard to version choice?
>
> Thanks,
> Zhanna
>
>  
> ________________________________________
> From: krbdev-bounces@... [krbdev-bounces@...] On Behalf Of Tom Yu [tlyu@...]
> Sent: Thursday, October 29, 2009 11:32 PM
> To: krbdev@...
> Subject: prefer Python for new scripts?
>
> I propose that we move toward preferring Python for new scripts in the
> source tree.  Scripts in our tree are written in many languages,
> including Python, Perl, Tcl/Expect, Bourne shell, and others.
>
> Anecdotal evidence suggests that it is easier to write maintainable
> Python code than maintainable Perl code, and that newcomers find
> Python an easier language to learn than Perl.
>
> I'm not suggesting that we rewrite all our scripts in Python, just
> that we prefer it in the future.  Reasons to not choose Python for new
> work would include extending existing scripts, etc. that are written
> in another language.  For example, the Tcl/Expect/Dejagnu testing
> frameworks we have are somewhat cumbersome, and I plan to replace them
> with something more consolidated, but any modifications or extensions
> to them should still be written in the currently used Tcl/Expect
> language.
>
> I have looked at a Python-based testing framework called QMTest, which
> appears somewhat promising, as a replacement for Dejagnu.  It hasn't
> had a release since 2007, but this is not inherently a bad thing.
>
> Please provide feedback on these suggestions.  Thanks.
>
> --
> Tom Yu
> Development Team Leader
> MIT Kerberos Consortium
> _______________________________________________
> krbdev mailing list             krbdev@...
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
> _______________________________________________
> krbdev mailing list             krbdev@...
> https://mailman.mit.edu/mailman/listinfo/krbdev
>

_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Simo Sorce]

On Thu, 2009-10-29 at 23:32 -0400, Tom Yu wrote:

> I propose that we move toward preferring Python for new scripts in the
> source tree.  Scripts in our tree are written in many languages,
> including Python, Perl, Tcl/Expect, Bourne shell, and others.
>
> Anecdotal evidence suggests that it is easier to write maintainable
> Python code than maintainable Perl code, and that newcomers find
> Python an easier language to learn than Perl.
>
> I'm not suggesting that we rewrite all our scripts in Python, just
> that we prefer it in the future.  Reasons to not choose Python for new
> work would include extending existing scripts, etc. that are written
> in another language.  For example, the Tcl/Expect/Dejagnu testing
> frameworks we have are somewhat cumbersome, and I plan to replace them
> with something more consolidated, but any modifications or extensions
> to them should still be written in the currently used Tcl/Expect
> language.
>
> I have looked at a Python-based testing framework called QMTest, which
> appears somewhat promising, as a replacement for Dejagnu.  It hasn't
> had a release since 2007, but this is not inherently a bad thing.
>
> Please provide feedback on these suggestions.  Thanks.

Unfortunately right now python is going through a transition phase.

In theory using 2.6 carefully should allow you to use the code with 3.0
later with minimal or no changes.
Using anything below 2.6 may require to migrate scripts later on.
I guess what will really drive your choice is going to be dependencies
anyway. Btw if someone would go and contribute to enhance krb5 python
bindings that would be awesome :-)

Simo.

--
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

I like Python.

I may set up Buildbot at some point to replace the ad hoc nightly test
framework Ken set up.  Time permitting, I may also work on Python
support for system tests (similar to what we have in tcl--the ability to
easily set up and tear down Kerberos environments to run test cases in).
I don't think there's a Python equivalent of "expect", so in a few cases
we might need to beef up programs to accept passwords from sources other
than the controlling terminal, if we don't have support for that
already.

I am not too worried about the 3.0 transition.  I suspect Python 2 will
be with us for a number of years.  However, I would suggest we avoid
runing Python scripts during the build unless we can be very minimal
about the version requirements.  For developer scripts (run during
distro-prep, or the test suite, or by hand) I'm tentatively okay with
using Python 2.5 as a minimum, although I'd like to know if we have any
developers who regularly use an OS which ships Python 2.4.  Some of the
Python 2.5 features look fairly nice (like conditional expressions) but
none of them look like must-haves.


_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Jeffrey Hutzelman]

--On Friday, October 30, 2009 12:21:36 PM -0400 Greg Hudson
<ghudson@...> wrote:

> However, I would suggest we avoid
> runing Python scripts during the build unless we can be very minimal
> about the version requirements

Or preferably, not at all.
Perl is _probably_ sufficiently widely deployed that requiring it for the
build is OK, and apparently it hasn't been a problem for Kerberos, but my
preference in the long run is to avoid even that.  If something is too
complicated to be done in sh, then chances are it doesn't need to be done
as part of the build, and if it does, maybe it's a candidate for a C
program.

For tests, I'd relax that a bit.  It ought to be possible for anyone
building Kerberos to run the tests (modulo cross-compiling), but I think
it's OK to require them to have a reasonably new perl and/or python first.
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Ezra Peisach]

Greg Hudson wrote:

> I like Python.
>
> I may set up Buildbot at some point to replace the ad hoc nightly test
> framework Ken set up.  Time permitting, I may also work on Python
> support for system tests (similar to what we have in tcl--the ability to
> easily set up and tear down Kerberos environments to run test cases in).
> I don't think there's a Python equivalent of "expect", so in a few cases
> we might need to beef up programs to accept passwords from sources other
> than the controlling terminal, if we don't have support for that
> already.
>
>  

I found pexpect  ( http://pexpect.sf.net or
http://www.noah.org/wiki/Pexpect )  - is a pure python version of expect
interface... According to the FAQ:


      Q: Isn't there already a Python Expect?

A: Yes, there are several of them. They usually require you to compile
C. I wanted something that was pure Python and preferably a single
module that was simple to install. I also wanted something that was easy
to use. This pure Python expect only recently became possible with the
introduction of the pty module in the standard Python library.
Previously C extensions were required.


So - we could distribute Pexpect...  (like krb5 use to distribute
autoconf)...

The pty module appears to exist as far back as python 2.3.3.. Although I
cannot say how buggy the older implementations are.... Pexpect is
written and tested w/ Python 2.5.

Licensing of pexpect looks ok... (but someone else should check)...


Ezra

_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Sam Hartman]

>>>>> "Tom" == Tom Yu <tlyu@...> writes:

    Tom> I propose that we move toward preferring Python for new
    Tom> scripts in the source tree.  Scripts in our tree are written
    Tom> in many languages, including Python, Perl, Tcl/Expect, Bourne
    Tom> shell, and others.

I definitely think that we should encourage people to write maintainable code.

However I also think that we should encourage people to write tests
etc.  I'd much rather see people actually write test scripts in
whatever language they are familiar with than not write scripts.

I think that if people focus on writing modular code, that my personal
recommendation is that we probably don't need a global recommendation
like this.

I definitely think that using Python is fine.  I also think that
moving away from the existing dejagnu tests would improve
maintainability.

--Sam
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Ezra Peisach]

On 11/03/2009 11:53 AM, Sam Hartman wrote:
>
> I definitely think that using Python is fine.  I also think that
> moving away from the existing dejagnu tests would improve
> maintainability.
>
> --Sam
> _______________________________________________
>    

One of the challenges with dejagnu is getting it to run with the test
suite... Sometimes the fault is dejagnu, sometime expect. Under Fedora
9/10/11 expect has issues with the newer tcl and dynamic loading of the
clock module... I have to use a static compiled version of expect with
an older tcl version to avoid the problem...
So - if someone could write the equivalent in python that is standalone
w/o esoteric software being installed  - I am all for it...

Ezra
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev