[Django] #33200: Consider "hiding" datetime/zoneinfo imports in django.utils.timezone

[Django]

#33200: Consider "hiding" datetime/zoneinfo imports in django.utils.timezone
-------------------------------------+-------------------------------------
Reporter: Jaap Roes | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Utilities | Version: dev
Severity: Normal | Keywords: timezone datetime
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
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.

--
Ticket URL: <https://code.djangoproject.com/ticket/33200>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#33200: Consider "hiding" datetime/zoneinfo imports in django.utils.timezone
-------------------------------------+-------------------------------------
Reporter: Jaap Roes | Owner: nobody

Type: | Status: closed

Cleanup/optimization |
Component: Utilities | Version: dev

Severity: Normal | Resolution: wontfix

Keywords: timezone datetime | Triage Stage:

| Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Mariusz Felisiak):

* status: new => closed
* resolution: => wontfix

Comment:

> 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`.

--
Ticket URL: <https://code.djangoproject.com/ticket/33200#comment:1>