Preparing Django code for the Black stable release

[Paolo Melchiorre]

Hi all,

More than two years ago the 'DEP 0008: Formatting using Black' was accepted 
with the constraint to wait until Black got to a stable release:
https://github.com/django/deps/blob/main/accepted/0008-black.rst

As you can see from this pull request in the Black code the first stable 
release is expected for January 2022:
https://github.com/psf/black/pull/2529

I think we can start prepare this great migrations of the Django code so we 
will be ready when Black 22.0 will be released and we can finally benefit 
from this change.

We have now more than 2 months to work on this.

Ciao,
Paolo

-- 
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/8bcec02b-6917-4d9a-9e65-eef375de73b9n%40googlegroups.com.

Re: Preparing Django code for the Black stable release

[Mariusz Felisiak]

> As you can see from this pull request in the Black code the first stable 
> release is expected for January 2022:
> https://github.com/psf/black/pull/2529
>
> I think we can start prepare this great migrations of the Django code so 
> we will be ready when Black 22.0 will be released and we can finally 
> benefit from this change.
>
> We have now more than 2 months to work on this.
>

Hi

Do you have any specific steps in mind? I'm not sure how we need to 
prepare. Implementation, as described in DEP 0008 
,
 
should be rather straightforward and I don't think anything needs to be 
done in advance. We (Fellows and OPS team) should be able to implement it 
within a few days.

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/81687d6f-2ea3-44b4-a9c8-fab71e4e0843n%40googlegroups.com.

Re: Fellow Reports - October 2021

[Mariusz Felisiak]

Week ending October 17, 2021 

*Triaged: *
   https://code.djangoproject.com/ticket/33183 - keepdb results in "Using 
existing database" log line, even when no database exists (duplicate) 
   https://code.djangoproject.com/ticket/33182 - Enable dark mode in a easy 
way (accepted) 
   https://code.djangoproject.com/ticket/33186 - Clarify get_FOO_display 
returns name, not label, from models.Choices (invalid) 
   https://code.djangoproject.com/ticket/33185 - sqlmigrate crashes given a 
RenameModel operation with a self-referencing foreign key on MySQL 
(accepted) 
   https://code.djangoproject.com/ticket/33178 - createsuperuser does not 
validate REQUIRED_FIELDS values in interactive mode when passed by 
command-line. (accepted) 
   https://code.djangoproject.com/ticket/33187 - Foreign key to a specific 
field is not handled in inspectdb (accepted) 
   https://code.djangoproject.com/ticket/33190 - If signals will be 
executed when running loaddata, then provide a warning (duplicate) 
   https://code.djangoproject.com/ticket/33189 - Obj does not exists 
message popup should start with a capital letter. (invalid) 
   https://code.djangoproject.com/ticket/33192 - It is not possible to use 
a custom lookup/transorm in a CheckConstraint (worksforme) 
   https://code.djangoproject.com/ticket/33193 - Clarify enumeration types 
are true Python Enums (invalid) 
   https://code.djangoproject.com/ticket/33194 - Remaking table with unique 
constraint crashes on SQLite. (accepted) 
   https://code.djangoproject.com/ticket/33196 - AppConfig.label identifier 
enforcement unnecessarily complicates upgrades for some apps (wontfix) 
   https://code.djangoproject.com/ticket/33198 - BinaryField documentation 
references length in characters, which is incorrect (accepted) 
   https://code.djangoproject.com/ticket/33195 - Class-based urlize() 
(accepted) 
   https://code.djangoproject.com/ticket/33199 - Make Signer parameters 
keyword-only. (accepted) 
   https://code.djangoproject.com/ticket/33200 - Consider "hiding" 
datetime/zoneinfo imports in django.utils.timezone (wontfix) 
   https://code.djangoproject.com/ticket/33201 - RenameModel with db_table 
should be a noop. (accepted) 
   https://code.djangoproject.com/ticket/33202 - Add a "grouper" template 
