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 rhettinger
Recipients docs@python, ncoghlan, rhettinger, terry.reedy
Date 2018-07-16.10:41:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1531737694.32.0.56676864532.issue34118@psf.upfronthosting.co.za>
In-reply-to
Content
> I propose that the 2nd 3 follow the model of the 1st 3,

This makes sense and would read a little better.

> Classes enumerate, filter, map, memoryview, range, reversed, 
> tuple, and zip are untagged.  I think, to be consistent, 
> that they should all get the *class* tag.

To me, that makes the most sense for: memoryview, range and tuple.

The rest are used like functions.  Even though they are technically classes, it is confusing to think of them as such (we don't call map() to get an instance of a mapobject and do a dir() to what interesting methods it may have).  Tools like map() and filter() actually were functions at one time.  The substantive change was that they were made to be lazy.  The implementation detail was that they were implemented as classes -- they could have been generators instead.  Accordingly, I think tagging these as classes is pedantically correct but actually makes the docs a little less usable.
History
Date User Action Args
2018-07-16 10:41:34rhettingersetrecipients: + rhettinger, terry.reedy, ncoghlan, docs@python
2018-07-16 10:41:34rhettingersetmessageid: <1531737694.32.0.56676864532.issue34118@psf.upfronthosting.co.za>
2018-07-16 10:41:34rhettingerlinkissue34118 messages
2018-07-16 10:41:34rhettingercreate