[1.4] SECRET_KEY deprecation is confusing...

[Nick Pope]

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 exception and Django 
will refuse to start.*
*
*
This doesn't make sense...  It currently raises DeprecationWarning which is 
an exception which causes Django to fail to start.  To trigger a 
deprecation warning while allowing execution to continue you need to use 
warnings.warn().

As things stand you are essentially implementing the behaviour for both 1.4 
*and* 1.5!

Cheers,

Nick

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/lYpYVlaGlZYJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Nick Pope]

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 large tables that may need this will be in their own, rather than 
third-party, apps. People can also choose to set this for a third-party app by 
subclassing the AppConfig, but as you say, they'd then be forced to handle 
migrations manually - is this even avoidable? I'm not sure how this would look 
for moving to a new default though.

-- 
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/dfb45121-8ce6-4d6b-8505-5831778e4c3f%40googlegroups.com.

Re: HttpResponse headers interface

[Nick Pope]

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 
that having `response.headers` brings a symmetry with `request.headers` 
that makes it easier for developers to remember how this all works. I am 
all for being concise, but I don't hold to the argument that the something 
isn't to be preferred just because it is more verbose and you "know" 
Django. The addition of ".headers" is hardly excessively verbose.

I think there has to be a balance struck between making things more 
accessible for developers that are new to Django and those that are 
long-time developers who need to maintain their existing code. There is 
always going to be some contention between satisfying both camps. I 
understand that there are the concerns raised referencing the API stability 
policy that there should be "one way to do it", but it does come with 
various provisos, e.g. "(eventually)" and "very high priority" (which *also* 
does not equal "the only priority" -  it isn't absolute).

In addition, I can highlight places with multiple ways of doing things, 
e.g. `Field.choices` with the ability to use enumeration classes or not, 
`Meta.indexes` or the not-yet-deprecated and only lightly discouraged 
`index_together` and `unique_together`, etc. While I think that "one way to 
do it" is an admirable goal, I don't think that we need to be quite so 
militant at adhering to that principle. Maybe this has originated from the 
Zen of Python, but even that states "There should be one-- and preferably 
only one --obvious way to do it." I see that as meaning "it is preferable 
to have one obvious way to do it" but not discounting multiple ways if that 
cannot be achieved or is undesirable.

If we're going to be driven forcibly by these principles it comes down to a 
tussle between Python's "obvious" - undisputedly `response.headers` - and 
Django's "superior" - well, arguably, neither, unless we choose clarity 
(`response.headers`) or Python's data model as what makes something 
"superior". In that regard we have a contradiction if we were to choose 
Python's data model as the "superior" solution as Python - or at least the 
"Zen of Python" - commends what is "obvious".

I honestly thought the approach Carlton mentioned in 
https://github.com/django/django/pull/13186#discussion_r454956921 struck 
the correct balance and we could even, if desired, highlight in the release 
notes for the new `response.headers` that the old approach has not gone 
away such that developers do not need to rush to update their code. As 
highlighted by the examples above, it feels like there is precedent for 
that. Also if the data model approach is plumbed in to use `.headers` as in 
the proposed implementation, I don't see this as being a burden to maintain.

Please let's be pragmatic about this stuff and not be driven to adhering to 
"one way to do it" as an extremist ideology rather than a laudable 
preference.
On Thursday, 16 July 2020 at 14:58:39 UTC+1 carlton...@gmail.com wrote:

> The concern is the backwards incompatibility. 
>
> I do see the reasons for the new approach. I accept that it’s easier to 
> grok if you don’t know Django already — “principal of least astonishment” I 
> think you opened with. 
>
> I just can’t balance those gains against forcing a change on the entire 
> community. It just doesn’t balance. (And being negative, as soon as you do 
> know Django the new proposal is more verbose, so not to be preferred.)
>
> I had thought that it would be additive but the API stability policy is 
> quite clear on the “one way of doing things”.
>
> Thus, as much as I do like the idea, I don’t think we can do this. 
>
> On Thu, 16 Jul 2020 at 15:39, Tom Carrick  wrote:
>
>> Hmm. I do think that Python's data model is a Good Thing. Where we might 
>> disagree is that I don't think this is an appropriate use of it.I'll try to 
>> illustrate with an example. Consider this code:
>>
>> response = HttpResponse()
>> response['foo'] = 'bar'
>>
>> Now, if I try to look at this code without context, putting my Django 
>> knowledge to the back of my head, intuitively, this doesn't look like I'm 
>> setting a header. To me it actually looks more like my response is JSON 
>> (increasingly common these days) and I'm setting the 'foo' key on it to 
>> 'bar'. Now, is this likely to happen and cause confusion? Probably not, 
>> since we tend to spell out our headers such as Content-Type rather than 
>> content-type, and custom headers tend to be prefixed with 'X-'. But I do 
>> think there is potential confusion, especially to beginners or perhaps 
>> people who know a little frontend development and expect any request to 
>> return JSON, and perhaps haven't had to interact with headers as their 
>> libraries take care of them

Re: f-strings again.

[Nick Pope]

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 replacing .format() with f-strings on a 
case-by-case basis, however, where performance is a concern.

Thanks for your initial documentation, Carlton. Am wondering whether we 
should be more explicit about the pros and cons of each to help people make 
the correct decision? Here are my thoughts:

%-formatting:

+ Simple to use printf-style familiar to all.
+ Default (can be changed 
) 
style used internally by the logging module, e.g. logging.info('Message 
with %s.', value)
− Much less flexibility for formatting, see pyformat.info.

``.format()``:

+ Useful for interpolating a stored template string, e.g. from a database, 
which isn't possible with f-strings.
− Worst performance due to method call.
− Much more verbose, makes code less readable.

f-strings:

+ Better performance than other methods due to dedicated FORMAT_VALUE 
 opcode.
+ Allows for embedding more complex expressions, e.g. f'Hello 
{user.get_full_name()}'
+ Much more concise, makes code more readable.
− Cannot be used if string must be translated.
− Complex expressions can get out of control. A sensible balance needs to 
be struck.

Regarding performance, here are some simple numbers:

python -m timeit -s 'x="test"' 'f"{x}"'
2000 loops, best of 5: 11.8 nsec per loop
$ python -m timeit -s 'x="test"' '"%s" % x'
1000 loops, best of 5: 39.1 nsec per loop
$ python -m timeit -s 'x="test"' '"{}".format(x)'
500 loops, best of 5: 76.1 nsec per loop

I think it is probably also worth updating the documentation added in this 
commit 
.
 
It isn't that xgettext doesn't support f-strings... It does:

$ echo "_('Hello %s') % user.username" | xgettext --language=python 
--omit-header --output=- -
#: standard input:1
#, python-format
msgid "Hello %s"
msgstr ""
$ echo "_('Hello {}').format(user.username)" | xgettext --language=python 
--omit-header --output=- -
#: standard input:1
msgid "Hello {}"
msgstr ""
$ echo "_('Hello {name}').format(name=user.username)" | xgettext 
--language=python --omit-header --output=- -
#: standard input:1
#, python-brace-format
msgid "Hello {name}"
msgstr ""
$ echo "_(f'Hello {user.username}')" | xgettext --language=python 
--omit-header --output=- -
#: standard input:1
#, python-brace-format
msgid "Hello {user.username}"
msgstr ""
$ echo "_(f'Hello {user.get_full_name()}')" | xgettext --language=python 
--omit-header --output=- -
#: standard input:1
msgid "Hello {user.get_full_name()}"
msgstr ""

It is actually that Python doesn't support modifying the template string 
prior to interpolating the values which is the requirement for injecting 
the translated string. PEP 498  
makes no explicit mention of this. PEP 501 
 was initially looking at 
solving the problem but was deemed a poor fit and was also deferred.

Kind regards,

Nick
On Tuesday, 21 July 2020 at 08:28:54 UTC+1 Mariusz Felisiak wrote:

> Hi y'all,
>
> I will not stand against f-strings, I think we can allow them. My main 
> concerns is readability. f-strings are powerful and it's quite common that 
> they are used with functions calls and complex formatting which makes code 
> hard to understand and maintain, *"With great power comes great 
> responsibility" ...*
>
> I'm strongly against any bulk updates to conform to this style. This 
> will just create unnecessary noise in the history, I know that there are 
> tools, please don't start this discussion again :)
>
> I would also be in favor of keeping only %-formatting and f-strings in 
> Coding style docs. I don't see any reason to use also `format()` in a new 
> code.
>
> Best,
> Mariusz
>

-- 
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/ceba9695-9d21-436f-84b5-53381aa3ea15n%40googlegroups.com.

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

[Nick Pope]

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 changing to 
   zoneinfo in 5.0
   2. Just make a hard break to zoneinfo in 4.0 replacing the pytz dependency 
   with backports.zoneinfo;python_version<"3.9"

If I'm honest, I actually prefer the second option for the following 
reasons:

   - It avoids having to go through the rigmarole of updating this stuff 
   twice. One release with big shouty warnings is better than two.
   - People jumping from 3.2 LTS to 4.2 LTS to 5.2 LTS will still have two 
   "consecutive" releases fiddling with this.
   - When Django 5.0 is released in January 2024, we'll still need to use 
   the backport as Python 3.8 isn't retired until October 2024.
   - We don't need to introduce, maintain, deprecate, and remove any extra 
   settings for choosing the pytz vs zoneinfo.
   - As Paul mentioned, most people are probably not using pytz's 
   .normalize() properly anyway...

The disadvantage is that users have to make a major change. But they're 
going to have to sooner or later anyway.
Using the shim doesn't stop them from having to rewrite their code a second 
time to switch over to zoneinfo.
With good documentation and examples on how to migrate, I think it would be 
a better approach.

On a final note, I'd like to say thank you to Paul for fixing this major 
timezone handling wart. I'm looking forward to life becoming much easier!

Kind regards,

Nick

On Wednesday, 7 October 2020 at 16:26:21 UTC+1 Paul Ganssle wrote:

> This sounds like a reasonable timeline to me. I think the breakage will be 
> relatively small because I suspect many end-users don't really even know to 
> use `normalize` in the first place, and when introducing the shim into a 
> fundamental library at work I did not get a huge number of breakages, but I 
> am still convinced that it is reasonably categorized as a breaking change.
>
> I do think that there's one additional stage that we need to add here (and 
> we chatted about this on twitter a bit), which is a stage that is fully 
> backwards compatible where Django supports using non-pytz zones for users 
> who bring their own time zone. I suspect that will help ease any breaking 
> pain between 3.2 and 4.0, because no one would be forced to make any 
> changes, but end users could proactively migrate to zoneinfo for a smoother 
> transition.
>
> I think most of what needs to be done is already in my original PR, it 
> just needs a little conditional logic to handle pytz as well as the shim.
>
> I am not sure how you feel about feature flags, but as a "nice to have", I 
> imagine it would also be possible to add a feature flag that opts you in to 
> `zoneinfo` as time zone provider even in 3.2, so that people can jump 
> straight to the 5.0 behavior if they are ready for it.
>
> I should be able to devote some time to at least the first part — making 
> Django compatible with zoneinfo even if not actively using it — but likely 
> not for a few weeks at minimum. If anyone wants to jump on either of these 
> ahead of me I don't mind at all and feel free to ping me for review.
>
> Best,
> Paul
> On 10/7/20 10:48 AM, Carlton Gibson wrote:
>
> Hi Paul.  
>
> Thanks for the input here, and for your patience 
>
> > I am fairly certain this is going to be a tricky migration and will 
> inevitably come with *some* user pain. I don't think this will be Python 
> 2 → 3 style pain, but some users who have been doing the "right thing" with 
> pytz will need to make changes to their code in the long run, which is 
> unfortunate.
>
> Looking at all the docs, your migration guide on pytz_deprecation_shim, 
> the example Kevin gave , 
> where we do some arithmetic in a local timezone, and call `normalize()` in 
> case we crossed a DST boundary, there's no way we can do this without 
> forcing a breaking change somewhere.
>
> So, probably, I've been staring at this too long today, but I think we 
> should introduce the shim in Django 4.0. Django 3.2, the next major release 
> will be an LTS. If we hold-off introducing the change until 4.0, we can 
> flag it as a breaking change in the 4.0 release notes, with big warnings, 
> allowing folks extra time to hang out on the previous LTS if they need it. 
>
> What I wouldn't want to do is to bring the breaking change in in Django 
> 3.2, because we'll have a whole load of folks updating from the 2.2 LTS at 
> about the time when it goes End of Life, and with no warning, that'd be a 
> hard breaking change to throw on top of their other issues. 
>
> We'd keep the shim in place for the entire 4.x series, removing in Django 
> 5.0 as per the deprecation policy 
> 

Re: Status of 3.2 release blockers.

[Nick Pope]

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 UTC carlton...@gmail.com wrote:

> Hey Florian. 
>
> OK +1, no problem. 
>
> > Let me know if I can help somewhere else in exchange ;)
>
> Super. 
>
> On Wednesday, 6 January 2021 at 10:31:54 UTC+1 f.apo...@gmail.com wrote:
>
>> Hi Carlton,
>>
>> I'd like to put 
>> https://github.com/django/django/pull/12553
>> https://github.com/django/django/pull/13800
>>
>> onto this list as well. They are imo basically finished and I'd love 
>> reviews from our fellows. Let me know if I can help somewhere else in 
>> exchange ;)
>>
>> Cheers,
>> Florian
>>
>> On Monday, January 4, 2021 at 10:56:42 AM UTC+1 carlton...@gmail.com 
>> wrote:
>>
>>> Hi all,
>>>
>>> Happy New Year! 
>>>
>>> Time to begin release process for the next major release, Django 3.2!
>>>
>>> Reference: https://code.djangoproject.com/wiki/Version3.2Roadmap
>>>
>>> The 3.2 feature freeze is scheduled for January 14. 
>>> We'll probably release the alpha that day.
>>>
>>> We have a few larger patches we want to finish reviewing:
>>>
>>> https://github.com/django/django/pull/11929 - Fixed #26167 -- Added 
>>> support for functional indexes.
>>> https://github.com/django/django/pull/13618 - Fixed 30360 -- Support 
>>> rotation of secret keys.
>>> https://github.com/django/django/pull/13435 - Fixed #32018 -- Extracted 
>>> admin colors into CSS variables.
>>> https://github.com/django/django/pull/11026 - Fixed #29010, Fixed 
>>> #29138 -- Added limit_choices_to and to_field support to autocomplete 
>>> fields.
>>>
>>> We'll update this thread for any schedule changes. 
>>>
>>> Kind regards, 
>>> Carlton
>>>
>>

