GeezerVison

@StanFromIreland We do:

https://github.com/python/cpython/blob/dea4083aa95/Modules/arraymodule.c#L2561

https://github.com/python/cpython/blob/dea4083aa95/Modules/_decimal/_decimal.c#L3699

I copied my approach from there. I'm OK with moving to init_state(), somehow PEP 810 set the tone.

I believe the reason why it didn't work is that it relied on a global variable, instead of per-interpreter module. I left a note in #148085 in the previous discussions feature section.

I remember there were issues with datetime and the capsule API so be careful there. Likewise, if you do per-state caching, it may break existing hooks (removing the module from sys.modules will not make it reload I think)

Likewise, if you do per-state caching, it may break existing hooks (removing the module from sys.modules will not make it reload I think)

How real of a concern is this?

I've grepped the code and I think we already tend to break monkey-patching:

I definitely do not want to cause any regression, but this seems to be a pattern, and the performance gain (on repeated runs) is real.

I would say it could break in tests. It's not uncommon to patch time-related modules when working with datetime I'd say. I honestly don't know if this is a real issue but I just wanted you to be aware of this possibility. In the past, I added NEWS entries indicating that imports were changed for performance reason just for users to know that the reference is no more local/global. In this case, it'd be easy to fix if someone first mock time, and then import datetime instead of doing the other way around.

Hi @maurycy , great work on this.

Since this module declares Py_MOD_GIL_NOT_USED, I was wondering about the lazy init pattern in a free-threaded build. If two threads enter build_struct_time concurrently with st->time_struct_time == NULL, both would call PyImport_ImportModuleAttrString and one overwrite would leave a reference with an incremented refcount that never gets decref'd.

I noticed arraymodule.c and _decimal.c have the same pattern, so maybe this is just accepted. But _asynciomodule.c initializes eagerly in module_init() which avoids this structurally. Was lazy chosen deliberately here over eager init in init_state()?

@picnixz Thank you, improved the NEWS entry: ff27dc4.

@htjworld Thank you. I think you're 100% right and all lazy import caches should use CAS.

I believe this is the correct pattern:

@picnixz Do you think this is indeed the correct pattern, and https://github.com/python/cpython/blob/dea4083aa95/Modules/arraymodule.c#L2561-L2567 and https://github.com/python/cpython/blob/dea4083aa95/Modules/_decimal/_decimal.c#L3699 are prone?

Probably even:

https://github.com/python/cpython/blame/a0c57a8d17eb0f5c4e620d83a13a47cf4d85e76f/Python/crossinterp.c#L593

I no longer think lazy is not worth the complexity. I've reverted it in 33c64f2.

cc @StanFromIreland

@StanFromIreland A friendly ping :-)

Hi @maurycy, sorry for the delay, however I'm reluctant to merge this. It would (probably) break freezegun and other such packages that depend on the monkey-patching. @pganssle what do you think?

Also CC'ing @bblommers

Hi @maurycy, sorry for the delay, however I'm reluctant to merge this. It would (probably) break freezegun and other such packages that depend on the monkey-patching. @pganssle what do you think?

Also CC'ing @bblommers

Thank you! Great point. No rush. I've prepared a simple regression test:

import freezegun
import time_machine
import datetime
import os
import time

os.environ["TZ"] = "UTC"
time.tzset()

FROZEN = datetime.datetime(2010, 6, 15, 12, 0, 0)
DATE = datetime.date(2010, 6, 15)

with freezegun.freeze_time(FROZEN):
    assert datetime.date.today() == DATE
    assert datetime.datetime.now() == FROZEN
    assert datetime.datetime.today() == FROZEN
    assert DATE.strftime("%Y-%m-%d %A") == "2010-06-15 Tuesday"
    assert DATE.timetuple().tm_year == 2010
print("freezegun: ok")

with time_machine.travel(FROZEN, tick=False):
    assert datetime.datetime.now() == FROZEN
    assert DATE.strftime("%Y-%m-%d %A") == "2010-06-15 Tuesday"
    assert datetime.date.today() == DATE
    assert datetime.datetime.today() == FROZEN
print("time-machine: ok")

And I've got news for you 😂

2026-05-14T11:42:52.278765000+0200 maurycy@gimel /Users/maurycy/work/cpython (datetime-cache-time-module-lookups e00aa62?) % uv run --with freezegun --with time-machine --python 3.11 /tmp/czasumierzenie.py
freezegun: ok
time-machine: ok
2026-05-14T11:42:52.820308000+0200 maurycy@gimel /Users/maurycy/work/cpython (datetime-cache-time-module-lookups e00aa62?) % uv run --with freezegun --with time-machine --python 3.12 /tmp/czasumierzenie.py
freezegun: ok
time-machine: ok
2026-05-14T11:43:01.349321000+0200 maurycy@gimel /Users/maurycy/work/cpython (datetime-cache-time-module-lookups e00aa62?) % uv run --with freezegun --with time-machine --python 3.13 /tmp/czasumierzenie.py
freezegun: ok
time-machine: ok
2026-05-14T11:43:03.558151000+0200 maurycy@gimel /Users/maurycy/work/cpython (datetime-cache-time-module-lookups e00aa62?) % uv run --with freezegun --with time-machine --python 3.14 /tmp/czasumierzenie.py
freezegun: ok
time-machine: ok
2026-05-14T11:43:05.601936000+0200 maurycy@gimel /Users/maurycy/work/cpython (datetime-cache-time-module-lookups e00aa62?) % uv run --with freezegun --with time-machine --python 3.15 /tmp/czasumierzenie.py
freezegun: ok
Traceback (most recent call last):
  File "/tmp/czasumierzenie.py", line 24, in <module>
    assert datetime.date.today() == DATE
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError

