Re: HttpResponse headers interface

[Tom Carrick]

I think the PR has everything now and is ready for review:
https://github.com/django/django/pull/13186

On Wed, 15 Jul 2020 at 08:38, Carlton Gibson 
wrote:

> Just to be clear:
>
> > I think we should keep the old interface.
>
> I mean as well as adding the new .headers property. (So +1)
> (Sorry if that was already clear.)
>
> On Tuesday, 14 July 2020 16:41:43 UTC+2, Carlton Gibson wrote:
>>
>> I think we should keep the old interface.
>>
>> The BC concerns are one point: it's every bit of Django code ever
>> written. To keep __setitem__ &co is a small price to pay not to needlessly
>> break that code.
>>
>> Beyond that though, the proposed API is very nice, but the pendulum will
>> swing back: having response objects conform to the Python Data Model, by
>> looking like dicts, will again come to seem desirable. In
>> the meantime it'll be merely be handy that you can so use them> humour> — The number of times, "I can just..." will pay off here (IMO)
>> tells further against removing those special methods.
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Tuesday, 14 July 2020 16:07:15 UTC+2, Jon Dufresne wrote:
>>>
>>> > I don't see a reason to deprecate it at all just now (though perhaps
>>> in _my_ ideal world that would happen at some point), but I'm not sure if
>>> it's worth keeping the current interface in the documentation at all?
>>>
>>> IMHO, we should eventually take the advice from the zen of Python "There
>>> should be one-- and preferably only one --obvious way to do it.". While we
>>> should not take this as dogma, I do think it is generally wise.
>>>
>>> If there are increased concerns about existing projects, perhaps we
>>> could delay the initial deprecation or apply some kind of extended
>>> deprecation period that would allow projects more time to migrate. Removing
>>> the old interface from the docs is a great first step.
>>>
>>> But ultimately, I think having two interfaces to solve the same tasks
>>> confuses new library users and makes project coding styles more difficult
>>> than necessary.
>>>
>>> --
> 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/9a37d067-381f-46ab-bfc9-543d59a61c31o%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/CAHoz%3DMYLD6UAeu0CKkNMVwJpymvSKkMQUKzGpoKGAbcrNyZusw%40mail.gmail.com.

Re: HttpResponse headers interface

[Javier Buzzi]

@Tom looks great, should we add depreciation notices to the 
response.__gettitem__/del that way there are no 2 right ways to do things? 
I would probably keep it around until 3.2... I personally like the whole 
respose.headers it's much more readable.

-- 
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/86889efe-b876-46cc-8dc4-1559d6a6487do%40googlegroups.com.

Re: HttpResponse headers interface

[Tom Carrick]

I guess there is still some debate on how to handle the old interface. I'll
give my opinion, but I want to make it clear I don't mind that much what we
do with it.

When I've seen people learning Django, they come across these magical
strings you somehow add to the response, but aren't content, that does
magical things like make the content download rather than show in the
browser. To people who don't yet understand HTTP, this feels very... well,
magical.

This new interface has the advantage of being extremely clear what's
happening to people who are less familiar with HTTP than we are. It's
setting a header, it's right there in the name. I also feel it's much more
explicit.

I would prefer "one right way to do it", but I also don't see a compelling
reason to deprecate the old interface. It's been there forever, a huge
amount of code uses it, and I don't see a problem with leaving it there.
The way it's implemented is just interacting with the new headers anyway,
so it should be trivial to keep them in sync. Adam has suggested in the PR
to note that it "may" be deprecated in the future. Even if we don't
actually plan to do this, I like it. It's sneaky, we get people to
hopefully migrate to the newer interface but don't break people's code, at
least for a good long time.

To summarise, I'm:

+1 for the new interface.
+1 for keeping the old interface.
-0 for documenting the old interface as an alternative.

On Wed, 15 Jul 2020 at 11:43, Javier Buzzi  wrote:

> @Tom looks great, should we add depreciation notices to the
> response.__gettitem__/del that way there are no 2 right ways to do things?
> I would probably keep it around until 3.2... I personally like the whole
> respose.headers it's much more readable.
>
> --
> 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/86889efe-b876-46cc-8dc4-1559d6a6487do%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/CAHoz%3DMa7VDDSVj-5e1yF0RrCr0WKxujpN2-LwQc3NQNNT92V%3DQ%40mail.gmail.com.

Re: HttpResponse headers interface

[Adam Johnson]

I'm in favour of retaining and documenting the old interface, with some
kind of sentence pointing at the new one. Carlton posted on the PR that he
felt it was a bit paternalistic to recommend one over the other. I don't
agree, I think it's important to offer some guidance, especially for new or
returning developers. But I'd be happy with just a pointer from the
documentation of the old method that ".headers" is new, since that will at
least prompt users to consider.

Deprecating would be too much churn for little benefit to working code.


On Wed, 15 Jul 2020 at 11:02, Tom Carrick  wrote:

