python development practices?

[David Bolen]

Peter Wang <pzw1[nospam]@hotmail.com> writes:

> yes - one can't make sweeping generalizations about the pros or cons
> of breaking a published interface; it all depends on context.
> however, certain sorts of behavior will be more likely to end up
> biting you in the ass, and mucking around with the "private" data of a
> class is surely one of them.  even if one has to hack something
> together for a demo, i'd rather have things in the code which scream
> out, "touch this and all bets are off; hack something else!"  in some
> sense, the "private", "public", and "protected" labels signal this and
> much more.

But then you could run into the other cases mentioned in the thread
where you have to go to extremes in order to bypass those labels just to
get the job done in that case.  There are pros and cons on both sides.

> hm... maybe i'm being too much of a Murphyist. :)

I'm not sure it's so much of crying Murphy as much as Python tends to
create some discussions that often feel to me like I'm seeing a real
mix of theoretical and practical.  (And as a purist in many of my
development ideals, I can appreciate and often side with the theory).

That is, something about Python that isn't as strict or formal and can
raise theoretical concerns (whether at a language level or in
something larger like design methodology) gets discussed, and you can
just "feel" the theoretical side banging up against a practical or
pragmatic side.

I'm not totally convinced the ability to provide more isolation or
protection would be a bad thing, nor that there isn't room for
improvement in more standardized ways of defining and validating
interfaces.  But I do think that barring a perfect solution, I'd
prefer Python's openness and convention (based on experience to date)
than a more restrictive model.

And it does seem to be a particular sort of discussion that appears
from time to time regarding various features.

Although it's sort of strange - I do like very strong systems as well,
but it's almost like I want a system that is either completely open,
or extremely closed yet flexible. :-)

> yes, that is a distinct possibility and one that i'm willing to
> entertain.  on a purely personal level, i find myself much more
> productive and my code surprisingly less buggy when i use python.
> being able to code the algorithms is a big plus. :)

This is one of those "practical" things.  And I've gone through a few
myself.  I've mentally wrestled with thinking that indentation based
blocks must be problematic, or that strict compile time checks had to
be better even with unit or coverage testing, and yes, that not being
able to formally in the language make my stuff "black boxes" just had
to be bad.

But the more code I've written, and the easier I've found it to reuse
(even stuff not intended for use as a component, and yes even
sometimes during reuse deciding to use something not originally
intended as part of the interface), and the robustness of the
resulting code continues to inspire confidence.  For example, we've
had a fairly complex 7x24 scheduling system running here for just
about a year now that was up and running originally after a month or
two of work, and to be honest has been fantastically reliable from my
perspective given the timeframe, needed capabilities and continued
evolution of it over time.  I just know it's orders of magnitude
better (resources needed, flexibility, ability to evolve) than what I
would have come up with using something like C++.  To be fair it was
primarily a single developer effort so it doesn't quite fit into this
thread, but I'm comfortable with it's capability to be maintained and
worked on by others even under Python's structure.

> cool, you work at fitlinxx!  my girlfriend Co-op'ed there a year ago.
> do you remember a Crystal Soja?  i recall her mentioning that there
> was an effort to use python there - i take it you were part of that?

Yes to both.  Luckily (unlike some others that have been posted here),
I happen to be top of the technical food chain here so I only had to
convince myself that Python was worth using :-)

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/