Skip to content

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

Closed

Description

@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

Activity

  1. added
    type-bugAn unexpected behavior, bug, or error
    on Nov 27, 2023
  2. ngnpope commented on Nov 27, 2023

    @ngnpope
    Contributor

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

  3. changed the title [-]pure python datetime.timezone is not acceptable as a base class[/-] [+]C-extension `datetime.timezone` is not acceptable as a base class[/+] on Nov 27, 2023
  4. felixxm commented on Nov 29, 2023

    @felixxm
    Contributor

    Working on patch

  5. changed the title [-]C-extension `datetime.timezone` is not acceptable as a base class[/-] [+]C-extension `datetime.timezone` is not acceptable as a base class; pure-Python version is[/+] on Nov 29, 2023
  6. added 3 commits that reference this issue on Nov 29, 2023
  7. pganssle commented on Nov 29, 2023

    @pganssle
    Member

    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.

  8. felixxm commented on Nov 29, 2023

    @felixxm
    Contributor

    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.

  9. felixxm commented on Jan 12, 2024

    @felixxm
    Contributor

    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):
        ...
  10. 7 remaining items

  11. added a commit that references this issue on Jan 17, 2024
  12. felixxm commented on Jan 17, 2024

    @felixxm
    Contributor

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

  13. added 3 commits that reference this issue on Jan 17, 2024
  14. added 3 commits that reference this issue on Jan 24, 2024
  15. added a commit that references this issue on Jan 26, 2024
  16. added a commit that references this issue on Feb 11, 2024
  17. added a commit that references this issue on Sep 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    extension-modulesC modules in the Modules dirtype-bugAn unexpected behavior, bug, or error

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions