Re: Proposal: Drop dependency on pytz in favor of zoneinfo

[Carlton Gibson]

Hi Aymeric.

Thanks for inputting!

I need to read in-depth what you’ve said here, but IIUC-at-first-pass: your
suggestion differs in jumping straight to the end-point with a fallback for
those who need it. (In contrast to getting folks to opt-in early if they
want it.) This sounds better if we can.

The Autumn hasn’t allowed time to make progress here but, what did you
think about allowing an early opt-in for Django v3.2? (I’m not sure we have
capacity to get the in in-time now anyway, so it may be moot.)

Kind regards,
Carlton.



On Sat, 2 Jan 2021 at 10:29, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> As the original author of support for timezone aware datetimes in Django,
> I've been meaning to review this... for six months... Better late than
> never I guess?
>
> In this discussion, we're assuming settings.USE_TZ = True.
>
>
> The original design
> , which
> still matches 80% of the current implementation, was very much based on
> advice found in the documentation of pytz. This has three consequences:
>
> 1. By default, users manipulate aware datetimes in UTC, which limits the
> breakage to cases where they explicitly switch to another timezone. This is
> auditable e.g. "look for timezone.activate or timezone.override in your
> code".
>
> 2. Django provides custom wrappers in order to take care of the pitfalls
> of pytz automatically e.g. timezone.make_aware. Backwards-compatibility can
> be implemented transparently there.
>
> 3. A strategy designed for migrating from pytz to zoneinfo should be
> applicable to Django.
>
>
> I'm seeing three areas that need care:
>
> A. APIs returning a tzinfo object, currently a pytz timezone (other than
> UTC — we switched from Django's custom definition of the UTC tzinfo to
> pytz' definition in the past without trouble).
>
> B. APIs returning aware datetimes, currently in a pytz timezone (other
> than UTC).
>
> C. APIs performing datetime conversions in the database, which is
> typically used for aggregating by day in a given timezone. This depends on
> the timezone name. I think we're fine on this front since we're keeping the
> same timezone names.
>
> So the primary concern is leaking pytz tzinfo objects (either directly, or
> via aware datetime objects), to user code that requested it explicitly. I
> may sound like I'm belaboring the point. However, I think we can make a
> better backwards-compatibility decision with an accurate estimate of the
> extent of the breakage.
>
>
> Django currently references pytz in the following places:
>
> - timezone.get_default/current_timezone => see case A above.
> - timezone.get_default/current_timezone_name => shouldn't be an issue
> since time zone names don't change.
> - BaseDatabaseWrapper.timezone => for timezone conversions in Python code
> via make_aware / make_naive; see case B above.
> - BaseDatabaseWrapper.timezone_name => for timezone conversions in the
> database via database-specific SQL functions; see case C above.
>
> With SQLite, the SQL conversion functions are implemented in Python and
> use pytz, but the end result is the same.
>
>
> My suggestion would be:
>
> - Switch everyone to zoneinfo (or backports.zoneinfo) by default in 4.0
> - Provide a temporary, immediately deprecated setting
> USE_PYTZ_DEPRECATION_SHIM in 4.0 and remove it in 5.0
>
> Why?
>
> - Most users don't use timezone.activate, timezone.override, or the
> DATABASES.TIME_ZONE setting to get aware datetimes in a timezone other than
> UTC for the purpose of doing datetime arithmetic in local time. Let's keep
> the upgrade instructions simple for the majority of users! "If you don't do
> anything fancy with timezones, you don't need to worry about this!"
>
> - But some users need a more gradual path, especially those with large
> codebases. Conscious use of pytz_deprecation_shim looks like the best plan
> for them. Since it isn't easy to monkey-patch, let's instruct them to set
> USE_PYTZ_DEPRECATION_SHIM = True so they can upgrade now and fix
> deprecation warning later. This would be Paul's pull request
> , but conditional on the
> setting.
>
> I considered using "can we import pytz_deprecation_shim?" as a signal
> instead of "is USE_PYTZ_DEPRECATION_SHIM set?" but this wouldn't work well
> if pytz_deprecation_shim becomes an indirect dependency. Then shims could
> get accidentally activated and the user wouldn't have a good solution.
>
>
> I hope this helps!
>
> --
> Aymeric.
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1AA84619-74BA-4A7D-A5A8-DC7210885BE9%40polytechnique.org
> 

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

[Aymeric Augustin]

Hi Carlton,

> IIUC-at-first-pass: your suggestion differs in jumping straight to the 
> end-point with a fallback for those who need it. (In contrast to getting 
> folks to opt-in early if they want it.)


Indeed. The majority will switch when the default changes; better earlier than 
later.

> what did you think about allowing an early opt-in for Django v3.2?


The more options we create, the more confusion we may generate e.g. when users 
try to understand release notes or to ask for support. This is why I tried to 
keep options to a minimum (1. initial situation, 2. target situation, 3. with 
shim) and to make as few users as possible go through option 3.

Implementing USE_PYTZ_DEPRECATION_SHIM is Django 3.2 makes the situation a bit 
more complex, as the setting will mean "use pds instead of pytz" in 3.2 and 
"use pds instead of zoneinfo" in 4.0. We'd have four options instead of three.

I'm pretty confident that the transition will go smoothly and I don't think the 
flaws in pytz are bad enough to warrant urgent action. As a consequence, 
offering opt-in in Django 3.2 doesn't seem all that valuable to me.

I'm OK with starting the migration in one year in Django 4.0. I'm also OK with 
offering the opt-in in Django 3.2 if others have a different value assessment!

Cheers,

-- 
Aymeric.



> On 3 Jan 2021, at 09:12, Carlton Gibson  wrote:
> 
> Hi Aymeric. 
> 
> Thanks for inputting! 
> 
> I need to read in-depth what you’ve said here, but IIUC-at-first-pass: your 
> suggestion differs in jumping straight to the end-point with a fallback for 
> those who need it. (In contrast to getting folks to opt-in early if they want 
> it.) This sounds better if we can. 
> 
> The Autumn hasn’t allowed time to make progress here but, what did you think 
> about allowing an early opt-in for Django v3.2? (I’m not sure we have 
> capacity to get the in in-time now anyway, so it may be moot.)
> 
> Kind regards, 
> Carlton.
> 
> 
> 
> On Sat, 2 Jan 2021 at 10:29, Aymeric Augustin 
>  > wrote:
> Hello,
> 
> As the original author of support for timezone aware datetimes in Django, 
> I've been meaning to review this... for six months... Better late than never 
> I guess?
> 
> In this discussion, we're assuming settings.USE_TZ = True.
> 
> 
> The original design 
> , which still 
> matches 80% of the current implementation, was very much based on advice 
> found in the documentation of pytz. This has three consequences:
> 
> 1. By default, users manipulate aware datetimes in UTC, which limits the 
> breakage to cases where they explicitly switch to another timezone. This is 
> auditable e.g. "look for timezone.activate or timezone.override in your code".
> 
> 2. Django provides custom wrappers in order to take care of the pitfalls of 
> pytz automatically e.g. timezone.make_aware. Backwards-compatibility can be 
> implemented transparently there.
> 
> 3. A strategy designed for migrating from pytz to zoneinfo should be 
> applicable to Django.
> 
> 
> I'm seeing three areas that need care:
> 
> A. APIs returning a tzinfo object, currently a pytz timezone (other than UTC 
> — we switched from Django's custom definition of the UTC tzinfo to pytz' 
> definition in the past without trouble).
> 
> B. APIs returning aware datetimes, currently in a pytz timezone (other than 
> UTC).
> 
> C. APIs performing datetime conversions in the database, which is typically 
> used for aggregating by day in a given timezone. This depends on the timezone 
> name. I think we're fine on this front since we're keeping the same timezone 
> names.
> 
> So the primary concern is leaking pytz tzinfo objects (either directly, or 
> via aware datetime objects), to user code that requested it explicitly. I may 
> sound like I'm belaboring the point. However, I think we can make a better 
> backwards-compatibility decision with an accurate estimate of the extent of 
> the breakage.
> 
> 
> Django currently references pytz in the following places:
> 
> - timezone.get_default/current_timezone => see case A above.
> - timezone.get_default/current_timezone_name => shouldn't be an issue since 
> time zone names don't change.
> - BaseDatabaseWrapper.timezone => for timezone conversions in Python code via 
> make_aware / make_naive; see case B above.
> - BaseDatabaseWrapper.timezone_name => for timezone conversions in the 
> database via database-specific SQL functions; see case C above.
> 
> With SQLite, the SQL conversion functions are implemented in Python and use 
> pytz, but the end result is the same.
> 
> 
> My suggestion would be:
> 
> - Switch everyone to zoneinfo (or backports.zoneinfo) by default in 4.0
> - Provide a temporary, immediately deprecated setting 
> USE_PYTZ_DEPRECATION_SHIM in 4.0 and remove it in 5.0
> 
> Why?
> 
> - Most users don't use timezone.activate, timezone.override, or the 
> DATABASES.TIME_ZONE setting to get aware datetimes

This should be taken in consideration : ordering variable in ListView Class

[AMINE ART]

Can get you every post if you fill it
I comment it to get only the user posts

class UserPostsListView(ListView):
model = Post
template_name = 'posts/pages/index.html'
context_object_name = 'posts'
#That line can ruine everything
#ordering = ['-date_posted']
paginate_by = 1

def get_query_set(self):
username = self.kwargs.get('username')
   user = get_object_or_404( User.objects.get(User, username=username) )
   return Post.objects.filter(author=user).ordered_by('-date_posted')

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4ab6c581-360a-4588-b1df-58398168afb6n%40googlegroups.com.

Re: GitHub Actions

[Tom Forbes]

Sorry for bumping such an old thread, but I've created a github actions POC 
and written it up here: 
https://forum.djangoproject.com/t/improving-the-contribution-experience-with-github-actions/5964

On Monday, 11 November 2019 at 08:11:57 UTC Johannes Maron wrote:

> Hi Mariusz, 
>
> Cool, let me know if you have any questions about the config file that I 
> wrote. I am happy to help :)
>
> Regarding the output, yes I can feel you. However I don’t know if we 
> really need to run tests at verbosity level 2 on CI. One can always do that 
> online or enable it if need be.
>
> At list of tests that failed in a human readable output format would be 
> nice. GitHub supports annotation on checks, but it's not really convenient 
> yet to be used.
>
> Using it for linters is a good start. We could also do the docs build and 
> limit that one to be only build if the docs actually changed. You can 
> trigger builds based on file condition 
> ,
>  
> which is pretty neat.
>
> Something that we also haven’t explored are scheduled builds. Those could 
> be helpful to do regression tests on especially on dependencies.
>
> Anyhow, love to see where this is going.
> -Joe
> On 11. Nov 2019, 15:53 +0900, Mariusz Felisiak , 
> wrote:
>
>
> I would suggest to open a PR to GitHub now and to get the Fellows 
>> involved. Ask them how to best integrate a trial without disturbing their 
>> workflow. What do you guys think?
>>
>>
> I'm going to play with GitHub actions in this week (or in the next one) 
> but I'm still not convinced. It's fine to use them for linters, but for 
> more complicated jobs it generates output that is less readable, IMO. You 
> don't get a formatted table but a raw output, so you have to scroll down 
> ~20k lines to check what went wrong. This can be really frustrating 
> especially with more then one failure. Nevertheless I'm going to play with 
> it.
>
> Best
> Mariusz
>
>
> --
> You received this message because you are subscribed to a topic in the 
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/django-developers/xDCmZPLTOQQ/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to 
> django-develop...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/6692d50f-b02d-4824-aa12-be22a20c3f0f%40googlegroups.com
>  
> 
> .
>
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0c944a34-6c73-457b-a860-a8b355589113n%40googlegroups.com.