python development practices?

[David Bolen]

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

> one doesn't have to be a rogue programmer to be enticed.  time
> pressures, schedule pressures, etc. can all force a good programmer to
> become one of the fallen.  if all the variables are hanging out, with
> no enforced privacy, it's much much easier/more tempting to start
> using them inappropriately in the code.  especially if it's just to
> get one quick feature in there for the demo, etc.  does this happen to
> other people, or is it just me?? :-)

One question that hasn't been raised in this thread is whether or not
this behavior can actually be beneficial too?

For example, let's say that an interface proves insufficient for a
need, and thus you bypass it for a quick feature for the demo.  In and
of itself, I don't necessarily consider that harmful - particularly if
it means you deliver your demo in the most expeditious manner.  Now of
course you need to revisit that post-demo (or release or whatever) and
refactor and/or clean up the interface, but that's going to be
generally true of an iterative or evolutionary development model
(which I think Python is well suited to).

So in some respects, being able to bypass a published interface when
necessary can be considered a positive and doesn't have to be a
negative.

If this continues to happen over time and is never revisited, could
you end up with a case where someone revisiting and changing a core
class breaks some of its users?  Sure.  But that can happen in various
ways even in more protected environments like C++, and so far in my
work, Python's openness in this regard has not proved a major issue.

> my question, all along, was not whether python works well when used
> with good development practice.  my question was to discover if there
> were any "safety nets" that other development teams might have erected
> for lapses in process.  if there are none, maybe we can think of some.
> if there are none because none are possible, then that's a different
> issue.

Or perhaps one of the reasons is that by and large those who have done
larger developments with Python haven't missed not having the safety
net, in which case the theoretical loss of protection being discussed
just hasn't turned into a major problem in practice.

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