python development practices?

[Paul Rubin]

Peter Wang <pzw1 at cor-no-spam-nell.edu> writes:
> >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...

Yeah, it's better than nothing, but as I said, it's cheesy.  I tend to
have very few private variables.  If I want a bunch of variables I
make them attributes of a class instance, instead of class variables
_a, _b, and _c, I prefer to have just one variable _x, with attributes
_x.a, _x.b, and _x.c.  That helps some.

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

IMO a bunch of the frustration I sometimes feel with Python comes
from its originally being intended as a "glue" language.  It's too
good for that, and finds itself used as a work horse or even a race
horse.  Neither type of horse belongs in the glue factory ;-).

> >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 wrote a really simple assert-like function,

  def _check(condition, msg='check fails'):
    if not condition: raise SomeError, msg

and use it to enforce all kinds of conditions on input values, etc.
Semantically it's nearly a do-nothing but again, it feels much cleaner
than using if statements.  I have tons of these sprinkled through my code.

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

You might look at the actual code of big systems written in Python,
such as Zope, Twisted Matrix, etc.

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

Here's one that got some attention recently:
 http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html