STINNER Victor <vstin...@python.org> added the comment:
> I believe that there are other modules that have similar situations like > heapq, but datetime is probably the worst offender. heapq seems to be a little bit different. _heapq is not a drop-in replacement of heapq.py. For example, nlargest() seems to only be implemented in pure Python. > 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. I have no idea what are the side effects of converting datetime.py file into a package. A single file _pydatetime.py seems more convenient to me. I'm aware of _strptime.py but I don't see it as a datetime submodule and I don't see the value of moving it as a datetime submodule. I'm fine with _datetime accessing _strptime module. It sounds more complex to me if _datetime would be imported by datetime which contains datetime._strptime. I see a higher risk of subtle import issues, since datetime has two implementations (C and Python). But it may be wrong :-) Also, all other stdlib modules which have a C implementation are designed with files, not folders: io.py (_io and _pyio) and decimal.py (_decimal and _pydecimal) are good examples. I mostly case about reducing the number of indirect imports and import performance. I don't have a strong opinion about file vs folder. > 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. I'm fine with breaking applications relying on implementation details. Also, we can adjust the code to fix such corner cases later if it's needed, possible and justified :-) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue40799> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
