Private identifiers - naming

[Sridhar R]

In python, to hide (from direct access) identifiers from outsiders
(not current module), we usually prefix the variables with '__'.

But this is usually _difficult_ to read. Imagine a module (which is a
common one) containing more private variables than public variables.

How cryptic it would be to see text with lot of __ in front of them !!

Any thoughts?

 

[Heiko Wundram]

Am Donnerstag, 6. Mai 2004 16:00 schrieb Sridhar R:

Any thoughts?

If you find "__varname" difficult to read, don't use it. Python doesn't hide
(try a dir(<instance>)) or protect access to these variables anyway, so you
actually gain nothing using this syntax if it makes it cryptic for you.

The old argument: "We're all mature enough not to fiddle with data members
that are not of our concern, but rather use the interface the class defines
for us." And of course, if a class really wants us to not use a data member,
this can all be stated in the doc-strings for the class.

And, btw., I've actually found it rather helpful to have full access to
classes (as long as I know the source of the class), so that I can patch in
functionality that the author may have "forgotten" to implement...

Heiko.

 

[Yermat]

In python, to hide (from direct access) identifiers from outsiders
(not current module), we usually prefix the variables with '__'.

But this is usually _difficult_ to read. Imagine a module (which is a
common one) containing more private variables than public variables.

How cryptic it would be to see text with lot of __ in front of them !!

Any thoughts?

Do we really need private variable ?

 

[Peter Hansen]

Am Donnerstag, 6. Mai 2004 16:00 schrieb Sridhar R:


If you find "__varname" difficult to read, don't use it. Python doesn't hide
(try a dir(<instance>)) or protect access to these variables anyway, so you
actually gain nothing using this syntax if it makes it cryptic for you.

Actually, using __varname causes the compiler to munge the name so that
it is actually _ClassName__varname, to allow subclasses to use the same
name without stepping on the parent class' variable of that name. So
cryptic or not, you actually _do_ gain something if, for example, you
are trying to write a library for reuse and don't want to have to
document all the attributes which are used internally, just to make sure
nobody inadvertently defines a subclass which uses the same name and
buggers up the works.

It's not about _preventing_ such access, just protecting against
casual/accidental collisions.

-Peter

 

[Richard Taylor]

Do we really need private variable ?

One of the things I like about Python is that it places trust in the
programmer. No nasty compiler policeman telling me off when I break the
rules.

So the point of a 'private' variable is to indicate to the user of a class
that the author of the class did not intend it to be accessed directly.
Personally I tend to do this by appending a single '_' to method or
identifier names.

If a caller wishes to ignore my hint that they should not access such
variables/methods then that is up to them. This 'trust' in the programmer
often means that more use can be made of third-party packages because the
way that they are used can be 'bent' slightly by 'tweeking'. Experience has
taught me that the over zealous use of private/protected identifiers in C++
can made libraries much less flexible.

We are all adults here, no need for nasty police men.

Richard

 

[Richard Taylor]

Actually, using __varname causes the compiler to munge the name so that
it is actually _ClassName__varname, to allow subclasses to use the same
name without stepping on the parent class' variable of that name. So
cryptic or not, you actually _do_ gain something if, for example, you
are trying to write a library for reuse and don't want to have to
document all the attributes which are used internally, just to make sure
nobody inadvertently defines a subclass which uses the same name and
buggers up the works.

It's not about _preventing_ such access, just protecting against
casual/accidental collisions.

-Peter

If that is what you are trying to do then I would be explicit about it.

class C:
def method(self):
self._C_id = True

At least then it is clear what the identifier is called and a sub class that
'really' wants to mess with it can do so explicitly. Compiler name mangling
is a really pain for readability. Not every one will remember that the
compiler is doing it and sub class authors may become confused.

Better to use something like pychecker to pick up possible name clashes.

Richard

 

[John Roth]

In python, to hide (from direct access) identifiers from outsiders
(not current module), we usually prefix the variables with '__'.

But this is usually _difficult_ to read. Imagine a module (which is a
common one) containing more private variables than public variables.

How cryptic it would be to see text with lot of __ in front of them !!

Any thoughts?

The double underscore triggers name mangling, while a single
underscore is more of a hint that this variable is protected (rather
than private.)

My take on it is that if you have that many private variables,
maybe the class is too big and needs to be split into several
classes with clearer responsibilities.

There is also a school of thought that says that classes ought
to contain more private members than public ones, some
being more than none. I don't subscribe to it, but it's part of
the landscape.

John Roth

 

[A. Lloyd Flanagan]

Do we really need private variable ?

Probably not, assuming all our developers are competent. But it IS
very convenient to have a way to indicate what data attributes should
not be accessed, and __ is useful compromise between making them
totally hidden and making them too easy to modify.

I don't find it that hard to read, personally.

 

[Jacek Generowicz]

So the point of a 'private' variable is to indicate to the user of a class
that the author of the class did not intend it to be accessed directly.
Personally I tend to do this by appending a single '_' to method or
identifier names.

FWIW, "me too".