> I guess there is still some debate on how to handle the old interface.
> I'll give my opinion, but I want to make it clear I don't mind that much
> what we do with it.
>
> When I've seen people learning Django, they come across these magical
> strings you somehow add to the response, but aren't content, that does
> magical things like make the content download rather than show in the
> browser. To people who don't yet understand HTTP, this feels very... well,
> magical.
>
> This new interface has the advantage of being extremely clear what's
> happening to people who are less familiar with HTTP than we are. It's
> setting a header, it's right there in the name. I also feel it's much more
> explicit.
>
> I would prefer "one right way to do it", but I also don't see a compelling
> reason to deprecate the old interface. It's been there forever, a huge
> amount of code uses it, and I don't see a problem with leaving it there.
> The way it's implemented is just interacting with the new headers anyway,
> so it should be trivial to keep them in sync. Adam has suggested in the PR
> to note that it "may" be deprecated in the future. Even if we don't
> actually plan to do this, I like it. It's sneaky, we get people to
> hopefully migrate to the newer interface but don't break people's code, at
> least for a good long time.
>
> To summarise, I'm:
>
> +1 for the new interface.
> +1 for keeping the old interface.
> -0 for documenting the old interface as an alternative.
>
> On Wed, 15 Jul 2020 at 11:43, Javier Buzzi  wrote:
>
>> @Tom looks great, should we add depreciation notices to the
>> response.__gettitem__/del that way there are no 2 right ways to do things?
>> I would probably keep it around until 3.2... I personally like the whole
>> respose.headers it's much more readable.
>>
>> --
>> 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/86889efe-b876-46cc-8dc4-1559d6a6487do%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/CAHoz%3DMa7VDDSVj-5e1yF0RrCr0WKxujpN2-LwQc3NQNNT92V%3DQ%40mail.gmail.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM20AkYDa%2BWNZRJ48yE7kGhFrCX9CtitgciiZQVxho1Trw%40mail.gmail.com.

Re: HttpResponse headers interface

[Javier Buzzi]

All this makes a lot of sense.

-- 
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/e8e32943-841f-4cee-8654-a992f2c263f3o%40googlegroups.com.

Re: HttpResponse headers interface

[Jon Dufresne]

>
> I would prefer "one right way to do it", but I also don't see a compelling
> reason to deprecate the old interface.
>

For me, the reason to eventually deprecate the old interface is to help new
developers learning a new codebase. When these developers have been taught
to use response.headers but inevitably happen upon the old interface, there
will be a period of head scratching, diving into docs, code, whatever to
learn what this means only to come to the conclusion that it is an alias.
To me, that is an experience that could be improved.

The other benefit I see in deprecating the old interface is that new
developers don't need to learn or care how this fits in a particular
organization's coding style. Perhaps the organization requires using only
response.headers. Someone that uses the old interface out of habit will
need to unlearn this habit and perhaps deal with the frustration that comes
up during a review to fix it.

Consolidating to only a single interface would resolve both of these, IMO.
I'm quite happy to see the deprecation occur over a longer time than
normal, so I think the "may be deprecated in the future" is a good choice
to start and then we can act only after we feel enough time has passed.

-- 
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/CADhq2b6WwZpW_P9cNePMpxnrc1xVQwqWFhM4J0ROqUNiy%3Dh2AQ%40mail.gmail.com.

Good example of settings_changed signal usage

[Caio Ariede]

Hello folks,

I want to add a good example of usage for the settings_changed signal to the 
documentation:

https://docs.djangoproject.com/en/dev/ref/signals/#setting-changed

I was looking around the web and it seems there is some confusion around its 
proper use, so I’d like to add a good example that highlights a good and proper 
use case. I’m having a hard time trying to figure out a small and concise 
example.

Ideas? :)

— Caio

-- 
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/939ab426-67fd-495c-8a9a-92474189cc6b%40Spark.

Re: Good example of settings_changed signal usage

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

disconnect/reconnect signals maybe ?

-- 
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/E4oyeqLRkl9RBI9Zjw5dgoKjS0rpQfyFIMkmqk9z5vp9373hAaJfaq0PnM91qGNyFbi5W-kU5C00eknDq36VT-Vze532AqNTzqSrXj_dfjU%3D%40protonmail.com.

Fellow Reports -- July 2020

[Carlton Gibson]

Hi all. 


Calendar Week 27 -- ending 05 July.


Triaged:

https://code.djangoproject.com/ticket/20081 -- Minimize the risk of 
SECRET_KEY leaks (needsinfo)
https://code.djangoproject.com/ticket/31755 -- make temporal subtraction 
work without ExpressionWrapper (Accepted)
https://code.djangoproject.com/ticket/31754 -- preserve_filters 
doesn't work (needsinfo)
https://code.djangoproject.com/ticket/30415 -- Refactor runtests.py to 
allow using other test runners. (needsinfo
)
https://code.djangoproject.com/ticket/31752 -- Intermittent test failure on 
Windows with PostgreSQL (Accepted)
https://code.djangoproject.com/ticket/31750 -- Abstract model field should 
not be equal across models (Accepted)
https://code.djangoproject.com/ticket/31751 -- Add support for cx_Oracle 8 
(Accepted)
https://code.djangoproject.com/ticket/31747 -- Avoid potential admin model 
enumeration (Accepted)



