python development practices?

[Peter Wang]

On Wed, 31 Oct 2001 16:33:08 +1100, "Darren Collins"
<collinda at nortelnetworks.com> wrote:

>> i don't think data hiding's purpose is to keep rogue programmers in
>> line.
>...
>> ... since the entire code of the class is
>> exposed (unless you split off a portion of it into a hidden base
>> class), it's doubly enticing to use stuff you're not supposed to.
>>
>I don't follow your reasoning here. These statements seem contradictory to
>me.

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?? :-)

>If people can see that something is supposed to be private, but they
>absolutely need access to it, then they have just discovered an interface
>problem. They can either fix the interface or put a quick hack in their code
>to to work around it by accessing the 'private' member. But they put in the
>hack knowing that they are breaking the original designer's intentions, so
>they're on their own. It is nice that you can do this when you really need
>to, though.

i guess my problem is that "they're on their own" is just not a good
enough answer.  they're not on their own; they've screwed the whole
team.  maybe we should fire them.  but they're not malicious - see the
distinction between rogue and "fallen" programmers above.  the nasty
side effects could be buried deep in the code and fail in subtle and
mysterious ways, and short of truly exhaustive system regression
tests, there is no safety net for the team and the whole product.

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.

i've been getting a lot of "there aren't any because you need good
development practices" answers, which seems equivalent to "this car
doesn't have airbags because you should wear your seatbelts".  in the
long term this is good because it forces people to wear seatbelts,
but it doesn't answer the question about how we save the ones that
don't.


-peter