[Python-ideas] Generators' and iterators' __add__ method

[julien tayon]

>> It would also clash with existing meanings of __add__ on some
>> types, such as NumPy arrays.
>
>
> Good example for Python Ideas FAQ.

Well, it looks like a classical problem of disambiguisation. We have
more than one consistent behaviour for addition. (I know I am dense).

And these behaviours  clash if not properly disambiguized.  In a world
were unicorns exists, we would select the behaviour of __add__ with a
switch (let's say __add__ would be a dispatch table that would take
the «algebrae» as a parameter). Still in this  world were unicorns
exists and Perl6 would be in production (and acclaimed) this switch
could be sensibily set according to the context. And everybody would
be perfectly aware and taking no dangers.

In the actual word, it is pretty much a chimera or a dying foetus
(musical joke) in the case of python since it would violates half the
tao of python :
...
Explicit is better than implicit.
...
Complex is better than complicated.
...
Special cases aren't special enough to break the rules.
...
There should be one-- and preferably only one --obvious way to do it.

As a result my suggestion for the FAQ should be to state that anyone
wanting to submit an idea to python community should «import this»
first and see it as deadly serious.
I made the mistake twice :)

PS I still see cases were having an __algebrae__ private member could
be very helpful, because dynamic typing has its limit.

hf, gl

-- 
Jul