[Python-3000] Removing __var

Christian Tanzer tanzer at swing.co.at
Sun Sep 24 14:04:54 CEST 2006


"Bob Ippolito" <bob at redivi.com> wrote:

> On 9/22/06, Thomas Heller <theller at python.net> wrote:
> > Bob Ippolito schrieb:
> > > On 9/22/06, Fred L. Drake, Jr. <fdrake at acm.org> wrote:
> > >> On Friday 22 September 2006 13:05, Christian Tanzer wrote:
> > >>  > It is useful in some situations, though. In particular, I use a
> > >>  > metaclass that sets `__super` to the right value. This wouldn't work
> > >>  > without name mangling.
> > >>
> > >> This also doesn't work if two classes in the inheritance hierarchy have the
> > >> same __name__, if I understand how you're using this.  My guess is that
> > >> you're using calls like
> > >>
> > >>     def doSomething(self, arg):
> > >>         self.__super.doSomething(arg + 1)
> > >
> > > In the one or two situations where it "is useful" you could always
> > > write out what it would've done.
> > >
> > > self._ThisClass__super.doSomething(arg + 1)
> >
> > It is much more verbose, though.  The question is are you writing
> > this more often, or are you introspecting more often?
>
> The point is that legitimate __ usage is supposedly so rare that this
> verbosity doesn't matter. If it's verbose, people definitely won't use
> it until they need to, where right now people do it all the time cause
> it's "private".

How can you say that?

I don't use __ for `private`, I use it for making cooperative super
calls (and `__super` occurs 1397 in my sandbox). I definitely don't
*want* to put the name of the class into a cooperative call. Compare

    self.__super.doSomething(arg + 1)

with

    super(SomeClass, self).doSomething (arg + 1)

The literal class name is verbose, error prone, and hostile to
refactoring.

I don't care about people supposedly abusing __ to define `private`
attributes -- we are all consenting adults here. (And people trying to
restrict visibility probably commit all sorts of blunders. Trying to
stop that might mean taking away most of Python's features).

-- 
Christian Tanzer                                    http://www.c-tanzer.at/



More information about the Python-3000 mailing list