-- 
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/31c418ca-438d-4c75-b550-31272c9024a0n%40googlegroups.com.

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

[Nick Pope]

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 falling back to the 
deprecation shim.

I'm also +1 for this approach, rather than an opt-in. I don't think it is a 
bad idea to promote this and get people to think about it sooner rather 
than later.
For those with complex and/or significant use of  pytz's API, there is then 
the option to opt-out and have another two or three releases to address the 
issue.

Cheers,

Nick

On Tuesday, 5 January 2021 at 12:20:18 UTC wksch...@gmail.com wrote:

> Just wanted to chime in with a +1 from a user in favor of moving away from 
> pytz. Doing so will be very helpful for frozen Python environments: 
> https://bugs.launchpad.net/pytz/+bug/1834363
>
> On Sunday, January 3, 2021 at 2:43:01 AM UTC-6 Aymeric Augustin wrote:
>
>> 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 <
>> aymeric@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 tha

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

[Nick Pope]

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 Python 3.7.

I also feel the policy was a little aggressive given that the total change 
to support Python 3.7 was 
https://github.com/django/django/compare/216398d1...c11a7b4

So +1 to Python 3.8 for Django 2.2, with an option on Python 3.9 if trivial.

On Wednesday, 30 October 2019 14:44:20 UTC, Carlton Gibson wrote:
>
> Hi all. 
>
> In November last year we added official Python 3.7 support to Django 1.11.
>
> https://groups.google.com/d/topic/django-developers/H7fP5w0YU2I/discussion
>
> This was 18 months after release, and well into the extended support 
> period. 
>
> There had been a long-line of requests to add that support. It seems that 
> lots of users want both the latest 
> Python and the Django LTS. 
>
>
> Django 2.2 officially only supports Python 3.8. 
>
> Python 3.8 is already available. 
>
> Python 3.9 will be available Oct 2020, which is a ≈18months before 2.2. is 
> EOL, and is roughly equivalent to when we added support for Python 3.7 to 
> Django 1.11. 
>
>
> I predict a similarly strong demand to support the newer Python versions 
> in Django 2.2. 
>
> I'm happy to take whatever line we deem appropriate here, but I'd like to 
> avoid, for example, saying "No, it's not supported" for many months, before 
> then changing our minds. 
>
> So what shall we do? 
>
> Django 2.2 is still in mainstream support and I think it should 
> automatically get Python 3.8 support. 
> I think version of Django should support the new Python versions whilst in 
> mainstream support, but I think this applies doubly to the LTS, even though 
> the LTS isn't my thing, simply because of the demand for it. 
>
> Data point: I didn't test the full matrix but, tests are already passing 
> here. 
>
> For Python 3.9 I think we should probably declare now that we will review 
> whether we will support it for 2.2 LTS when it's released. 
> (i.e. if it's a small back port like the one required for 3.7/1.11 then 
> yes, otherwise no.) 
>
>
> What do we think? 
>
> Thanks 
> Kind Regards,
>
> Carlton
>
>

