Document which named built-in classes can be subclassed

[terryjreedy]

BPO	17279
Nosy	@terryjreedy, @ezio-melotti, @durban
Files	subclassable.py

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2013-02-22.22:09:24.066>
labels = ['type-feature', 'docs']
title = 'Document which named built-in classes can be subclassed'
updated_at = <Date 2013-02-28.20:38:01.646>
user = 'https://github.com/terryjreedy'

bugs.python.org fields:

activity = <Date 2013-02-28.20:38:01.646>
actor = 'terry.reedy'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation']
creation = <Date 2013-02-22.22:09:24.066>
creator = 'terry.reedy'
dependencies = []
files = ['29216']
hgrepos = []
issue_num = 17279
keywords = []
message_count = 4.0
messages = ['182703', '182846', '182847', '183231']
nosy_count = 5.0
nosy_names = ['terry.reedy', 'ezio.melotti', 'cvrebert', 'daniel.urban', 'docs@python']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue17279'
versions = ['Python 2.7', 'Python 3.3', 'Python 3.4']

Linked PRs

• gh-61481: Document that memoryview, range, and slice cannot be subclassed #153766

[terryjreedy]

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.)

[terryjreedy]

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,

[terryjreedy]

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."

[terryjreedy]

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.