Using git bisect:

2026-05-14T11:55:58.141343000+0200 maurycy@gimel /Users/maurycy/src/github.com/maurycy/cpython  (git)-[v3.15.0a6~249|bisect]?- % cat /tmp/bisekt.sh 
#!/usr/bin/env bash
set -u
cd "$(git rev-parse --show-toplevel)"
make -j"$(nproc)" >/tmp/bisect-build.log 2>&1
PY=./python.exe
[ -x "$PY" ] || exit 125
uv run --with freezegun --with time-machine --python "$PY" /tmp/czasumierzenie.py
2026-05-14T11:56:43.035141000+0200 maurycy@gimel /Users/maurycy/src/github.com/maurycy/cpython (main b6854c5?) % git bisect start main fc3e22a06c9~1 -- Modules/_datetimemodule.c
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[f5685a266b252455e03ef8e6055eaf4007ec749d] gh-80620: Support negative timestamps on windows in `time.gmtime`, `time.localtime`, and `datetime` module (#143463)
2026-05-14T11:57:32.147048000+0200 maurycy@gimel /Users/maurycy/src/github.com/maurycy/cpython  (git)-[v3.15.0a6~249|bisect]?- % git bisect run /tmp/bisekt.sh                                   
running '/tmp/bisekt.sh'
freezegun: ok
Traceback (most recent call last):
  File "/tmp/czasumierzenie.py", line 24, in <module>
    assert datetime.date.today() == DATE
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
Bisecting: 0 revisions left to test after this (roughly 1 step)
[49fb46f555881c9f2d20ca87c8187c8718217c77] gh-139774: use relaxed atomics for datetime hashes (#139775)
running '/tmp/bisekt.sh'
freezegun: ok
Traceback (most recent call last):
  File "/tmp/czasumierzenie.py", line 24, in <module>
    assert datetime.date.today() == DATE
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[fc3e22a06c9b7c93ee379b5554a40a275745e15f] gh-88473: Implement fast path in date.today() for date types (#130980)
running '/tmp/bisekt.sh'
freezegun: ok
Traceback (most recent call last):
  File "/tmp/czasumierzenie.py", line 24, in <module>
    assert datetime.date.today() == DATE
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
fc3e22a06c9b7c93ee379b5554a40a275745e15f is the first bad commit
commit fc3e22a06c9b7c93ee379b5554a40a275745e15f
Author: Stan Ulbrych <[email protected]>
Date:   2025-09-16 10:28:54 +0100

    gh-88473: Implement fast path in date.today() for date types (#130980)
    
    Co-authored-by: Bénédikt Tran <[email protected]>

 .../2025-03-08-17-07-00.gh-issue-88473.qg23g8.rst  |  3 ++
 Modules/_datetimemodule.c                          | 34 +++++++++++++++-------
 2 files changed, 26 insertions(+), 11 deletions(-)
 create mode 100644 Misc/NEWS.d/next/Library/2025-03-08-17-07-00.gh-issue-88473.qg23g8.rst
bisect found first bad commit
2026-05-14T12:01:43.310131000+0200 maurycy@gimel /Users/maurycy/src/github.com/maurycy/cpython  (git)-[bisect/bad|bisect]?- % 

And it's... fc3e22a (cc @picnixz)

cc @adamchainz

ref #130980
ref adamchainz/time-machine#610
ref adamchainz/time-machine#618

Hi @maurycy, sorry for the delay, however I'm reluctant to merge this. It would (probably) break freezegun and other such packages that depend on the monkey-patching. @pganssle what do you think?

FWIW I don't think we can be beholden to how these mocking libraries work. These kinds of libraries is that they are often digging around in the internal implementation details to get themselves to work, so the nature of the beast is that they need to keep up if we break stuff (though if it's basically free for us to not break something then obviously we shouldn't break it just to break it).

If doing something that is a real improvement to the code as it is used makes it impossible to write a library of this type, my intuition is that instead of avoiding breaking them forever, we should shift gears to injecting hooks into the library to give a blessed "we won't break you" abstraction to mocking libraries, but I'm guessing it won't come to that.

These kinds of libraries is that they are often digging around in the internal implementation details to get themselves to work, so the nature of the beast is that they need to keep up if we break stuff

Yes, however, they are quite prominent nowadays, so I think we should give them some consideration. Although I think they could simply switch to using pydatetime to avoid this, so it's not the end of the world.

FWIW I don't think we can be beholden to how these mocking libraries work.

💯 feel free to break time-machine, as long as it's possible to still mock something. I'll fix it up!

But also: this PR will not break it, afaict. time-machine monkey-patches C-level function pointers, which aren't moving around here :)

Documentation build overview

📚 cpython-previews | 🛠️ Build #34278579 | 📁 Comparing e206500 against main (1cbe035)

  🔍 Preview build  

This PR is stale because it has been open for 90 days with no activity.

🤖 New build scheduled with the buildbot fleet by @StanFromIreland for commit e206500 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F148088%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-refleak-buildbots label again.