python development practices?

[pzw1 at cornell.edu]

On Wed, 31 Oct 2001, Richard Jones wrote:

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

i think reliance on them is not a healthy thing, and in fact makes people 
too comfortable with not having a good development process.  however, 
they are really really really nice for catching dumb things like typos or 
a forgotten integer->string cast somewhere deep inside a rarely-executed 
bit of the code.  that's why i also asked about code coverage tools in 
the same breath. :-)

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

hmm.. this seems to be the uniform response to my questions, and it was 
what i had surmised before even posting.  is there really no middle 
ground?  are there no real development groups using python with high 
time-to-market pressures and imperfect process?  i find it hard to 
believe that someone or some group hasn't evolved a way of dealing with 
this...

i mean, i agree wholeheartedly with what you are saying, except that it's
much like having a car which is completely crashproof and extremely
fuel-efficient when tire pressure is maintained exactly, oil changed every
3,000 miles, and the dashboard is treated every 3 months with armor-all.  but
as soon as tire pressure dips 2 psi below spec, the engine explodes.  and
only when you drive down roads with a prime number of letters. 

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

oh, absolutely.  disciplined progammers are a must in any circumstance if one
is to even develop usable code.  but no one's perfect, and python is so
incredibly useful and powerful and elegant in so many cases that it's 
doubly grating on my sensibilities that the language isn't more of an 
ally in catching honest mistakes... 

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

thanks for your responses. :)

-peter