filter (wontfix) 
   https://code.djangoproject.com/ticket/33204 - Make MultiValueDict more 
consistent (wontfix) 

*Reviewed/committed: *
   https://github.com/django/django/pull/14963 - Refs #32900 -- Restored 
'[y/N]' in questioner prompt when merging migrations. 
   https://github.com/django/django/pull/14962 - Fixed #33149 -- Made test 
runner --pdb option work with subTest(). 
   https://github.com/django/django/pull/14976 - Refs #21755 -- Fixed 
createsuperuser crash for required foreign keys passed in options in 
interactive mode. 
   https://github.com/django/django/pull/14960 - Fixed #33178 -- Made 
createsuperuser validate required fields passed in options in interactive 
mode. 
   https://github.com/django/django/pull/14763 - Fixed #28401 -- Allowed 
hashlib.md5() calls to work with FIPS kernels. 
   https://github.com/django/django/pull/14805 - Fixed #29470 -- Logged 
makemigrations automatic decisions in non-interactive mode. 
   https://github.com/django/django/pull/14982 - Refs #25265 -- Allowed 
Query subclasses to build filters. 
   https://github.com/django/django/pull/14978 - Doc'd a precise exception 
type in Paginator.page() docs. 
   https://github.com/django/django/pull/14762 - Fixed #33008 -- Fixed 
prefetch_related() for deleted GenericForeignKeys. 
   https://github.com/django/django/pull/14983 - Fixed #23953 -- Made 
makemigrations continue number sequence for squashed migrations. 
   https://github.com/django/django/pull/14993 - Fixed #33195 -- Refactored 
urlize() based on a class. 

*Authored: *
   https://github.com/django/django/pull/14972 - Refs #29628, Refs #33178 
-- Made createsuperuser validate password against required fields passed in 
options. 
   https://github.com/django/django/pull/14979 - Bumped versions in 
pre-commit and npm configurations. 
   https://github.com/django/django/pull/14988 - Refs #27131 -- Removed 
SMTPBackendTests.test_server_login(). 
   https://github.com/django/django/pull/14989 - Refs #32074 -- Removed 
usage of deprecated asyncore and smtpd modules. 

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/0f79407a-066a-4394-82a0-7b5288017a71n%40googlegroups.com.

Re: Preparing Django code for the Black stable release

['Adam Johnson' via Django developers (Contributions to Django itself)]

The extension I added to the DEP may be a bit involved:

> All code Django generates will also be Black-formatted (startproject,
> migrations, inspectdb, etc.), at least if the user has Black installed.
>
But then again it may only need a few calls to black.format_str() in the
right places.

On Wed, 20 Oct 2021 at 10:37, Mariusz Felisiak 
wrote:

>
> As you can see from this pull request in the Black code the first stable
>> release is expected for January 2022:
>> https://github.com/psf/black/pull/2529
>>
>> I think we can start prepare this great migrations of the Django code so
>> we will be ready when Black 22.0 will be released and we can finally
>> benefit from this change.
>>
>> We have now more than 2 months to work on this.
>>
>
> Hi
>
> Do you have any specific steps in mind? I'm not sure how we need to
> prepare. Implementation, as described in DEP 0008
> ,
> should be rather straightforward and I don't think anything needs to be
> done in advance. We (Fellows and OPS team) should be able to implement it
> within a few days.
>
> 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/81687d6f-2ea3-44b4-a9c8-fab71e4e0843n%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/CAMyDDM0kbb2aF%2BMK0GObXFm6pVrt%3DWMLsX1TcK6QyEHpDVBjeg%40mail.gmail.com.

Re: Idea

['Adam Johnson' via Django developers (Contributions to Django itself)]

Check out htmx as a way to avoid needing JavaScript in your Django
applications: https://htmx.org/

Example app: https://github.com/adamchainz/django-htmx

On Sun, 19 Sept 2021 at 00:00, Jet Ezra  wrote:

