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.

classification
Title: Document which named built-in classes can be subclassed
Type: enhancement Stage: needs patch
Components: Documentation Versions: Python 3.3, Python 3.4, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: cvrebert, daniel.urban, docs@python, ezio.melotti, terry.reedy
Priority: normal Keywords:

Created on 2013-02-22 22:09 by terry.reedy, last changed 2022-04-11 14:57 by admin.

Files
File name Uploaded Description Edit
subclassable.py terry.reedy, 2013-02-24 01:53
Messages (4)
msg182703 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-02-22 22:09
More than once, people have noted on python-list that not all built-in classes can be subclassed and that there seems to be no way to find out which, other than to try each. (Today, Daniel Urban pointed out the CPython-specific 'xx.__flags__ & (1 << 10)'.) If the specifics are a Python feature, rather than CPython specific, I think they should be given in the doc.

There is a recent issue, which I cannot find, about re-organizing the Library built-in functions chapter by groups. If this is done, it would be easy to add, in the introduction to built-in classes, a list of which of the named classes can or cannot be subclassed (whichever list is shorter) and note that those not in builtins cannot be.)
msg182846 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-02-24 01:53
Such a list might differentiate between classes that are intentionally not subclassed and those for which subclassing simply has not yet been enabled. That might help eliminate the latter list.

When I suggested on the python-ideas 'range' thread that people should best get what they wanted with a range subclass, if that were made possible, Nick C. replied "I wasn't even aware you *couldn't* subclass it (I'd never tried).". Indeed, why would he with no doc.

The types module doc could also use an addition.
Attached subclassable.py produces these lists:
Among named builtin classes, these cannot be subclassed:
bool, memoryview, range, slice, 
Among types classes, these can be subclassed:
ModuleType, SimpleNamespace,
msg182847 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-02-24 02:25
The list given is for 3.3. 3.2 and 2.7 do not have SimpleNamespace. I do not have and currently cannot build 3.4 to test, but as of this moment, I expect it to be the same. In 2.7, range is xrange. Its types module includes aliases for builtins, such as IntType, so "Among classes that do not have built-in names" would need to be prefixed.

I simple sentence for types should be easy to place. I am not sure about the built-ins list. The bool entry already has "Class bool cannot be subclassed further. Its only instances are False and True (see Boolean Values).", so a general list would be repeating that part. I am thinking of a minimal sentence for the other three entries. "This class cannot be subclassed."
msg183231 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-02-28 20:38
From the current python-ideas 'range' thread:
Me: Would it be correct to say (now) that all 4 are intentional omissions? and not merely oversights?
Nick: Yes, I think so. People will have to be *real* convincing to explain a case where composition isn't a more appropriate solution.
History
Date User Action Args
2022-04-11 14:57:42adminsetgithub: 61481
2013-02-28 20:38:01terry.reedysetmessages: + msg183231
2013-02-28 06:26:39ezio.melottisetnosy: + ezio.melotti
2013-02-24 17:32:30cvrebertsetnosy: + cvrebert
2013-02-24 02:25:07terry.reedysetmessages: + msg182847
2013-02-24 01:53:01terry.reedysetfiles: + subclassable.py

messages: + msg182846
2013-02-22 22:52:35daniel.urbansetnosy: + daniel.urban
2013-02-22 22:09:24terry.reedycreate