Exporting some of the `datetime` functions from `django.utils.timezone`

[suayip uzulmez]

Most of the time I use `timezone.now` in conjunction with `timezone.timedelta`, however, today I realized it was not publicly exported in the module.

Most of the time,  using it saves an import from `datetime` (e.g., timezone.now + timezone.timedelta is a common pattern). I presume this use case is a common one among Django developers. I made a quick Stack Overflow search, which yielded 100+ results:

https://stackoverflow.com/search?q=timezone.timedelta+%5Bdjango%5D

Then I thought, why stop there? Usage of `timezone.datetime` would possibly reduce the `datetime` imports to zero in some Django projects. However it is not used as much, as you can imagine:

https://stackoverflow.com/search?q=timezone.datetime+%5Bdjango%5D

I would say we should at least consider exporting `timedelta` What do you think?

[Mariusz Felisiak]

Hi,

> I would say we should at least consider exporting `timedelta` What do you think?

I'm strongly against it. Things should be imported from source modules, not cross-imported from Django modules just because we use them. This is confusing to the users who might have the impression that `django.utils.timezone.timedelta` is more than `datetime.timedelta`, which is not True.

Best,
Mariusz

[Jacob Rief]

I find it confusing that we have to import now from django.utils.timezone, but timedelta from Python's internal datetime.

This btw. is a violation of the Law of Demeter, hence I agree with Suayip's proposal.

– Jacob

[Mariusz Felisiak]

I find it confusing that we have to import now from django.utils.timezone, but timedelta from Python's internal datetime.

This btw. is a violation of the Law of Demeter, hence I agree with Suayip's proposal.

– Jacob

There is a big difference between `now()` and `timedelta`, `django.utils.timezone.now` is defined in Django it is not the same as `datetime.now`. Unlike, `timedelta` would be always Python's `datetime.timedelta`. Following this proposition, we should reintroduce most of the standard Python libraries in the django.utils modules 🤯 TBH, we're trying to do the exact opposite and remove all aliases, e.g. https://github.com/django/django/commit/d6816bff73b37af05c968c009419c7c608e37307

I remember a discussion where a user tried to convince me that `django.utils.timezone.datetime` is not the same as `datetime.datetime` and that Django is definitely adding some magic here and I have to use `datetime` from Django. This is of course not true.

Best,
Mariusz

[Adam Johnson]

I agree with Mariusz. Encouraging alternative import paths for standard library functions can only lead to confusing code.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/40cce83a-4967-4a6c-9ae2-7e15386814dcn%40googlegroups.com.

[Bogdan Barna]

Agree with Mariusz and Adam. The 2 modules are not the same. At most, we can say `django.utils.timezone` has an unfortunate naming.

Just my 2c.