python development practices?

[John Roth]

"Peter Wang" <pzw1 at cor-no-spam-nell.edu> wrote in message
news:e1iuttghajb226flvq9jr07ddq229tki38 at 4ax.com...
> are there good references on using Python in a commercial, team
> development environment?
>
> i have been advocating and slowly convincing various people in my
> company to use Python.  i've successfully used it to write a few tools
> and an application.  however, the general perception is that it is a
> good scripting language and possibly acceptable for single-person
> development use, but it doesn't afford use in a large-scale software
> team.  the lack of data hiding, the lack of data coverage tools
> (pre-run-time linting), and the lack of interfaces and strong types
> are the typical turn-offs, in addition to the minor but omnipresent
> tab indentation issue. :-)
>
> while i feel that Python makes me far more productive as a programmer
> for all the projects on which i've worked, i'm inclined to agree that
> the lack of data hiding coupled with lack of a standard interface
> specification would cause problems in a team.

IMHO, the data hiding issue is a red hering. If there's someone on the
team where you absolutely need private variables to keep them honest,
you've got lots greater problems than the choice of language. In python,
if you don't want to export a variable or method, simply prefix it with
an underscore. This will tell anyone who really cares that it's private,
and if it's used outside, then the code needs to be refactored.

There's a PEP outstanding for interfaces, and I presume that it will
be seriously considered for 2.3. In any case, if you really need
interfaces, it's possible to write one in Python, although it wouldn't
look very pretty.

As far as causing problems in a team environment, the eXtreme program
folks at comp.software.extreme-programming like python - and that
development methodology carries team orientation to an eXtreme.

I'm not sure what you mean by 'data coverage tools.' If you mean a
code coverage tool to check whether the unit tests cover everything,
look on the Vaults of Parnassus. PyCover is acceptable, although it
could
use a bit more work.

There's also some code inspection tools, but I don't remember the name.

Tab versus space indentation is simply a matter of setting team
standards.
If you want to be very anal about it, you can always set up an
enforcement
mechanism at code checkin, when you insure that all your unit tests run
to 100%. You do that, don't you?

> how do Python development teams get around these issues?  does using
> Python in a commercial software team simply require more disciplined
> programmers?

Programming requires discipline. Period. If you're depending on a
compiler
to catch sloppy thinking, then you've got trouble.

John Roth