Reviewed:

https://github.com/django/django/pull/13135 -- [2.2.x] Fixed 
ForeignKeyRawIdWidgetTest.test_render_unsafe_limit_choices_to on Python 3.5.
https://github.com/django/django/pull/13120 -- Improved performance of 
MEDIA_URL/STATIC_URL access and check SECRET_KEY on access.
https://github.com/django/django/pull/12752 -- Fixed #17664 -- Deprecated 
silencing exceptions in the {% if %} template tag.
https://github.com/django/django/pull/13101 -- Made JavaScript URL 
manipulation more robust with URL and URLSearchParams.
https://github.com/django/django/pull/13098 -- Simplified JavaScript with 
Array.prototype.includes().
https://github.com/django/django/pull/12646 -- Fixed #31169 -- Adapted the 
parallel test runner to use spawn. [GSoC]
https://github.com/django/django/pull/13123 -- [2.2.x] Refs #31751 -- 
Doc'd that cx_Oracle < 8 is required.
https://github.com/django/django/pull/13122 -- Fixed #31751 -- Fixed 
database introspection with cx_Oracle 8.



Authored:

https://github.com/django/django/pull/13137 -- Refs #6903 -- Adjusted 
ModelAdmin.preserve_filters docs.
https://github.com/django/django/pull/13126 -- Fixed #31752 -- Set explicit 
datetime for M2M ordering test.





Calendar Week 28 -- ending 12 July.


Triaged:

https://code.djangoproject.com/ticket/31774 -- validate_unique in Model 
class doesn't validate uniqueness for ImageField. (worksforme)
https://code.djangoproject.com/ticket/31775 -- An option to enforce 
raw_id_fields in Admin site for all relation fields by default (Duplicate 
of #17881)
https://code.djangoproject.com/ticket/31768 -- `django.http.request` 
`validate_domains` - should be optional "Invalid HTTP_HOST 
header" (Invalid)
https://code.djangoproject.com/ticket/31764 -- Add a way to allow subdomain 
wildcards in the set of allowed hosts for redirects after login/logout 
(needsinfo)
https://code.djangoproject.com/ticket/31759 -- Why do instance hints in 
ForwardManyToOneDescriptor use the related object? (Invalid)



Reviewed:

https://github.com/django/django/pull/13168 -- Used urllib.parse.urljoin() 
in auth_tests to join URLs.
https://code.djangoproject.com/ticket/31773 -- ExpressionWrapper loses 
output_field for combined expression without an output_field.
https://github.com/django/django/pull/12632 -- Fixed #31405 -- Added 
LoginRequiredAuthenticationMiddleware force all views to require 
authentication by default.
https://github.com/django/django/pull/13088 -- Fixed #31573 -- Made 
QuerySet.update() respect ordering on MariaDB/MySQL.
https://github.com/django/django/pull/13164 -- Fixed #31739 -- Documented 
dependency between HttpRequest stream IO methods and body.
https://github.com/django/django/pull/13158 -- Fixed #31767 -- Fixed 
QuerySet.none() on combined queryset.
https://github.com/django/django/pull/13153 -- Fixed #31765 -- Use feature 
detection to detect if SQlite supports atomically renaming references
https://github.com/django/django/pull/13157 -- Fixed #31502 -- Document 
Model._state.db and Model._state.adding.
https://github.com/django/django/pull/12310 -- Fixed #31180 -- Configured 
applications automatically.
https://code.djangoproject.com/ticket/31747 -- Avoid potential admin model 
enumeration



Authored:

https://github.com/django/django/pull/13072 -- Removed unsupported 
third-party backends from docs.




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/ab670625-766b-415c-9e1d-abbbe77180cao%40googlegroups.com.

Re: Good example of settings_changed signal usage

[Adam Johnson]

I'd suggest one of the examples from within Django itself - several of them
clear relevant @lru_caches.

On Wed, 15 Jul 2020 at 14:22, '1337 Shadow Hacker' via Django developers
(Contributions to Django itself)  wrote:

> disconnect/reconnect signals maybe ?
>
> --
> 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/E4oyeqLRkl9RBI9Zjw5dgoKjS0rpQfyFIMkmqk9z5vp9373hAaJfaq0PnM91qGNyFbi5W-kU5C00eknDq36VT-Vze532AqNTzqSrXj_dfjU%3D%40protonmail.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM2wUBfutYFnfkUkT%2Bsa1J7Jt8hxvgU0to_F4LkgcPbA%2Bw%40mail.gmail.com.

Re: HttpResponse headers interface

[David Smith]

The recent change to `url()` was a good example of this; even though it was in 
a DEP and the docs for a long time it still caused a lot of noise when the 
deprecation path was finally started.

The projects (ok, small sample) I've looked at are only now making this change. 
Folks will only change their code when they absolutely need to.

Could a warning in a of 'hey, did you know there is a new way to do this and 
btw the current way is going away' be more helpful. (I suspect not, but putting 
it out here).

-- 
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/a21bac06-1f87-42ea-bc90-f6829cb131c6o%40googlegroups.com.