datetime subclass repr varies by implementation

[jaraco]

In pypy/pypy#3980, I reported an issue I'd encountered where the repr of a datetime.datetime subclass shows a different repr depending on which implementation (C or Python) of the datetime module is used:

import sys
import importlib
c_impl = importlib.import_module('_datetime')
sys.modules['_datetime'] = None
py_impl = importlib.import_module('datetime')
assert repr(py_impl.datetime(2000,1,1)) == repr(c_impl.datetime(2000,1,1))

class Fake(py_impl.datetime):
  pass

fpy = Fake(2000,1,1)

class Fake(c_impl.datetime):
  pass

fc = Fake(2000,1,1)

assert repr(fpy) == repr(fc), f'{fpy!r} != {fc!r}'

Emits as output:

Traceback (most recent call last):
  File "/Users/jaraco/draft/dt.py", line 18, in <module>
    assert repr(fpy) == repr(fc), f'{fpy!r} != {fc!r}'
AssertionError: __main__.Fake(2000, 1, 1, 0, 0) != Fake(2000, 1, 1, 0, 0)

This inconsistency wreaks havoc on doctests when using a library like freezegun.

Is there a way for these two implementations to share a common repr?

Linked PRs

• gh-107773: Make datetime subclass repr consistent both implementations #130308

[mattip]

The difference is in the implementation of __repr__ of the datetime.py pure python implementation, and the _datetime.c c-extension module __repr__.

[jaraco]

Looking at the definition of a PyTypeObject, I see that tp_name is meant to supply the module name.

[jaraco]

Somehow, the __module__ of the subclass isn't making it into the tp_name of the type object in the C API.

import datetime

class Fake(datetime.datetime):
  pass

print(repr(datetime.datetime(2000,1,1)))
print(repr(Fake(2000,1,1)))

datetime.datetime(2000, 1, 1, 0, 0)
Fake(2000, 1, 1, 0, 0)

[mattip]

tp_name is meant to supply the module name

I think that is for types created via C extension (like _datetime.datetime, which also does not tell the full truth since the module name is _datetime not datetime). Types created from python will not have the module name. Here is the PyTypeObject struct of Fake (python3.9, I stopped in a C debugger in datetime_repr). If the __repr__ is meant to show the module name, it will have to dig it out of the class's __dict__.

debug output

(gdb) p *self->ob_base->ob_type
$3 = {ob_base = {ob_base = {ob_refcnt = 5, ob_type = 0x975620 <PyType_Type>}, ob_size = 0}, tp_name = 0x7ffff7a2b7a0 "Fake",
tp_basicsize = 64, 
tp_itemsize = 0,
tp_dealloc = 0x47ffa3 <subtype_dealloc>,
tp_vectorcall_offset = 0,
tp_getattr = 0x0,
tp_setattr = 0x0, 
tp_as_async = 0xaf3da8,
tp_repr = 0x556363 <datetime_repr>,
tp_as_number = 0xaf3dc0,
tp_as_sequence = 0xaf3ef8,
tp_as_mapping = 0xaf3ee0, 
tp_hash = 0x55d76a <datetime_hash>,
tp_call = 0x0, tp_str = 0x55726a <datetime_str>,
tp_getattro = 0x46f1db <PyObject_GenericGetAttr>, 
tp_setattro = 0x46e915 <PyObject_GenericSetAttr>,
tp_as_buffer = 0xaf3f48,
tp_flags = 284160,
tp_doc = 0x0, 
tp_traverse = 0x47fdcf <subtype_traverse>,
tp_clear = 0x47fec7 <subtype_clear>,
tp_richcompare = 0x559173 <datetime_richcompare>, 
tp_weaklistoffset = 56,
tp_iter = 0x0,
tp_iternext = 0x46a99b <_PyObject_NextNotImplemented>,
tp_methods = 0x0,
tp_members = 0xaf3f80, 
tp_getset = 0x97d380 <subtype_getsets_full>,
tp_base = 0x98b140 <PyDateTime_DateTimeType.lto_priv.0>, 
tp_dict = {'__module__': '__main__', '__dict__': <getset_descriptor at remote 0x7ffff7914470>, '__weakref__': <getset_descriptor at remote 0x7ffff7914590>, '__doc__': None},
tp_descr_get = 0x0,
tp_descr_set = 0x0,
tp_dictoffset = 48,
tp_init = 0x47edd9 <object_init>, 
tp_alloc = 0x47fbde <PyType_GenericAlloc>,
tp_new = 0x55cb28 <datetime_new>,
tp_free = 0x541c09 <PyObject_GC_Del>,
tp_is_gc = 0x0, 
tp_bases = (<type at remote 0x98b140>,), 
tp_mro = (<type at remote 0xaf3c10>, <type at remote 0x98b140>, <type at remote 0x98b2e0>, <type at remote 0x974fa0>),
tp_cache = 0x0, 
tp_subclasses = 0x0,
tp_weaklist = <weakref at remote 0x7ffff79142f0>,
tp_del = 0x0,
tp_version_tag = 0,
tp_finalize = 0x0, 
tp_vectorcall = 0x0}

[donBarbos]

I think if tp_name doesn't add module name for subclasses then we shouldn't either.
Your test case passes successfully after my change in #130308

[StanFromIreland]

This is complete, issue can be closed.