python development practices?

Richard Jones richard at bizarsoftware.com.au
Wed Oct 31 02:16:08 CET 2001


On Wednesday 31 October 2001 11:45, Peter Wang wrote:
> 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),

Investigate the use of unit tests. Not only can they check code compliance, 
but they also force you to define what code compliance is. Search the web for 
"extreme programming". There's some books about the subject too.


> and the lack of interfaces and strong types
> are the typical turn-offs,

Nah, they're just Old School concerns :)  Seriously, those mechanisms do help 
catch stupid bugs, but reliance on those issues can sometimes reduce the 
amount of time actually documenting the interfaces/components and testing 
them.


> in addition to the minor but omnipresent
> tab indentation issue. :-)

Any team environment will enforce a coding style. Indendation style is always 
a part of this. This is a dead herring.


> 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.

You've just got to move the interface and component specifications up from 
the code into documentation (where, IMO, it belongs.) and enforce component 
compliance with unit tests.


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

Programmers must be disciplined anyway, again IMO. This idea that programmers 
can just write whatever they damn well like, with little regard for what 
other people are diong (an idea propogated mostly by the "write it any damn 
way you like" ideology of Perl) is extremely detrimental to a working team.


> i'm eager to hear everyone's thoughts...

Well, there you have (some) of them, hope they help :)


    Richard




More information about the Python-list mailing list