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

Hi Carlton, Sorry I didn't reply on the PR about advancing anything for 3.2. I ran out of capacity and at this late stage it is best to wait until 4.0 anyway. I see that Aymeric is in favour of forging ahead to use zoneinfo in 4.0 as was my preference, but with the addition of an opt-out

Re: Status of 3.2 release blockers.

Hi Carlton, Just wondering if you're still willing to accept the following for 3.2: - https://code.djangoproject.com/ticket/16117 - https://github.com/django/django/pull/13532 Adam marked it "ready for checkin" about 6 weeks ago. Cheers, Nick On Wednesday, 6 January 2021 at 10:04:18

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

Hi Carlton, Thanks for coming back to this. Your reasoning makes a lot of sense. I too think it'll be good not to land this in 3.2 LTS and focus on making any changes in 4.0. The question is then which path we choose to take: 1. The deprecation route using pytz_deprecation_shim in 4.0

Re: f-strings again.

Hi, So I'm in favour of using f-strings, but agree that there are places where they are not appropriate. I am also against bulk updates in this case as mentioned in my previous comment . I don't think we should exclude

Re: HttpResponse headers interface

I would agree that `response.headers` *is* by far clearer especially to those not familiar with Django or coming from other frameworks. As Tom says, we only visually know that setting a key on a response object is for headers because of the key name itself, e.g. "Content-Type". I also think

Re: Adding ability to choose AutoField type (signed vs unsigned)

Ah. I hadn't thought about that - only got as far as being able to define a new default value in DEFAULT_AUTOFIELD in the start project template so that existing projects are not suddenly forced to migrate. An alternative is to have something on the AppConfig. I'm sure for most people the

Re: Python version support for LTS Django (in particular v2.2)

I think that the main reason for supporting Python 3.7 in Django 1.11 was to help make things easier for those migrating from Python 2 to 3. Python 3.8 was only released ~3 months before the Python 2 EOL, so most people in the last year and up to the end of this year will likely migrate to

Re: Looking for feedback on implementation of UserManager.with_perm()

Hi Berker, I just wanted to highlight my comment on the PR here for the benefit of those discussing this: https://github.com/django/django/pull/7153#issuecomment-242672721 We currently horribly abuse the existing permission system to add additional global permissions in a hacky way by

[1.4] SECRET_KEY deprecation is confusing...

Hi, There is a problem in 1.4rc2 where a missing SECRET_KEY causes Django to refuse to start. According to the current version of the release notes on the website: *In Django 1.4, starting Django with an empty SECRET_KEY will raise a DeprecationWarning. In Django 1.5, it will raise an