Victor Stinner

About \_strptime, I see that the time.strptime() imports internally the \_strptime module. If we move \_strptime inside datetime: does it mean that calling time.strptime() would have to import the datetime...

I don't have the bandwidth to work on this issue, so I just close it.

> It is still a valid issue Well, I made a first attempt in 2020: PR #20472 which it went nowhere. Let me re-create the change: PR #99090. It's basically...

> The biggest advantage I see to moving datetime into its own folder is that it gives us a lot more freedom to expand into smaller sub-modules in the future....

Ok, I wrote a more elaborated script to measure ``import datetime``: ```py import pyperf import sys def bench_import_datetime(modules): import datetime del modules["datetime"] del modules["_datetime"] modules.pop("time", None) modules.pop("math", None) modules.pop("operator", None)...

By default, ``git log Lib/_pydatetime.py`` only shows my commit as if I created it from scratch. But ``git log --follow Lib/_pydatetime.py`` works as expected and shows 81 commits up to:...

For miss-islington, I did a test locally. I create a local bugfix from my PR ``pydatetime`` branch: ``` $ git switch -c pydatetime_bugfix $ vim $ git diff diff --git...

Another test where the rename is a dedicated commit. Spoiler: not good, I get the same conflict on backport. First commit, only to rename: ``` $ git switch -c clean_pydatetime...

For me, the quick conclusion is that we have 2 choices: * **No change**: keep 2642 lines of Python code in datetime.py * Create Lib/_pydatetime.py and **backport manually** changes from...

> Create Lib/_pydatetime.py and backport manually changes from 3.12 to 3.11, and then rely on miss-ilington to automate the backport from 3.11 to 3.10 In clear, I'm in favor of...