Paul Rubin wrote:
> Dennis Lee Bieber <[EMAIL PROTECTED]> writes:
>
>> Ah, but in the way of your code -- it is not "your car"... It is the
>>car you supplied to someone "hundreds of miles away"... And they are
>>perfectly free to open the hood... tamper with the engine programming, etc.
>
>
> I don't understand what you're getting at. If they're free to edit
> the code, then why should they complain about private variables? They
> can change the declaration if they need to.
Similarly they can rewrite it in Perl if they don't like it being in
Python. So what? Most people have *zero* interest in looking behind the
interface of the code they use, whether it's an API or a GUI.
Effectively this whole thread seems to have become an argument about
what kind of boxes you can have around namespaces. For the vast majority
who don't care the discussion will seem a little academic.
Should namespaces be protected? The lazy Pythonista's answer to that
question is:
>>> import os; f = os.popen("python -m this")
>>> for l in f:
... if "namespaces" in l.lower().split(): print l[:-1]
...
Namespaces are one honking great idea -- let's do more of those!
>>>
[note that my laziness extends to the gratuitous introduction of a
separate process to produce the source data. Can I claim extra points
for that?]
So it should come as no surprise to anyone that namespaces appear in
many contexts in Python. So, why this sudden urge (you may wonder, if
you don't think much about code purity) to have "private" and its
buddies. The security police have arrived, and you can be pretty sure
nothing much is going to be fun from here on in.
Think about it: we have a language that has an eval() function and an
exec statement, and people are concerned that some service consumer
shouldn't be allowed to go poking around inside namespaces? What do we
have to do, put up signs saying "do not stab yourself with a knife"? If
people want control without discipline (which is effectively what
private and the like purport to do) then Python just may not be your
language ...
Access to another object's namespace is almost invariably all-or-nothing
in Python, which (it should not be overlooked) has introspection
capabilities. With this ability to poke around in the bowels of the
system to perform deep magic comes a corresponding responsibility: don't
abuse the privilege, and behave in a disciplined (sort of) way.
To avoid naming conflicts, Python provides a mechanism (name mangling)
which pretty much guarantees that your names won't conflict with anybody
else's, *even if you subclass a class whose methods use the same name*.
This was a thoughtful addition, widely ignored by experienced
programmers. It was never intended to stop people from poking around
under the hood - simply to ensure that you wouldn't *accidentally* start
poking around under the hood of a parent class's implementation because
of a name clash.
C++ and cronies are not introspective languages (Java is and, like
Python, can mess about with its own workings; because of Java's many
constraints this turns out to be much less fun than in Python, but of
course Jython will give you access to many useful Java resources in a
much saner context) and non-introspective programmers frequently recoil
in horror when faced with the prospect of losing the training wheels :-)
Given the denizens of this particular list/newsgroup I am sure I will be
bombarded by a host of ways I could have produced the output of "import
this" without creating a new process. So, to try and forestall various
further expansions of this thread, let me produce a FAQ (which is
clearly quite bogus, since I am still writing it) for this post.
Q: It's inefficient to start another process.
A: When I need to do it six million times a second I'll remember that.
This was a one-off example. I have already wasted more time
discussing this issue than I would have saved in the first
thousand runs of a rewrite.
Q: It isn't cross-platform.
A: Well it runs on Windows, Cygwin and Linux, so it doesn't do badly.
Q: You could have done it some other way.
A: Please get over this obsession. There will always be more than
one way to do most things despite the output from a simpler (but
non-portable) solution
$ python -m this | grep way
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Note that word "obvious": nobody says you *have* to do things the
obvious way.
Q: Are you Dutch or something?
A: No such luck. But I'm not Belgian either :-)
a-voice-said-smile-things-could-be-worse-so-i-smiled-and-sure-enough-things-got-worse-ly
y'rs - steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
--
http://mail.python.org/mailman/listinfo/python-list
