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 terry.reedy
Recipients chris.jerdonek, eric.araujo, ezio.melotti, terry.reedy
Date 2013-01-12.03:32:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1357961522.36.0.546885628429.issue16927@psf.upfronthosting.co.za>
In-reply-to
Content
I like this idea, including the function subdivisions. I once suggested moving the classes into the later builtins chapter, but it was pointed out to me that a) they once *were* functions (no longer relevant); b) they are callables (very relevant); and hence people who see "bytearray(b'abc')" might not know that bytearray *is* a class. A separate section could have a few lines of introduction explaining "Keyword 'class' and built-in name 'type' serve different roles in code. But when referring to a Python object, they are more or less synonyms. Classes are callable. The operators and methods of the instances returned by the following built-classes are explained in the Built-in Types section."

The index is another discovery method, one I use routinely, especially with the offline Windows help version of the docs, where one just types the first few letters of the name being sought in the index tab (much easier than the online click and search version). (Though the index entries might be improved a bit, that is another issue.)

code related: compile comes before eval and exec, both of which use compile on string input.
History
Date User Action Args
2013-01-12 03:32:02terry.reedysetrecipients: + terry.reedy, ezio.melotti, eric.araujo, chris.jerdonek
2013-01-12 03:32:02terry.reedysetmessageid: <1357961522.36.0.546885628429.issue16927@psf.upfronthosting.co.za>
2013-01-12 03:32:02terry.reedylinkissue16927 messages
2013-01-12 03:32:00terry.reedycreate