curious position of
(reluctantly) agreeing with your conclusion to "Go ahead and implement
your protocol using attributes with plain names" even though I disagree
with virtually every part of your reasoning. In my mind, the two deciding
factors are:
(1) Guido's original style guid
Ben Finney wrote:
> The double-underscore convention seems more for attributes *that are
> interpreted specially*, e.g. by syntax operators or other core
> language features.
I would qualify that by adding that it's for attributes that are treated
specially _and when you don't want to overload o
Steven D'Aprano wrote:
> Double-underscore names and methods are special to Python. Developers are
> prohibited from creating their own (although the language doesn't enforce
> that prohibition). From PEP 0008, written by Guido himself:
>
> __double_leading_
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> having the ability to create a protocol is a Very Good Thing, and
> double leading and trailing underscore names are the accepted Python
> style for such special methods.
Is it? There are many protocols that use plain names. Even the
built-in types su
Steven D'Aprano wrote:
> So what do folks think? I believe the protocol idiom ("look for a method
> called __parrot__ and then do something with it") is too useful and
> powerful to be ignored, but then if __parrot__ is reserved by Python,
> what to do?
The Python core claims all rights for __m
Double-underscore names and methods are special to Python. Developers are
prohibited from creating their own (although the language doesn't enforce
that prohibition). From PEP 0008, written by Guido himself:
__double_leading_and_trailing_underscore__: "magic" objects or
