Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #56513

Re: class-private names and the Zen of Python

Show key headers only | View raw

On 10/08/2013 06:24 AM, Steven D'Aprano wrote:
> On Tue, 08 Oct 2013 12:13:48 +0200, Marco Buttu wrote:
>
>> In the following case:
>>
>>   >>> class Foo:
>> ...     _Foo__a = 100
>> ...     __a = 33
>> ...
>>   >>> Foo._Foo__a
>> 33
>>
>> I think this behavior, for a user who does not know the convention,
>> could be a surprise.
> Yes, you are correct. It surprised me, and I've been using Python for
> more than 15 years, and I know the convention of double-underscore name-
> mangling.
>
>
>> Should be raising an exception (in order to inform
>> the user the transformation of the name __a have been replaced an
>> existing name) a possible --explicit-- alternative?
> No, I don't think so. That would slow down class creation, for no real
> benefit. Except for the name-mangling part, this is no different from:
>
> class Spam:
>      x = 23
>      x = 42
>
> If anything, something like PyLint or PyChecker could warn about it. But
> the language itself is fine like it is.
>
>
>> Another question is: where is the place in which this transformation
>> occurs? Is it at the parser level, before the dictionary attribute is
>> gave as argument to the metaclass?
> Good question!
>
> I don't have a full answer, but I have a part answer: it occurs before
> the metaclass sees the namespace:
>
> py> class Meta(type):
> ...     def __new__(meta, name, bases, namespace):
> ...             print(namespace)
> ...             return super().__new__(meta, name, bases, namespace)
> ...
> py>
> py> class Test(metaclass=Meta):
> ...     __test = 'foo'
> ...
> {'__module__': '__main__', '_Test__test': 'foo', '__qualname__': 'Test'}
>
>
> so I think it is done by the parser.
Unless one wanted to add an error checking mode to the interpreter, not 
a totally bad idea, I agree that this is a job for external tools.  But 
perhaps that same external tool should be referenced in the 
documentation.  As it is I'm not clear that PyLint and/or PyChecker are 
kept current with the compiler/interpreter version, and I rather suspect 
that they aren't.  (This won't normally show up, as changes that they 
would catch happen quite rarely, but...)

OTOH, neither one really fits in as, say, an included module...they're 
more like idle, which now that I look does have a "check module" run 
option.  Perhaps that invokes one of them.  I note that Idle, itself, is 
barely mentioned in the documentation. Perhaps there needs to be a 
"tools" section.


-- 
Charles Hixson

Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

class-private names and the Zen of Python Marco Buttu <marco.buttu@gmail.com> - 2013-10-08 12:13 +0200
  Re: class-private names and the Zen of Python Terry Reedy <tjreedy@udel.edu> - 2013-10-08 06:36 -0400
    Re: class-private names and the Zen of Python Marco Buttu <marco.buttu@gmail.com> - 2013-10-08 12:47 +0200
  Re: class-private names and the Zen of Python Ned Batchelder <ned@nedbatchelder.com> - 2013-10-08 07:07 -0400
    Re: class-private names and the Zen of Python Marco Buttu <marco.buttu@gmail.com> - 2013-10-08 13:15 +0200
      Re: class-private names and the Zen of Python Ned Batchelder <ned@nedbatchelder.com> - 2013-10-08 12:20 -0400
  Re: class-private names and the Zen of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-08 13:24 +0000
    Re: class-private names and the Zen of Python Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-09 00:00 +0100
      Re: class-private names and the Zen of Python Marco Buttu <marco.buttu@gmail.com> - 2013-10-09 07:55 +0200
    Re: class-private names and the Zen of Python Charles Hixson <charleshixsn@earthlink.net> - 2013-10-09 12:34 -0700

csiph-web