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
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
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
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
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 t
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?
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
> 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 repos
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) w
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
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
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 tha
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.
> O
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 fro
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
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.d
> 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
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
18 matches
Mail list logo
