python development practices?
pzw1 at cornell.edu
pzw1 at cornell.edu
Wed Oct 31 05:42:46 CET 2001
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
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
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. :)
More information about the Python-list