python development practices?

[Hung Jung Lu]

Peter Wang <pzw1[nospam]@hotmail.com> wrote in message news:<6YLfO=JIhU1VpcRCSlWyV5uJY4mq at 4ax.com>...
> i don't think data hiding's purpose is to keep rogue programmers in
> line.  it's partly to insulate imperfect development practice (e.g.
> sloppy documentation) and partly to define an interface for a class.
> someone else made the point that this is the purpose of documentation,
> which should be kept up to date; i agree but people will invariably
> look at code, and with python, 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.

It really depends on each person's own experience. I must say that I
hated C++'s data hiding (the 'private' keyword). In a team
environment, if someone hides data, you are at his/her mercy. This is
a really life story: what if a few days before shipping your product,
you need to modify the functionality of a class that is written by
someone else, but you can't access the hidden data? What if the person
that wrote the code is unreacheable (busy with something else)? As you
may well known, in commercial productions, each person's code is
untouchable by others (Source Safe), and some components are not even
in code, but in the form of compiled library. What do you do? In C++,
you are doomed, unless you resort to really dirty tricks. You can
guess what I did: pointer tricks, I basically pried open all private
data members, by force. Luckily the same trick worked for PC and for
Mac, and the product shipped fine.

Python allows you to patch existing codes. Even dynamically. Imagine
your product depends on third-party codes, and there are problems/bugs
with the third-party codes. What do you do? You file a bug report to
the original authors, but you have to wait a few weeks/months before
they release a new version. Do you want to dig into their code and
modify it? I don't think so, because if you accidentally install their
package again, all your changed are gone. What you want to do is write
a dynamic patch to their code, in your own code space (in your files).
Because you have access to all data, you can check conditions on when
to apply the patch, so when a new version come out, you automatically
stop applying the patch. You can see that Python, because it does not
enforce data hiding, actually often insulate you better from code
changes of other people.

I don't think data hiding at the language level is a good thing.
Really. The only valid rationale is to prevent name collision, which
in Python you can do with a leading underscore. And for your
information, the old place where I worked actually uses the same
convention (leading underscore) for private data members in C++/Java,
and they did not know Python. I've used initial underscore ever since.
Believe me, it's a good notation.

Data hiding is necessary for security issues. But my personal belief
is that this kind of petty security issues should not be part of a
programming language itself (it does not work, anyway, because in C++
you can access all data members, private or otherwise, via dirty
tricks.) There are other ways of addressing security concerns, at a
higher level. It's denigrating to programmers not to be able to do
things at the language level.

> interface isn't fully spec'ed out.  and the guy who wrote the code is
> out of town for a week.  

This is the time that you'll be REALLY grateful that you are using
Python instead of Java or C++.

Hung Jung