On 12/11/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 12/11/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > Keeping it for Py3K would be fine, if the mechanism was changed so that it
> > actually worked right. That is, the mechanics would be such that any two
> > concurrently existing classes would be guaranteed to mangle the names of
> > their
> > private variables differently - simply using the class name (as now) doesn't
> > guarantee that when inheriting from a class in a different module and
> > reusing
> > the name.
>
> I know about the fear of accidental reuse of class names, but I don't
> find it a compelling argument.
FWIW, I know I currently have a number of classes that are potentially
hazardous in this way. Each of these classes is basically a
substitute class for a third-party API that I have to code to. The
API is missing a number of convenience methods, and the most
straightforward way to introduce these methods[1] is to create a
subclass of the appropriate class. Since they are in a different
module, it seems perfectly normal for me to give them the same name
since for all external modules, they should look the same as the
original API (but with the added methods). So I have a number of
classes that look something like:
class Document(_cdm.Document):
...
# add convenience methods here
...
I don't use double-underscore name mangling, but if I did, it would
clearly fail in this case.
[1] I've concluded this after a variety of refactorings. But perhaps
there is a better way...
> Also, I like the current, well-defined mangling algorithm; it means
> that when I'm in the debugger I can manually mangle or unmangle names
> as required.
Why couldn't the name mangling do something like:
'_%s_%s__%s' % (cls.__module__, cls.__name__, attrname)
This would still allow manual mangling/unmangling, and it seems like
it would cover most of the same-name different module concerns...
STeVe
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
