Author p-ganssle
Recipients ezio.melotti, p-ganssle, serhiy.storchaka, shihai1991, vstinner
Date 2020-06-26.14:58:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1593183525.41.0.169812902168.issue40799@roundup.psfhosted.org>
In-reply-to
Content
As for deciding between moving to `datetime/` and moving to `_pydatetime`, I think we should send an e-mail to Python-Dev about it to get a wider perspective, because the import machinery is a lot of black magic, and I know that there are large proprietary code bases out there that pile weird stuff on top of it. I'm not sure I can fully appreciate the trade-offs.

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. For example, in `zoneinfo`, we have zoneinfo/_common.py (https://github.com/python/cpython/blob/2e0a920e9eb540654c0bb2298143b00637dc5961/Lib/zoneinfo/_common.py), which is some logic shared between the C and Python implementations; `_zoneinfo.c` is able to rely directly on `_common.py` without importing `zoneinfo/_zoneinfo.py` (which saves us a bunch of other module imports as well).

Right now the C implementation of `datetime` only directly imports `time` and `_strptime`, but I could imagine future enhancements that would be stupidly inconvenient to implement in C, but where we wouldn't want to implement all of _pydatetime just to get a pure-Python implementation. Having a namespace available for such packages would be useful.
History
Date User Action Args
2020-06-26 14:58:45p-gansslesetrecipients: + p-ganssle, vstinner, ezio.melotti, serhiy.storchaka, shihai1991
2020-06-26 14:58:45p-gansslesetmessageid: <1593183525.41.0.169812902168.issue40799@roundup.psfhosted.org>
2020-06-26 14:58:45p-gansslelinkissue40799 messages
2020-06-26 14:58:45p-gansslecreate