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.hettin...@gmail.com> wrote: > >> On Sep 13, 2015, at 3:09 PM, Maciej Fijalkowski <fij...@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. > > > > > > > > > > > _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
