[Python-ideas] Fast sum() for non-numbers - why so much worries?

[Stephen J. Turnbull]

Joshua Landau writes:

 > > [Aside: it's a poor analogy. Gills are not like lungs, they
 > > differ greatly in many ways,
 > 
 > This isn't really relevant, but alas they *are* like lungs. Sure,
 > it's an imperfect relation, but that's why I said "like lungs" and
 > not "are lungs".

No, it is relevant.  You provide a very high-level specification
("extract oxygen from ambient fluid"), and then make a slightly lower-
level distinction ("ambient fluid is air vs. water").  But as far as I
can see, many of the issues that make "sum(iterable of sequences)" an
unattractive API are far lower-level ("counter-current vs. concurrent").
ISTM that the choice of *not* constraining the definitions of _i<binop>
to be efficient, in-place versions of the corresponding _<binop> was
deliberate.  So you need to take into account differences that are
potential and ill-defined -- and when Steven provides a real use case
at this level, you start preparing to concede.

 > > If __iadd__ becomes optional, but preferred over __add__, then
 > > some currently summable classes will change their behaviour
 > > (although you call those classes "broken").
 > 
 > That is what I was doing - calling them broken.
 > 
 > > In either case, this is a semantic change to sum, which is what you
 > > explicitly denied.
 > 
 > I'm not sure not supporting broken code counts as a semantic change.
 > That is what I was debating.

It does count; it's a language change.  It is not a bug-fix in which
the implementation is brought into line with the language definition.
CPython has historically taken the position if the language definition
is ambiguous, a change in CPython behavior requires that *the language
definition be changed* to clarify that the changed behavior is the
mandated behavior.  Note also that CPython is intended to be a
reference implementation.  Therefore existing behavior has a special
significance unless explicitly specified to be implementation-
dependent.  Not only applications, but other implementations, may
depend on existing behavior.

 > But that is what I am doing :P. If a spec is undefined, you don't
 > require results to be consistent.

No, that may be a bug in the spec: the spec is incomplete, but it does
include requiring results to be consistent.  That's why reference
implementations exist, and why "modern" specs explicitly state that
behavior is undefined, or that a certain construct "is an error [even
if the implementation doesn't signal it]".

 > This is what would happen. That changes nothing, as far as I am
 > concerned -- and hence is not a semantic change.

Well, I see that you do know what you're doing.  My opinion (which is
not authoritative) is that you are using a different definition of
"semantic change" from the one used by Python (!= CPython).

 > >> Python has previously had precedents where broken code does not
 > >> get to dictate the language as long as that code was very rare.

I suspect Guido would not call code "broken" unless it depended on an
actual bug in the implementation, or there was another way to do it
that is TOOWTDI.  Here there is another way to do it that is TOOWTDI
*for the case you want to support* (not the code you consider broken).
So this is a losing analogy for you.

 > > E.g. I have a DSL where = reassigns to a data structure, +=
 > > appends to an existing one, and + is not defined at all.
 > 
 > That is... really quite a good argument. I think I may have to think
 > on that final point, but you've probably just about won it. Why didn't
 > you just say this from the start?

Because he thought his other arguments were even better.<wink/>

(another) Steve