Also you can support future changes to the syntax (e.g. __matmul__ and
friends from 3.5, __aiter__ from 3.5.2) with a single codebase rather than
having to push that grammar back to previous versions (impossible?) or have
the grammar for magic methods be extraordinarily general (messy?)
On Tue,
Another advantage of dunder method names is that you
can google them. Someone coming across a method called
"__foo__" can easily find documentation about it, but
it's not so easy to do that for special syntax.
--
Greg
___
Python-ideas mailing list
I think that the most important simple thing with dunder/magic methods is
name mangling, and that an abstraction like your proposed one makes it less
clear what will happen to a name.
Also, as Nick Coghlan pointed out, there are a lot of dunder/magic methods
Nathan Dunn writes:
> > * the mapping protocol covers more than just __getitem__
>
> __setitem__(self, key, value) could bedef self[key] = value
> likewise
> __delitem__(self, key) def del self[key]:
> __iter__(self) iter(self)
>
On Sun, Nov 06, 2016 at 01:28:34AM -0500, Nathan Dunn wrote:
> Python has very intuitive and clear syntax, except when it comes to method
> definitions, particularly dunder methods.
I disagree with your premise here. Python's method definitions are just
as intuitive and clear as the rest of
On 6 November 2016 at 16:28, Nathan Dunn wrote:
> There are some immediate problems with this, such as `bool(self)` being
> indistinguishable from a regular method signature and `class(x, y)` not
> declaring the `self` identifier. These and other problems can be solved to
>
Python has very intuitive and clear syntax, except when it comes to method
definitions, particularly dunder methods.
class Vec(object):
def __init__(self, x, y):
self.x, self.y = x, y
def __add__(self, other):
return Vec(self.x + other.x, self.y + other.y)
def