Will python never intend to support private, protected and public?

[Steve Holden]

Paul Rubin wrote:
> Dennis Lee Bieber <wlfraed at ix.netcom.com> 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/