-- 
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/613aee69-1d8b-445c-a64b-0917eed976a7%40googlegroups.com.

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

[Nick Pope]

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 manually adding content 
types. (https://code.djangoproject.com/ticket/24754 would be awesome) 

My scenario is simply having an easy method to find users *and* groups with 
a particular permission or set of permissions. Doing so is rather clunky at 
the moment.
I also feel that any solution should have the ability to optionally 
include/exclude by is_superuser and is_active flags - we often want to know 
who has a permission whether implicit or explicit.

Thanks,

Nick

On Wednesday, 14 September 2016 05:10:41 UTC+1, Berker Peksag wrote:
>
> https://github.com/django/django/pull/7153/ implements 
> UserManager.with_perm() [1] as: 
>
> def with_perm(self, perm): 
> for backend in auth.get_backends(): 
> if hasattr(backend, 'with_perm'): 
> return backend.with_perm(perm) 
> return self.get_queryset().none() 
>
> [1] "Shortcut to get users by permission": 
> https://code.djangoproject.com/ticket/18763 
>
> With this implementation, users of UserManager.with_perm() won't get 
> users with permissions for all backends. Also, result of 
> UserManager.with_perm() will depend on the order of 
> settings.AUTHENTICATION_BACKENDS. See also 
> https://code.djangoproject.com/ticket/18763#comment:9 for more 
> information about the current strategy. 
>
> I suggested an alternative approach at 
> https://github.com/django/django/pull/7153/files#r78226234 with the 
> following implementation: 
>
> def with_perm(self, perm, backend=None): 
> if backend is None: 
> backends = _get_backends(return_tuples=True) 
> if len(backends) != 1: 
> raise ValueError( 
> 'You have multiple authentication backends configured 
> and ' 
> 'therefore must provide the `backend` argument.' 
> ) 
> _, backend = backends[0] 
> if hasattr(backend, 'with_perm'): 
> return backend.with_perm(perm) 
> else: 
> backend = load_backend(backend) 
> if hasattr(backend, 'with_perm'): 
> return backend.with_perm(perm) 
> return self.get_queryset().none() 
>
> This also simulates what django.contrib.auth.login() does when 
> multiple authentication backends are defined: 
>
>
> https://github.com/django/django/blob/18c72d59e0807dae75ac2c34890d08c1e0972d0a/django/contrib/auth/__init__.py#L100
>  
>
> Tim suggested to get some feedback about possible use cases: 
>
> "I'm not sure about the use cases. For example, someone might want to 
> get users with permissions for all backends. It would be nice if we 
> had some feedback about what users are implementing on their own to 
> confirm we're targeting the largest use case." 
>
> Is there any other possible use cases? Which one of the suggested 
> approaches cover the largest use case? 
>
> Thanks! 
>
> --Berker 
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c5249500-d576-44ab-b38a-78ac22866782%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.