Hello, I have found several posts of people (including Python commiters) asking for the removal of name mangling in Python, (the latest in 2006 in python-3000). I have searched in the various mailing lists and I can't find a clear status on this. If someone knows please let me know. Otherwise : I would like to propose this feature to be removed because it brakes Python philosophy imho. Regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/
On Sun, Feb 1, 2009 at 7:40 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
This could only be done in python 3000, and without 2to3 fixers (and smart ones at that) would break an insane amount of code.
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. I think if you find enough support, a PEP would need to be written up for this - it's a large enough change that we could not make it lightly. Not to mention if done in a 3.1 or 3.2 it would break compatibility with the older 3.xx releases (ergo, we'd need deprecation warnings and so on). Ultimately, I'm +1 on this but I'm wary of it too - it's a pretty big change and without some ability to lock down/hide a given method/variable or way of constructing "public interfaces" I think people in the community may be upset. Now, removing the name mangling but adding some way of declaring an interface into a module might be nice ;) jesse
On Sun, Feb 1, 2009 at 1:56 PM, Jesse Noller <jnoller@gmail.com> wrote:
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,
Yes, I am just throwing this here and that's a big piece of work indeed. If people are supporting this idea, maybe it can be suggested to Brett for dicussion at the Python Language Summit, (for the "'new features and future plans" part) http://us.pycon.org/2009/about/summits/language/
I would tend to think that properties are a good alternative for people that want to protect from external consumers. Tarek
On Dom, Feb 1, 2009 14:25, Tarek Ziadé wrote:
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 3:05 PM, Cesare Di Mauro <cesare.dimauro@a-tono.com> wrote:
And I can assure you that it wasn't rare having the need to access private members of some VCL component.
Hehe right. And the paradox is that most people I worked with were complaining about that and were still using private/protected parts in their own code. Just for the anectode since you are familiar with Delphi, my path to open source was : Delphi -> getting frustrated on expensive, closed components -> getting a taste of freedom with the Indy Components -> moving to Python and OSS
-- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/
On Sun, Feb 1, 2009 at 4:40 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
This is the first time I've heard of this request.
If someone knows please let me know.
AFAIK it's never been brought up on python-dev while we were discussing Py3k.
Otherwise : I would like to propose this feature to be removed because it brakes Python philosophy imho.
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. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Sun, Feb 1, 2009 at 5:30 PM, Guido van Rossum <guido@python.org> 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
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/
On Sun, Feb 1, 2009 at 1:40 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
Thanks for refreshing my memory. But the explanation below holds -- it should stay.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
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. 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. -- Steven
On Sun, Feb 1, 2009 at 2:29 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Of course. But that's several orders of magnitude easier to avoid, since classes are so much rarer than attributes.
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 <lists@cheimes.de> wrote:
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/
On Sun, Feb 1, 2009 at 7:40 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
This could only be done in python 3000, and without 2to3 fixers (and smart ones at that) would break an insane amount of code.
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. I think if you find enough support, a PEP would need to be written up for this - it's a large enough change that we could not make it lightly. Not to mention if done in a 3.1 or 3.2 it would break compatibility with the older 3.xx releases (ergo, we'd need deprecation warnings and so on). Ultimately, I'm +1 on this but I'm wary of it too - it's a pretty big change and without some ability to lock down/hide a given method/variable or way of constructing "public interfaces" I think people in the community may be upset. Now, removing the name mangling but adding some way of declaring an interface into a module might be nice ;) jesse
On Sun, Feb 1, 2009 at 1:56 PM, Jesse Noller <jnoller@gmail.com> wrote:
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,
Yes, I am just throwing this here and that's a big piece of work indeed. If people are supporting this idea, maybe it can be suggested to Brett for dicussion at the Python Language Summit, (for the "'new features and future plans" part) http://us.pycon.org/2009/about/summits/language/
I would tend to think that properties are a good alternative for people that want to protect from external consumers. Tarek
On Dom, Feb 1, 2009 14:25, Tarek Ziadé wrote:
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 3:05 PM, Cesare Di Mauro <cesare.dimauro@a-tono.com> wrote:
And I can assure you that it wasn't rare having the need to access private members of some VCL component.
Hehe right. And the paradox is that most people I worked with were complaining about that and were still using private/protected parts in their own code. Just for the anectode since you are familiar with Delphi, my path to open source was : Delphi -> getting frustrated on expensive, closed components -> getting a taste of freedom with the Indy Components -> moving to Python and OSS
-- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/
On Sun, Feb 1, 2009 at 4:40 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
This is the first time I've heard of this request.
If someone knows please let me know.
AFAIK it's never been brought up on python-dev while we were discussing Py3k.
Otherwise : I would like to propose this feature to be removed because it brakes Python philosophy imho.
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. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Sun, Feb 1, 2009 at 5:30 PM, Guido van Rossum <guido@python.org> 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
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/
On Sun, Feb 1, 2009 at 1:40 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
Thanks for refreshing my memory. But the explanation below holds -- it should stay.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
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. 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. -- Steven
On Sun, Feb 1, 2009 at 2:29 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Of course. But that's several orders of magnitude easier to avoid, since classes are so much rarer than attributes.
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 <lists@cheimes.de> wrote:
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/
participants (6)
-
Cesare Di Mauro -
Christian Heimes -
Guido van Rossum -
Jesse Noller -
Steven D'Aprano -
Tarek Ziadé