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
On Sat, Nov 05, 2016 at 07:50:44PM +1000, Nick Coghlan wrote:
> Hi folks,
>
> As promised, here's a follow-up to the withdrawn PEP 531 that focuses
> on coming up with a common protocol driven solution to conditional
> evaluation of subexpressions that also addresses the element-wise
> comparison
