[Python-ideas] Method signature syntactic sugar (especially for dunder methods)

[Nathan Dunn]

> * __add__ is only part of the addition protocol, there is also
> __radd__ and __iadd__

__iadd__ could be represented as def self += value:.

Reflected binary operators do pose a problem. A possible solution would be
to give self special meaning in this context, so def self + other: would
correspond to __add__ and def other + self: to __radd__. But of course,
this would be a more fundamental change to the language than just syntactic
sugar.


> * likewise, there is not a one-to-one correspondence between the
> bool() builtin and the __bool__() special method (there are other ways
> to support bool(), like defining __len__() on a container)

That is a fair point, but I think this would be only a slight point of
confusion. I believe for the most part other builtins such as __abs__,
__len__, etc. do have a one-to-one correspondence so this syntax would make
sense in almost all situations.

But while were on the topic, I will take this opportunity to note that all
the methods to support builtins suffer from the same ambiguity I alluded to
earlier with bool(self). One solution could be to use a @builtin decorator
or something to that effect, but that would more or less defeat the purpose
of cleaner, more intuitive syntax. It may be that there is no viable
alternative for the builtin function dunder methods.


> * the mapping protocol covers more than just __getitem__

__setitem__(self, key, value)   could be    def self[key] = value
likewise
__delitem__(self, key)                      def del self[key]:
__iter__(self)                              iter(self)
__len__(self)                               len(self)


> (and you also
> need to decide if you're implementing a mapping, sequence, or
> multi-dimensional array)

Could you speak more about this? It doesn't seem to me that this would
affect the method signatures since it is up to the implementer to interpret
the semantic meaning of the keys.


> it would break the current symmetry between between name binding
> in def statements and target binding in assignment statements

> With the proposed change, we'd face the
> problem that the following would both be legal, but meant very
> different things:
>
>     cls.mymethod = lambda self: print(self)
>     def cls.mymethod(self): print(self)
>
> The former is already legal and assigns the given lambda function as a
> method on the existing class, `cls`
>
> The latter currently throws SyntaxError.
>
> With the proposed change, rather than throwing SyntaxError as it does
> now, the latter would instead be equivalent to:
>
>     def mymethod(cls, self): print(self)
>
> which would be a very surprising difference in behaviour.

I will admit that there is potential for confusion here as this

class Formatter(object):
def Formatter.displayDefault(obj):
print('[{}]'.format(obj))

is rather suggestive of a static method, but I don't think the confusion
arises because the syntax breaks the symmetry you reference. The self-dot
syntax *is* meant to elicit target binding in assignment statements. Just
as self.mymethod = lambda p1, p2: p1+p2 indicates that an instance of the
class has a callable with two parameters bound to its mymethod attribute,
so too does the statement def self.mymethod(p1, p2):. So I don't think this
inherently breaks any symmetry.

It is specifically in the case that the identifier is the same as the class
name that this leads to surprising behavior, but there is already a similar
risk of confusion any time the name of a class is used as an identifier
within the class body. Perhaps my proposed syntax does increase this risk
since the identifier doesn't look like a parameter or a variable, but
hopefully the self form of this syntax would be so commonplace that seeing
anything else before the dot would throw up a red flag.


Thanks,
-Nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20161107/ad9258dc/attachment-0001.html>