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

[Steven D'Aprano]

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.)

(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

(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.

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.

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.

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.



> 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.



-- 
Steven.