python development practices?

[Peter Wang]

On 30 Oct 2001 17:11:28 -0800, Paul Rubin <phr-n2001d at nightsong.com>
wrote:

>Peter Wang <pzw1 at cor-no-spam-nell.edu> writes:
>> 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.
>
>Well, there's cheesy data hiding in the sense that instance variables
>whose names begin with underscores are difficult to reach from other
>modules.  

well... kind of.  but short of naming all my private variables "_foo"
and hacking around the problem, there's no way to prevent lazy
programmers from touching all of your classes's data members.  i know
this is not python's paradigm, but OTOH this is something that has to
be dealt with in a production environment...

as an aside, and i don't mean to sound obnoxious, but why did guido
not put in data hiding into python at an earlier stage?  my colleague
whose background on generic programming comes entirely from the STL
points this "wart" out as one of python's largest, and brings up the
good point that data hiding was well known to the OOP world at the
time of python's first incarnations.

>If by "interfaces" you mean Java-like interfaces, that's a bogus
>criticism since Python supports multiple base classes, which let
>you do the same things and then some.

nope, didn't mean Java interfaces.  just meant some clean way to
define contracts between callers and functions.  static typing is an
interface mechanism.  if python had an elegant language-level
construct for defining basic contracts, it would be a boon to (1)
compile-time debugging and (2) design by contract in python.

i've read the interfaces PEP and that seems like a nice way to do it
at the class level, but almost seems too heavyweight for "basic"
types.  or, in light of "classes are types are classes", there doesn't
seem to currently be a lightweight way to say "this is a list-like
item" or "this is an INT-like item".  one could fiddle with proxies
and such to achieve the effect, but that's the difference between a
language *allowing* a feature versus *providing* a feature.

>I agree with the criticism about the tool environment, and would also
>have to say the runtime library isn't what I'd call "industrial strength".

actually that was the least of my worries. :-)  if could just
guarantee code coverage on the stuff i write, i'd be happy!  i have to
be honest: i haven't done much with trace.py or pylint.  but my
original question was much more about development practices with
python: coding specs, docstring conventions, module import rules, etc.
i can read PEPs and documentation as well as the next guy, but
development practices - there, i haven't got a clue.

>> how do Python development teams get around these issues?  does using
>> Python in a commercial software team simply require more disciplined
>> programmers?
>
>> are there good references on using Python in a commercial, team
>> development environment?
>
>I don't know about Python, but large systems have been built in Lisp,
>and there have been some studies too.  Lisp's runtime semantics are
>fairly similar to Python, though the development environments are
>far more highly evolved.

can you point me to some of these studies?  or at least a list of
google keywords? :-)

-peter