Peter Wang <pzw1@[...].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
-- 
http://mail.python.org/mailman/listinfo/python-list