On Dom, Feb 1, 2009 14:25, Tarek Ziadé wrote:

On Sun, Feb 1, 2009 at 1:56 PM, Jesse Noller wrote:

...

I think though - there's would be a fair amount of outcry due to this from the userbase/people looking at the language. Some people simply want the ability to hide things within their modules/classes/etc from the external consumers - this makes sense if you approach things from the JWODT (Java way of doing things), privacy of internal methods/variables is "key" to a clean and stable API.

That's the first thing that surprised me when I started Python, since I came from Delphi where private and protected attributes were a religion back then,

In Delphi (like many other languages, such as C++, Java, etc.) protected members aren't really protected. You can always use class crackers to gain full (public-like) access to them. It's a pretty common practice, and everyone that have built components has surely used it at least one time. Access control can be a good thing on paper, but leaves everything on the designer's hands. So if he makes a mistake design the class, you can be out of business. If you are lucky, the members are protected and you can always crack them, but when they are private, you can only give up or rewrite the class yourself: not a beautiful prospect. And I can assure you that it wasn't rare having the need to access private members of some VCL component. So, if access control can be a matter of religion, men must have the freedom to decide whatever they want to do with classes. Like Python does. ;) Cheers Cesare

On Sun, Feb 1, 2009 at 1:40 PM, Tarek Ziadé wrote:

On Sun, Feb 1, 2009 at 5:30 PM, Guido van Rossum wrote:

...

This is the first time I've heard of this request.

The most recent one is here I think : http://mail.python.org/pipermail/python-3000/2006-September/003857.html

Thanks for refreshing my memory. But the explanation below holds -- it should stay.

...

I'm against removing it. While the "privacy" it offers is marginal, it also offers protection against accidental clashes between attribute names. E.g. consider person A who writes a library containing a class A, and person B who writes an application with a class B that subclasses A. Let's say B needs to add new instance variables, and wants to be "future-proof" against newer versions of A that might add instance variables too. Using name-mangled variables gives B a "namespace" of his own (_B__*), so he doesn't have to worry about clashes between attribute names he chooses now and attribute names that A might choose in the future. Without name-mangling, B would have to worry that A could add private variables with clashing names as well -- in fact, the presence of any private variables in A would have to be documented in order to ensure that subclasses wouldn't accidentally clash with them, defeating the whole purpose of private.

Right, thanks for the explanation,

I found back a thread where it has been discussed already so I'll study it

http://mail.python.org/pipermail/python-dev/2005-December/058555.html

Regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Sun, Feb 1, 2009 at 2:29 PM, Steven D'Aprano wrote:

...

E.g. consider person A who writes a library containing a class

A, and person B who writes an application with a class B that subclasses A. Let's say B needs to add new instance variables, and wants to be "future-proof" against newer versions of A that might add instance variables too. Using name-mangled variables gives B a "namespace" of his own (_B__*), so he doesn't have to worry about clashes between attribute names he chooses now and attribute names that A might choose in the future. Without name-mangling, B would have to worry that A could add private variables with clashing names as well -- in fact, the presence of any private variables in A would have to be documented in order to ensure that subclasses wouldn't accidentally clash with them, defeating the whole purpose of private.

Just for completeness sake, I'll point out that there is still a possible name clash using name-mangling: if you subclass B, and inadvertently name your subclass A (or any other superclass of B), then your __names may clash with A's __names.

Of course. But that's several orders of magnitude easier to avoid, since classes are so much rarer than attributes.

I don't particularly like name-mangling, but I don't see it is a large enough problem that it needs to be removed, particularly in the absence of any viable alternative.

I usually recommend against it (in favor of a single underscore), but there are a few situations where it is really useful. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Sun, Feb 1, 2009 at 5:45 PM, Christian Heimes wrote:

In my opinion the removal of the feature is going to create too much pain. The name mangling just causes a minor unpleasantness for newbies. Is it really a big deal in your opinion?

No I guess people can live with it. And if it's too much pain to remove, it sounds right not to do it I guess. It seems to make sense for mixins, but that is not a pattern I am using at all; Regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/