This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author p-ganssle
Recipients ezio.melotti, p-ganssle, serhiy.storchaka, vstinner
Date 2020-05-28.14:39:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1590676750.24.0.854141439341.issue40799@roundup.psfhosted.org>
In-reply-to
Content
I basically agree with this — this is one of the reasons I structured the zoneinfo module the way I did rather than mimicking the pattern in datetime.

I believe that there are other modules that have similar situations like heapq, but datetime is probably the worst offender.

I am inclined to say that we should restructure datetime into a folder, containing __init__.py, _datetime.py and possibly _strptime.py (which I think is also only used in datetime), but I think that sort of restructuring is way more sensitive to weird import bugs than this one.

As it is now, I would be shocked if this didn't break *someone*, because people are always relying on weird implementation details (knowingly or unknowingly), but I think it's worth doing; it's good to tackle it this early in the cycle.

@vstinner What do you think about restructuring into a folder-based submodule rather than _pydatetime.py? It's way more likely to break someone, but I think it might be the better way to organize the code, and I don't want to have to go through *two* refactors of this sort.
History
Date User Action Args
2020-05-28 14:39:10p-gansslesetrecipients: + p-ganssle, vstinner, ezio.melotti, serhiy.storchaka
2020-05-28 14:39:10p-gansslesetmessageid: <1590676750.24.0.854141439341.issue40799@roundup.psfhosted.org>
2020-05-28 14:39:10p-gansslelinkissue40799 messages
2020-05-28 14:39:10p-gansslecreate