Consider "hiding" datetime/zoneinfo imports in django.utils.timezone

[Jaap Roes]

During code review I've seen people using from django.utils.timezone import datetime (and variations) on multiple occasions. Sometimes because their IDE just autocompletes that import, sometimes under the false assumption that these are a timezone aware variation of the stdlib's datetime implementation.

The most recent iteration I came across can be seen here: ​https://github.com/SmileyChris/easy-thumbnails/pull/579#discussion_r729003666

Because importing datetime, timedelta, zoneinfo etc. from a module called timezone "looks" reasonable people seem to assume that these are valid imports and sometimes even assume these are Django specific implementations.

An easy way to discourage these imports is aliasing them, i.e.:

import datetime as _datetime
import zoneinfo as _zoneinfo

I'm aware Django (or any Python project) is full of potential incorrect import opportunities. But this one seems to pop up fairly regularly in my experience and when combined with incorrect assumptions about what is being imported can be a root cause of subtle bugs.

[Mariusz Felisiak]

I'm aware Django (or any Python project) is full of potential incorrect import opportunities. But this one seems to pop up fairly regularly in my experience and when combined with incorrect assumptions about what is being imported can be a root cause of subtle bugs.

Thanks for this suggestion, however __all__ is already defined in the django.utils.timezone and none of it is documented. IMO there is nothing we can do anything to stop folks from making false assumptions, adding underscores won't help.

"wontfixed" generally not only in this case. There are many modules where we may receive similar requests, e.g. from django.utils.archive import tarfile.