C-extension datetime.timezone is not acceptable as a base class; pure-Python version is

[mattip]

Bug report

Bug description:

Datetime has two modes. There is divergent behavior between the pure python and the c-extension timezone class, as found in django

>>> import datetime, _pydatetime
>>> class timezone(_pydatetime.timezone): pass  # Works fine...
... 
>>> class timezone(datetime.timezone): pass  # Fails to subclass...
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type 'datetime.timezone' is not an acceptable base type

CPython versions tested on:

3.12

Operating systems tested on:

Linux

Linked PRs

• gh-112451: Make C-extension datetime.timezone acceptable as a base class. #112518
• gh-112451: Prohibit subclassing of datetime.timezone. #114190

[ngnpope]

Just to clarify: It is acceptable as a base class in Pure Python, but not in the C extension.

[felixxm]

Working on patch

[pganssle]

I think @abalkin would know better, but I think the no-subclassing behavior was deliberate. If that is the case we should probably fix it by preventing inheritance in the pure Python module.

[felixxm]

I think @abalkin would know better, but I think the no-subclassing behavior was deliberate. If that is the case we should probably fix it by preventing inheritance in the pure Python module.

I'm fine with making them consistent in any way. Just let me know and I'll update my patch.

[felixxm]

I think @abalkin would know better, but I think the no-subclassing behavior was deliberate. If that is the case we should probably fix it by preventing inheritance in the pure Python module.

As far as I'm aware, there are reasonable use cases for timezone subclasses, e.g. enums:

class AvailableTimezone(datetime.timezone, enum.Enum):
    ...

[serhiy-storchaka]

One of advantage of non-inheritable C-extension classes is that you can replace __init__ constructor with __new__ constructor. __new__ is more convenient in C-extension classes, because it makes easier to guarantee that all fields are properly initialized. On other hand, __init__ is more convenient in Python classes. Replacing __init__ with __new__ can break subclasses with their own constructor.

Fortunately, both timezone implementations use __new__.

But when make a class inheritable, you should check a lot of other details. Test with overridden __init__(). Test with overridden methods. Test with additional attributes. How non-trivial subclasses work with pickling and shalllow and deep copying? How instances of different subclasses are compared?

[pganssle]

Here is Alexander's original justification for not allowing timezone to be subclassed: #49344 (comment)

I tend to agree with his reasoning, but I don't entirely understand the enum example given by @felixxm here. Why exactly does it need to be a subclass?

[erlend-aasland]

Thanks for chiming in @pganssle and @serhiy-storchaka. I see this is not as straight-forward as I thought. If any change is to be done, it would have to be to follow up Paul's suggestion to disallow subclassing of the Python class. We can also just leave it as it is; there are plenty of cases where the C implementation of a module differs from the Python implementation.

[felixxm]

I tend to agree with his reasoning, but I don't entirely understand the enum example given by @felixxm here. Why exactly does it need to be a subclass?

True, it's not probably not as useful as IntEnum or StrEnum.

there are plenty of cases where the C implementation of a module differs from the Python implementation.

Granted, but these small differences make things trickier when you try to support Python and PyPy at the same time.

[felixxm]

I've submitted a new PR to make both implementation consistent, #114190.