[Python-Dev] semantics of subclassing things from itertools

[Raymond Hettinger]

> On Sep 13, 2015, at 3:09 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> 
> Well, fair enough, but the semantics of "whatever happens to happen
> because we decided subclassing is a cool idea" is possibly the worst
> answer to those questions.

It's hard to read this in any way that isn't insulting.

It was subclassable because a) it was a class, 2) type/class unification was
pushing us in the direction of making builtin types more like regular classes
(which are subclassable), and 3) because it seemed potentially useful
to users (and apparently it has been because users are subclassing it).

FWIW, the code was modeled on what was done for enumerate() and
reversed() where I got a lot of coaching and review from Tim Peters,
Alex Martelli, Fredrik Lundh, and other python luminaries of the day.


> Ideally, make it non-subclassable. If you
> want to have it subclassable, then please have defined semantics as
> opposed to undefined.

No, I'm not going to change a 13 year-old API and break existing user code
just because you've gotten worked-up about it.

FWIW, the semantics wouldn't even be defined in the itertools docs.
It is properly in some section that describes what happens to any C type
that defines sets the Py_TPFLAGS_BASETYPE flag.   In general, all of
the exposed dunder methods are overridable or extendable by subclassers.


Raymond


P.S.  Threads like this are why I've developed an aversion to python-dev.
I've answered your questions with respect and candor. I've been sympathetic
to your unique needs as someone building an implementation of a language
that doesn't have a spec.  I was apologetic that the docs which have been
helpful to users weren't precise enough for your needs.   

In return, you've suggested that my first contributions to Python were 
irresponsible and based on doing whatever seemed cool.

In fact, the opposite is the case.  I spent a full summer researching how similar
tools were used in other languages and fitting them into Python in a way that
supported known use cases.  I raised the standard of the Python docs by
including rough python equivalent code, showing sample inputs and outputs, 
building a quick navigation and summary section as the top of the docs,
adding a recipes section, making thorough unittests, and getting input from Alex,
Tim, and Fredrik (Guido also gave high level advice on the module design).

I'm not inclined to go on with this thread. Your questions have been answered
to the extent that I remember the answers.  If you have a doc patch you want
to submit, please assign it to me on the tracker.  I would be happy to review it.