Django bugfix release: 3.2.8

[Carlton Gibson]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2021/oct/05/bugfix-release/ 


-- 
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/51B45B77-42FE-4E3A-A7F8-330B9D10F4FA%40gmail.com.

Re: Custom Groups model and interoperability

[Scot Hacker]

No official (or semi-official) position on this? Is "The right way to 
create custom Groups" simply undefined in Django? 

Thanks.


On Sunday, October 3, 2021 at 10:27:36 PM UTC-7 Scot Hacker wrote:

> I asked this question on django-users and got no response. Thought I might 
> have better luck getting an "official" opinion on this here.
>
> You can call blocks in your templates anything you like, but if you intend 
> to share your software with the world, you'd better use `{% block content 
> %}` if you expect interoperability between your project and 3rd party apps.
>
> My question is along similar lines, but relates to using custom Groups. 
> There is no `settings.AUTH_GROUPS_MODEL` equivalent to `AUTH_USER_MODEL`. 
> If you make a custom Group model that subclasses Django Group, you can 
> still use `user.groups.all()`. But if a project uses a Group model that 
> that does not subclass `Group`, that doesn't work of course.
>
> I can't seem to find anywhere in the docs where Django recommends doing it 
> one way or another. I've always thought that a custom group should subclass 
> Group, and that is common, but some projects apparently don't do it that 
> way.
>
> I am asking because I am the maintainer of a reusable app that requires 
> groups compatibility, and have come across an app that that uses a 
> non-Django-derived groups system. We have come to impasse about the best 
> way to support this (or whether to support it all).
>
> Are there any best practices on this question in the Django docs or 
> elsewhere?
>
> Thanks,
> Scot
>

-- 
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/6d593b84-e0d9-4a08-8225-c49bbfa3bfacn%40googlegroups.com.

Re: Custom Groups model and interoperability

[Aymeric Augustin]

Hello,

The semi-official position is "create a separate model with a FK to the 
auth.Group". I know that's less than helpful. At least you know that there's 
nothing better built-in.

-- 
Aymeric.

PS: `{% block content %}` doesn't provide a meaningful level of 
interoperability. The semi-official position on this is "there is no reasonable 
way to do pluggable templates".

> On 5 Oct 2021, at 19:13, Scot Hacker  wrote:
> 
> 
> No official (or semi-official) position on this? Is "The right way to create 
> custom Groups" simply undefined in Django? 
> 
> Thanks.
> 
> 
> On Sunday, October 3, 2021 at 10:27:36 PM UTC-7 Scot Hacker wrote:
> I asked this question on django-users and got no response. Thought I might 
> have better luck getting an "official" opinion on this here.
> 
> You can call blocks in your templates anything you like, but if you intend to 
> share your software with the world, you'd better use `{% block content %}` if 
> you expect interoperability between your project and 3rd party apps.
> 
> My question is along similar lines, but relates to using custom Groups. There 
> is no `settings.AUTH_GROUPS_MODEL` equivalent to `AUTH_USER_MODEL`. If you 
> make a custom Group model that subclasses Django Group, you can still use 
> `user.groups.all()`. But if a project uses a Group model that that does not 
> subclass `Group`, that doesn't work of course.
> 
> I can't seem to find anywhere in the docs where Django recommends doing it 
> one way or another. I've always thought that a custom group should subclass 
> Group, and that is common, but some projects apparently don't do it that way.
> 
> I am asking because I am the maintainer of a reusable app that requires 
> groups compatibility, and have come across an app that that uses a 
> non-Django-derived groups system. We have come to impasse about the best way 
> to support this (or whether to support it all).
> 
> Are there any best practices on this question in the Django docs or elsewhere?
> 
> Thanks,
> Scot
> 
> -- 
> 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/6d593b84-e0d9-4a08-8225-c49bbfa3bfacn%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/6482479E-AADA-4851-B031-F6F5CD02E8E6%40polytechnique.org.

Re: DEFAULT_AUTO_FIELD

[Pavlos Georgiadis]

Hi,

As far as I know this is why BigAutoField is for. I guess the AutoField 
is there for backwards compatibility.



--
Pavlos Georgiadis


On 4/10/21 11:58, אורי wrote:

Hi,

Are there any intentions to make DEFAULT_AUTO_FIELD 
and django.db.models.AutoField a 64-bit integers in future versions of 
Django?


If not, why not?

Thanks,
אורי
u...@speedy.net 
--
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/CABD5YeGT-O0XMkZjC%3Dh%3DMWcJFEBo%3D%2BzXWpuBFfUsO5vJ3ZLH7g%40mail.gmail.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/57a8e950-45a0-4582-8a32-dee5dc57f08f%40georgiadis.eu.

Re: Custom Groups model and interoperability

[Scot Hacker]

Thanks very much for the response Aymeric. Seems like a bit of a gray area 
that could use some form of recommendation - like in a "Best Practices" 
section of the documentation? In any case, thanks again.

Scot


On Tuesday, October 5, 2021 at 1:13:47 PM UTC-7 Aymeric Augustin wrote:

> Hello,
>
> The semi-official position is "create a separate model with a FK to the 
> auth.Group". I know that's less than helpful. At least you know that 
> there's nothing better built-in.
>
> -- 
> Aymeric.
>
> PS: `{% block content %}` doesn't provide a meaningful level of 
> interoperability. The semi-official position on this is "there is no 
> reasonable way to do pluggable templates".
>
> On 5 Oct 2021, at 19:13, Scot Hacker  wrote:
>
>
> No official (or semi-official) position on this? Is "The right way to 
> create custom Groups" simply undefined in Django? 
>
> Thanks.
>
>
> On Sunday, October 3, 2021 at 10:27:36 PM UTC-7 Scot Hacker wrote:
>
>> I asked this question on django-users and got no response. Thought I 
>> might have better luck getting an "official" opinion on this here.
>>
>> You can call blocks in your templates anything you like, but if you 
>> intend to share your software with the world, you'd better use `{% block 
>> content %}` if you expect interoperability between your project and 3rd 
>> party apps.
>>
>> My question is along similar lines, but relates to using custom Groups. 
>> There is no `settings.AUTH_GROUPS_MODEL` equivalent to `AUTH_USER_MODEL`. 
>> If you make a custom Group model that subclasses Django Group, you can 
>> still use `user.groups.all()`. But if a project uses a Group model that 
>> that does not subclass `Group`, that doesn't work of course.
>>
>> I can't seem to find anywhere in the docs where Django recommends doing 
>> it one way or another. I've always thought that a custom group should 
>> subclass Group, and that is common, but some projects apparently don't do 
>> it that way.
>>
>> I am asking because I am the maintainer of a reusable app that requires 
>> groups compatibility, and have come across an app that that uses a 
>> non-Django-derived groups system. We have come to impasse about the best 
>> way to support this (or whether to support it all).
>>
>> Are there any best practices on this question in the Django docs or 
>> elsewhere?
>>
>> Thanks,
>> Scot
>>
>
> -- 
> 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/6d593b84-e0d9-4a08-8225-c49bbfa3bfacn%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/49ecfb95-ac40-4a3c-8f19-40b1f9586f39n%40googlegroups.com.