[Python-Dev] semantics of subclassing things from itertools

[Maciej Fijalkowski]

Hey Raymond

I'm sorry you got insulted, that was not my intention. I suppose
something like "itertools objects are implemented as classes
internally, which means they're subclassable like other builtin types"
is an improvement to documentation.

On Mon, Sep 14, 2015 at 12:17 AM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
>
>> 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.
>
>
>
>
>
>
>
>
>
>
>