> I know this may not be necessary at the moment because we are comfortable
> depending on front-end frameworks, but I have my two ideas here:
>
> 1. what if django alone without any framework can be used to design
> progressive web apps, with routers that do not reload the page, we
> currently have one of the best routing but what if they support SPAs this
> time?
>
> 2. what if we could instead of Javascript in the templates, we write
> python, case in example is forexample how we write C# in .NET withing our
> templates not writing JavaScript. Currently Django is requiring its
> developer to again go ahead and learn JS too, what if we remove that??
>
> --
> 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/bdefe58e-b26f-434e-a83f-36917b81f936n%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/CAMyDDM2N6zFK7p0VA8e-Y-DwpCSsePH3O5q3g1P7O8O8-Vi5kA%40mail.gmail.com.

Re: Proposed change in ORM model save logic

['Adam Johnson' via Django developers (Contributions to Django itself)]

I am also in favour. Thanks for explaining Barry.

On Mon, 18 Oct 2021 at 11:22, Carlton Gibson 
wrote:

> OK, thanks all, let's reopen. These kind of wontfix+MailingList issues is
> more about getting more eyes on it than anything else, and the explanation
> you've given is super Barry.
>
> C.
> On Sunday, 17 October 2021 at 09:59:18 UTC+2 Aymeric Augustin wrote:
>
>> Hello,
>>
>> On 15 Oct 2021, at 08:49, Barry Johnson  wrote:
>>
>> Instead of resolving this difference in keys by executing:
>> setattr(self, field.attname, obj.pk)
>> We believe it should instead:
>> setattr(self, field.name, obj)
>>
>>
>> For anyone reading this, this code is
>> https://github.com/django/django/pull/13589/files#diff-1c8b882c73bfda668d5451d4578c97191b0ebc0f088d0c0ba2296ab89b428c44R939
>>
>> I think the proposed change is correct. I reviewed this pull request and
>> related ticket, as well as prior art in the area, and I'm not seeing a
>> reason for assigning just the PK (= PK set, related cache not set) rather
>> than the entire object (= PK and related cache both set).
>>
>> Disclaimer — while I was involved in this area long ago, I didn't follow
>> what happened after commit 5980b05c, where the "prevent data loss with
>> unsaved related objects" checks were moved from the moment a related object
>> is assigned to the moment the object is saved.
>>
>> I reviewed Carlton's wontfix, which made sense to me, to understand why
>> we didn't reach the same conclusion. Carlton thinks the code has been here
>> for a very long time and would be tricky to touch; I believe that we're
>> only touching a line introduced in 519016e5, 2.5 years ago, which doesn't
>> feel _that_ old to me.
>>
>> 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/59a3158f-2552-4f33-9db3-8c5711dd6a91n%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/CAMyDDM2YViGGr86rzuPCuq%3D3_1o%3Do25S-SLDLM5nKkaUzp0yqg%40mail.gmail.com.

Re: Changelist links for proxy model admins

['Adam Johnson' via Django developers (Contributions to Django itself)]

Hi Niccolò

I suspect no one has replied to your thread because your use case is too
niche. Perhaps try showing the issue with more words and more visually with
a screenshot or two.

To me it sounds like "the admin links to the wrong place for proxy models"
which sounds like a plain bug, and if that is the case you could directly
open a ticket.

—Adam

On Sun, 17 Oct 2021 at 16:00, Niccolò Mineo  wrote:

> Hi.
>
> When one is displaying a proxy model admin I think It could be nice to
> automatically override the default behaviour for instances in the
> changelist and have them redirect to the proxy URL, instead of the default,
> non-proxy one.
>
> What do you think?
>
> I can prepare a PR.
>
> --
> 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/26c430ca-9896-4ab7-832b-369e515afcc8n%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/CAMyDDM0tUsuO1cBOX%3DkT%3Dg%2BmTwhp6RUp6Vrgw-uEUg_ZNk6BKA%40mail.gmail.com.

