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

[Antoon Pardon]

Op 2005-09-30, Steven D'Aprano schreef <steve at REMOVETHIScyber.com.au>:
> On Fri, 30 Sep 2005 07:37:14 +0000, Antoon Pardon wrote:
>
>> Well I have the following reasons not to like the current python way:
>> 
>> 1) Beginning all your private variables with an underscore is like
>> starting all your integers with an 'i' or all your dictionary with
>> a 'd' etc.
>
> Three points:
>
> (1) It is utterly pointless in a statically typed language like C to name
> integer variables starting with an i, because both you and the compiler
> already know it is an integer. However, in a dynamically typed language
> like Python, it may in some circumstances make sense, since you have no
> other clue as to the expected type of object a variable has.
>
> (Descriptive names like "arglist" are better, but when the descriptive
> name is ambiguous, or there is no sensible descriptive name, this
> convention can be helpful.)

I don't think such a convention is that helpfull. 

> (2) Hungarian notation wasn't supposed to be about starting integer
> variables' names with an i, that was a misunderstanding of the Microsoft
> OS division. See here for further details:
>
> http://www.joelonsoftware.com/articles/Wrong.html

Nice article and I think such conventions are indeed very helpfull,
but we are not talking that kind of convention here. Take a statement
like below:

  _var1 = var2

You can't infer that this is wrong because one starts with an '_'
and the other doesn't.

> (3) Let's do a small thought experiment. Suppose that Python introduces
> "real" private variables. Now that Python has private variables, tens of
> thousands of C++ and Java developers immediately rush to use Python in
> huge collaborative projects. You're working on one of these huge projects,
> and reading the source code to a class that takes 45 pages for its
> definition. You're on page 33, and you see these lines:
>
>     # cache the expensive lookup for extra speed
>     usercache = self.longcomplexcalculation()
>
> "Ahah!" you say to yourself, "That's exactly what I need to make my code
> run faster. Instead of calling Klass.longcomplexcalculation() every time I
> need it, I can just look at usercache."
>
> Quick: was usercache a private variable? How can you tell, short of
> searching through those 45 pages of code? You can't.

What's the problem, my editor will find that soon enough.

> Of course, in real Python, as soon as you see _usercache with a leading
> underscore, you know it is a private variable, and you don't have to
> search the source code to find out. So that's an advantage to the
> existing Python system.

But you don't know if it is a private variable of this module or a
private variable imported from another module. So you don't know
if it is something that you can touch freely but clients should
be cautious about or something you should be cautious about.

So take a module with tens of private variables, which are
the one that are imported and which are the local ones. You can
search all those pages too.

> It seems to me that much of this argument is about terminology, not
> reality. We've made a mistake in describing Python as "not having private
> variables, only semi-private by convention". Bad bad bad. 
>
> What we should have said is that Python DOES have private variables. In
> the same way that Python forces you to use a consistent indentation
> scheme, Python forces you to name all your private attributes with a
> leading underscore. And just like C++ lets you sneakily access private
> variables by defining private as public, so Python lets you sneakily
> access private variables by mangling the name.

But private variable are not mangled. Just putting one underscore is
apparantlty enough to flag a variable a private, but you need two
starting underscores for name mangling. At least that is how I
understand:

http://www.python.org/doc/2.2.3/tut/node11.html#SECTION0011600000000000000000

> Then we'd all be happy, the language zealots would take note that Python's
> implementation of private variables has a gotcha to watch out for, and
> we'd all be happy.
>
>
>> 2) The editor and font I use make it hard to see underscores. They
>> usually seem to belong more to the line below than to the actual
>> lines.
>
> That's a bug in the editor/font combination. I've seen some versions of
> Abiword cut off the bottom pixel from lines, including underscores. If
> your editor made y look like v or u, you'd call it a bug, and if it makes
> an underscore disappear or look like part of the next line, that's a bug
> too. (Just like Ariel has the bug that the letters r n together look like
> the letter m. darn vs dam.

IMO that an underscore looks like it belong to the next line is not a
bug. An underscore doesn't belong to this line, it belongs under it.

>> My idea as somekind of compromise between what happens in languages
>> like C++ and currently in python would be the following:
>> 
>> 1) Allow keywords like private (or implemetation) to mark certain
>> variables, functions or classes as an implementation detail.
>> Personnally I would prefer the opposite such as a interface
>> to mark objects which are not private, but that would break too
>> much code.
>> 
>> 2) Allow the client access to these private variables, through
>> a special construct. Maybe instead of "from ... import ..."
>> "from ... spy ...".
>
> What you are suggesting is that you have private variables that are only
> private by convention, since anyone can simply call use spy to treat
> them as public. In other words, no different from what Python already
> does, except it avoids underscores and introduces at least one new keyword
> (spy) and one new syntax element (something to flag a variable as private).
>
> Yeah, that will make a huge difference.

IMO this convention doesn't make sense, because it doesn't distinghuish
between private variables of this module, which the developer is freely
to use however it fits and private variables from other modules you
should be cautious about. With my suggestion it would be easier to
use a convention like:

  from module spy var as _var


This would would make the '_' much more usefull as a flag, because it
would now stand for an imported private variable.

-- 
Antoon Pardon