This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients docs@python, ncoghlan, rhettinger, terry.reedy
Date 2018-07-20.10:49:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Marking memoryview, range, and tuple explicitly as classes, and making the initial phrasing in the docs consistent across all the builtin collection/container types sounds like a good improvement to me.

I agree with Raymond that we should leave whether or not enumerate, filter, map, reversed, and zip support inheritance, isinstance() and issubclass() ambiguous for now (at least within the scope of this issue). That's the main observable difference between implementations that expose a class definition directly, and those that wrap them in a factory function.

While technically that ambiguity is a portability problem across implementations, in practice folks that want to emulate one of these behaviours are far more likely to write their own generator function or iterator class from scratch than they are to try to inherit from one of these.

If we were going to note anything at all for these, it would be to put a "CPython implementation detail" note in each one about the fact that you can subclass them being a CPython implementation detail, but I'd only suggest adding that if we ever get complaints about this hindering portability in practice, rather than our pointing it ourselves as a potential point of inconsistency.
Date User Action Args
2018-07-20 10:49:36ncoghlansetrecipients: + ncoghlan, rhettinger, terry.reedy, docs@python
2018-07-20 10:49:36ncoghlansetmessageid: <>
2018-07-20 10:49:36ncoghlanlinkissue34118 messages
2018-07-20 10:49:36ncoghlancreate