Re: Changelist links for proxy model admins

[Niccolò Mineo]

Hi Adam,

let me explain with one use case (I believe there's at least one more, but 
it doesn't matter for example's sake):

say you have a model Employee with two proxy models DeliveryPerson and 
CallCenterOperator, but only Employee has a ModelAdmin.

You get to the Employee admin changelist and each instance's link is in the 
form of */admin/employees/employee/{pk}/*.

What you would like to have sometimes is that links actually follow the 
structure of the proxy model they point to.

So, if one Employee instance is actually a DeliveryPerson, then I may want 
to have its own link on the changelist to be 
*/admin/employees/deliveryperson/{pk}/*, instead of the  
*/admin/employees/employee/{pk}/*.

Right now this is possible by overriding one of the response methods in the 
ModelAdmin, but I would find very useful a boolean attribute (
*"proxy_changelist_links" *maybe?) on the ModelAdmin for the same purpose.
Il giorno mercoledì 20 ottobre 2021 alle 18:20:22 UTC+2 Adam Johnson ha 
scritto:

> Hi Niccolò
>
> I suspect no one has replied to your thread because your use case is too 
> niche. Perhaps try showing the issue with more words and more visually with 
> a screenshot or two.
>
> To me it sounds like "the admin links to the wrong place for proxy models" 
> which sounds like a plain bug, and if that is the case you could directly 
> open a ticket.
>
> —Adam
>
> On Sun, 17 Oct 2021 at 16:00, Niccolò Mineo  wrote:
>
>> Hi.
>>
>> When one is displaying a proxy model admin I think It could be nice to 
>> automatically override the default behaviour for instances in the 
>> changelist and have them redirect to the proxy URL, instead of the default, 
>> non-proxy one.
>>
>> What do you think?
>>
>> I can prepare a PR.
>>
>> -- 
>> 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/26c430ca-9896-4ab7-832b-369e515afcc8n%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/dba63126-de41-462b-8258-efdcc4caf7a4n%40googlegroups.com.

Re: Preparing Django code for the Black stable release

[Paolo Melchiorre]

On Wed, Oct 20, 2021, 11:37 Mariusz Felisiak 
wrote:

>
> I think we can start prepare this great migrations of the Django code so
>> we will be ready when Black 22.0 will be released and we can finally
>> benefit from this change.
>>
>
> Do you have any specific steps in mind? I'm not sot sure how we need to
> prepare. Implementation, as described in
>
DEP 0008
> ,
> should be rather straightforward and I don't think anything needs to be
> done in advance. We (Fellows and OPS team) should be able to implement it
> within a few days.
>

Hi,

I was thinking we can start right now using black in a branch and see which
issue will show up and start fixing them.

Ciao,
Paolo

>

-- 
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/CAKFO%2Bx6hUfgmiZ%2BeL3EYDw6jHsZ0u0bqYNb4hQSPepgvEVewiQ%40mail.gmail.com.

Re: Preparing Django code for the Black stable release

[Markus Holtermann]

There is https://github.com/MarkusH/django-migrations-formatter which I think 
holds everything that's necessary to make the migration writer create 
black-formatted output.

Cheers, Markus

On Wed, Oct 20, 2021, at 11:11 AM, 'Adam Johnson' via Django developers  
(Contributions to Django itself) wrote:
> The extension I added to the DEP may be a bit involved:
>
>> All code Django generates will also be Black-formatted (startproject,
>> migrations, inspectdb, etc.), at least if the user has Black installed.
>>
> But then again it may only need a few calls to black.format_str() in the
> right places.
>
> On Wed, 20 Oct 2021 at 10:37, Mariusz Felisiak 
> wrote:
>
>>
>> As you can see from this pull request in the Black code the first stable
>>> release is expected for January 2022:
>>> https://github.com/psf/black/pull/2529
>>>
>>> I think we can start prepare this great migrations of the Django code so
>>> we will be ready when Black 22.0 will be released and we can finally
>>> benefit from this change.
>>>
>>> We have now more than 2 months to work on this.
>>>
>>
>> Hi
>>
>> Do you have any specific steps in mind? I'm not sure how we need to
>> prepare. Implementation, as described in DEP 0008
>> ,
>> should be rather straightforward and I don't think anything needs to be
>> done in advance. We (Fellows and OPS team) should be able to implement it
>> within a few days.
>>
>> 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/81687d6f-2ea3-44b4-a9c8-fab71e4e0843n%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/CAMyDDM0kbb2aF%2BMK0GObXFm6pVrt%3DWMLsX1TcK6QyEHpDVBjeg%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/07f0f742-c503-4f8b-81b4-33bda7f937bf%40beta.fastmail.com.

Re: Preparing Django code for the Black stable release

[Mariusz Felisiak]

> I was thinking we can start right now using black in a branch and see 
> which issue will show up and start fixing them.
>

We don't want to merge multiple commits related to black. According to the 
"Implementation" section in DEP 0008, we're going to run Black on the 
entire Django code repository and make a single commit. Running black 
should not encounter any issues, it's a code formatter, unless we find any 
bugs in Black such as 
https://github.com/psf/black/issues/1629#issuecomment-700621526. 

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/b703ebb2-77b9-4833-b379-f671de06ed26n%40googlegroups.com.

Re: Preparing Django code for the Black stable release

[Paolo Melchiorre]

On Wed, Oct 20, 2021, 21:51 Mariusz Felisiak 
wrote:

>
> I was thinking we can start right now using black in a branch and see
>> which issue will show up and start fixing them.
>>
>
> We don't want to merge multiple commits related to black. According to the
> "Implementation" section in DEP 0008, we're going to run Black on the
> entire Django code repository and make a single commit. Running black
> should not encounter any issues …
>

Okay, I also hope the migration to Black will be this smooth.

So now we just have to wait for 2022.

Ciao,
Paolo

-- 
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/CAKFO%2Bx53pmuLxc68_R7VtKgq_cVSmo1PGcUumG73pZ%3D3g7MAvg%40mail.gmail.com.

Re: Redirect type selection in django.contrib.redirects

[Niccolò Mineo]

Elaborating on the original proposal to make it backwards compatible, I was 
thinking along the lines of checking in the middleware whether the 
response_redirect_class attribute is set with the default class and, if it 
is not, making it use the Model's *redirect_type* field. 

What do you think?

Il giorno sabato 16 ottobre 2021 alle 23:50:26 UTC+2 Niccolò Mineo ha 
scritto:

> I just opened a ticket with the related PR: 
> https://code.djangoproject.com/ticket/33206
>
> Il giorno mercoledì 6 ottobre 2021 alle 23:55:51 UTC+2 Adam Johnson ha 
> scritto:
>
>> This seems like a reasonable addition to me.
>>
>> On Fri, 24 Sept 2021 at 08:08, Niccolò Mineo  wrote:
>>
>>> Hi. The marketing guys at my workplace asked for the ability to 
>>> customise the redirect type  (301, 302) when creating redirects in the 
>>> admin and I shipped this change a while ago. I believe this could be a nice 
>>> addition to Django itself, too. What do you think?
>>>
>>>
>>>
>>>
>>> -- 
>>> 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/0ccdfe91-c97a-4363-9226-518310ceca04n%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/9e0544a3-ae7d-46fe-afb6-d79437a6345cn%40googlegroups.com.

Re: Redirect type selection in django.contrib.redirects

[Niccolò Mineo]

Elaborating on the original proposal to make it backwards compatible, I was 
thinking along the lines of checking in the middleware whether 
the response_redirect_class attribute is set with the default class and, if 
it is, making it use the Model's *redirect_type* field. This could be 
extended to the 410, as well.

What do you think?

Il giorno sabato 16 ottobre 2021 alle 23:50:26 UTC+2 Niccolò Mineo ha 
scritto:

> I just opened a ticket with the related PR: 
> https://code.djangoproject.com/ticket/33206
>
> Il giorno mercoledì 6 ottobre 2021 alle 23:55:51 UTC+2 Adam Johnson ha 
> scritto:
>
>> This seems like a reasonable addition to me.
>>
>> On Fri, 24 Sept 2021 at 08:08, Niccolò Mineo  wrote:
>>
>>> Hi. The marketing guys at my workplace asked for the ability to 
>>> customise the redirect type  (301, 302) when creating redirects in the 
>>> admin and I shipped this change a while ago. I believe this could be a nice 
>>> addition to Django itself, too. What do you think?
>>>
>>>
>>>
>>>
>>> -- 
>>> 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/0ccdfe91-c97a-4363-9226-518310ceca04n%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/dd8cd2a3-99f5-4688-8393-d8845c22f9d0n%40googlegroups.com.

Re: Redirect type selection in django.contrib.redirects

[Niccolò Mineo]

For 410 status codes, the attribute to check would be the 
response_gone_class, of course.

Il giorno giovedì 21 ottobre 2021 alle 08:43:12 UTC+2 Niccolò Mineo ha 
scritto:

> Elaborating on the original proposal to make it backwards compatible, I 
> was thinking along the lines of checking in the middleware whether 
> the response_redirect_class attribute is set with the default class and, if 
> it is, making it use the Model's *redirect_type* field. This could be 
> extended to the 410, as well.
>
> What do you think?
>
> Il giorno sabato 16 ottobre 2021 alle 23:50:26 UTC+2 Niccolò Mineo ha 
> scritto:
>
>> I just opened a ticket with the related PR: 
>> https://code.djangoproject.com/ticket/33206
>>
>> Il giorno mercoledì 6 ottobre 2021 alle 23:55:51 UTC+2 Adam Johnson ha 
>> scritto:
>>
>>> This seems like a reasonable addition to me.
>>>
>>> On Fri, 24 Sept 2021 at 08:08, Niccolò Mineo  
>>> wrote:
>>>
 Hi. The marketing guys at my workplace asked for the ability to 
 customise the redirect type  (301, 302) when creating redirects in the 
 admin and I shipped this change a while ago. I believe this could be a 
 nice 
 addition to Django itself, too. What do you think?




 -- 
 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/0ccdfe91-c97a-4363-9226-518310ceca04n%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/ee059272-00f9-4842-9a08-956cd64dc7fen%40googlegroups.com.

Re: Redirect type selection in django.contrib.redirects

[Niccolò Mineo]

Elaborating on the original proposal to make it backwards compatible, I was 
thinking along the lines of checking in the middleware whether the 
response_redirect_class attribute is set with the default class and, if it 
is, making it use the Model's redirect_type field. For 410 status codes, 
the response_gone_class would be the attribute to check, of course.

What do you think?

Il giorno giovedì 21 ottobre 2021 alle 08:53:31 UTC+2 Niccolò Mineo ha 
scritto:

> For 410 status codes, the attribute to check would be the 
> response_gone_class, of course.
>
> Il giorno giovedì 21 ottobre 2021 alle 08:43:12 UTC+2 Niccolò Mineo ha 
> scritto:
>
>> Elaborating on the original proposal to make it backwards compatible, I 
>> was thinking along the lines of checking in the middleware whether 
>> the response_redirect_class attribute is set with the default class and, if 
>> it is, making it use the Model's *redirect_type* field. This could be 
>> extended to the 410, as well.
>>
>> What do you think?
>>
>> Il giorno sabato 16 ottobre 2021 alle 23:50:26 UTC+2 Niccolò Mineo ha 
>> scritto:
>>
>>> I just opened a ticket with the related PR: 
>>> https://code.djangoproject.com/ticket/33206
>>>
>>> Il giorno mercoledì 6 ottobre 2021 alle 23:55:51 UTC+2 Adam Johnson ha 
>>> scritto:
>>>
 This seems like a reasonable addition to me.

 On Fri, 24 Sept 2021 at 08:08, Niccolò Mineo  
 wrote:

> Hi. The marketing guys at my workplace asked for the ability to 
> customise the redirect type  (301, 302) when creating redirects in the 
> admin and I shipped this change a while ago. I believe this could be a 
> nice 
> addition to Django itself, too. What do you think?
>
>
>
>
> -- 
> 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/0ccdfe91-c97a-4363-9226-518310ceca04n%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/da935d61-f229-4319-9cee-ffe3fe8c31dfn%40googlegroups.com.

Re: Redirect type selection in django.contrib.redirects

[Niccolò Mineo]

Elaborating on the original proposal to make it backwards compatible, I was 
thinking along the lines of checking in the middleware whether the 
response_redirect_class attribute is set with the default class and, if it 
is, making it use the Model's redirect_type field. For 410 status codes, 
the response_gone_class would be the attribute to check, of course.

Il giorno sabato 16 ottobre 2021 alle 23:50:26 UTC+2 Niccolò Mineo ha 
scritto:

> I just opened a ticket with the related PR: 
> https://code.djangoproject.com/ticket/33206
>
> Il giorno mercoledì 6 ottobre 2021 alle 23:55:51 UTC+2 Adam Johnson ha 
> scritto:
>
>> This seems like a reasonable addition to me.
>>
>> On Fri, 24 Sept 2021 at 08:08, Niccolò Mineo  wrote:
>>
>>> Hi. The marketing guys at my workplace asked for the ability to 
>>> customise the redirect type  (301, 302) when creating redirects in the 
>>> admin and I shipped this change a while ago. I believe this could be a nice 
>>> addition to Django itself, too. What do you think?
>>>
>>>
>>>
>>>
>>> -- 
>>> 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/0ccdfe91-c97a-4363-9226-518310ceca04n%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/55ef8515-6ce5-4d37-b1a1-2306da3f4afan%40googlegroups.com.

Re: Redirect type selection in django.contrib.redirects

[Niccolò Mineo]

Ex.

if self.response_gone_class != HttpResponseGone and r.new_path == '':
return self.response_gone_class()
if self.response_redirect_class != HttpResponsePermanentRedirect:
return self.response_redirect_class(r.new_path)
return HttpResponse(status_code=r.redirect_type, new_path=r.new_path)

Il giorno giovedì 21 ottobre 2021 alle 08:56:44 UTC+2 Niccolò Mineo ha 
scritto:

> Elaborating on the original proposal to make it backwards compatible, I 
> was thinking along the lines of checking in the middleware whether the 
> response_redirect_class attribute is set with the default class and, if 
> it is, making it use the Model's redirect_type field. For 410 status 
> codes, the response_gone_class would be the attribute to check, of course.
>
> Il giorno sabato 16 ottobre 2021 alle 23:50:26 UTC+2 Niccolò Mineo ha 
> scritto:
>
>> I just opened a ticket with the related PR: 
>> https://code.djangoproject.com/ticket/33206
>>
>> Il giorno mercoledì 6 ottobre 2021 alle 23:55:51 UTC+2 Adam Johnson ha 
>> scritto:
>>
>>> This seems like a reasonable addition to me.
>>>
>>> On Fri, 24 Sept 2021 at 08:08, Niccolò Mineo  
>>> wrote:
>>>
 Hi. The marketing guys at my workplace asked for the ability to 
 customise the redirect type  (301, 302) when creating redirects in the 
 admin and I shipped this change a while ago. I believe this could be a 
 nice 
 addition to Django itself, too. What do you think?




 -- 
 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/0ccdfe91-c97a-4363-9226-518310ceca04n%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/072f27d3-9c38-4426-a9aa-b74c5abb7b73n%40googlegroups.com.