Re: [Question] Why BaseManager._get_queryset_methods need use getattr(self.get_queryset(), name) in create_method

[Tim Graham]

Hi Ryoma, a good way to investigate this would be to make the change and 
see if anything breaks. 

If I understand correctly, your suggest is:

-return getattr(self.get_queryset(), name)(*args, **kwargs)
+return method(*args, **kwargs)

In that case, running the test suite gives this error:

  File "/home/tim/code/django/django/db/models/manager.py", line 89, in 
manager_method
return method(*args, **kwargs)
   ^^^
TypeError: QuerySet.using() missing 1 required positional argument: 'alias'

I leave further investigation to you. :-)
On Tuesday, February 27, 2024 at 7:28:05 PM UTC-5 Ryoma Han wrote:

> I've been reading through the Django source code the last few days. When I 
> was reading the BaseManager source code I saw a method like this:
>
> ```python
> @classmethod
> def _get_queryset_methods(cls, queryset_class):
> def create_method(name, method):
> @wraps(method)
> def manager_method(self, *args, **kwargs):
> return getattr(self.get_queryset(), name)(*args, **kwargs)
>
> return manager_method
>
> new_methods = {}
> for name, method in inspect.getmembers(
> queryset_class, predicate=inspect.isfunction
> ):
> if hasattr(cls, name):
> continue
> queryset_only = getattr(method, "queryset_only", None)
> if queryset_only or (queryset_only is None and 
> name.startswith("_")):
> continue
> new_methods[name] = create_method(name, method)
> return new_methods
> ```
>
> My question is why we use `getattr(self.get_queryset(), name)` insted of 
> just use `method`.
>

-- 
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/86389eb3-c16f-42d6-ae0d-983038734598n%40googlegroups.com.

Re: Transition Docs to Inline

[Tim Graham]

I don't think moving docs inline is a good idea. Quoting Aymeric from 2013 
regarding django.contrib.admindocs [1] summarizes my feelings: 
"""
1) It's called the "documentation generator", but it only operates on 
docstrings. This promotes the idea that docstrings are appropriate 
documentation, while the Python and Django communities now favor prose 
documentation. 

2) Even though it's possible to use docstrings to generate API 
documentation, for instance with Sphinx' autodoc, I find that heavily 
formatted, Javadoc-style docstrings (or late epydoc-style) tend to be hard 
to read for humans and I don't want Django to encourage them. 
"""
[1] 
https://groups.google.com/g/django-developers/c/0-qFyCPuSRs/m/kny7Oeu2RdoJ
On Monday, January 8, 2024 at 11:55:19 AM UTC-5 Jörg Breitbart wrote:

> Ah interesting that you mentioned django-stubs. I had good to mediocre 
> success applying it to my own django apps. It gets the job mostly done 
> for high level interfaces, but shows rough stub edges as soon as you 
> have to touch lower interfaces (can only speak for the ORM section in 
> this regard, which is highly mutating itself).
>
> Type annotations in Python are heavily inspired by Typescript, where 
> you'd strive for building up you interface types granularily and the 
> compiler does the rest pulling things together.
> I am not sure if Python's type annotations are yet or will ever be 
> capable to achieve that good enough for most common python paradigm, 
> seems Python is way too flexible for static type analysis. Typescript 
> partially solves this by banning/hiding some of JS' flexibility. (Ever 
> tried to fully type a mutating decorator in Python? Hours of fun ahead, 
> and you will still end up declaring many Anys effectively disabling 
> proper type pulling.)
>
> Now back to Django - it makes heavy usage of dynamic python features, 
> which is poison for any static type deduction. This is also the reason 
> why IDEs typically fail for more dynamic python code like django, unless 
> they do a partial runtime inspection (I think IntelliJ tries to do that 
> to some degree).
>
> So while better typing support is really nice where possible, I'd 
> suggest to not open this can of worms (yet), but mainly to stick to the 
> better inline docs idea.
>
>
> Cheers,
> Jörg
>

-- 
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/011ce3a2-3936-4e90-b205-5d12b229d536n%40googlegroups.com.

Re: Transition Docs to Inline

[Tim Graham]

Hi Moshe, 

Why is consulting the online documentation insufficient? I think most 
developers build Django projects while referencing the online documentation 
rather than while reading Django's source code.

What sort of documentation would be inlined? Would this require a large 
amount of duplication between docs and source code?

Why does adding docstrings require pyi files? My text editor doesn't have 
this "hover" feature. Please elaborate on your proposal for the 
uninitiated. Are there other projects that use the approach you suggest?
On Wednesday, January 3, 2024 at 2:38:02 PM UTC-5 Moshe Dicker wrote:

> Due to the dynamic nature of Python, features aren’t obvious.
> Developers don’t know what features a class has unless they dig through 
> the convoluted source code themselves or going online to check the 
> documentation.
>
> For example when implementing a `forms.ModelForm` hovering over it reveals 
> absolutely nothing useful.
>
> [image: image]
> image1000×157 11.5 KB
>
> 
>
> What do the “Django Lords” have to say about inlining the documentation in 
> the source code itself.
>
> I know the “Django Lords” have been weary of adding type stubs.
> However adding a docstring to this
> ```
> class Model(models.Model):
> ...
> class Meta: < THIS
> ...
> ```
>
> would require some stubs/.pyi files.
>
> I wouldn’t want to work on this just to find out that there are benefits 
> of the current setup that they aren’t willing to make a tradeoff.
>
> What would be the best way of asking the Django Governing Board about 
> their opinion on this?
>

-- 
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/d079d602-a11d-46ae-86c0-4bee9a8ff01bn%40googlegroups.com.

Re: Can we move the activity on this list to the Forum now?

[Tim Graham]

I agree with Carsten. I find the groups.google.com web interface much 
easier to follow and to quickly scan and see which threads I've read and 
which have new activity. I follow this mailing list more closely than the 
forum and prefer writing to it.

Incidentally, when I look at the "Django Internals" category of the forum, 
I see a lot of inappropriate usage questions that get answered there rather 
than pointed to the correct category. Is there a way to recategorize those 
posts?

On Thursday, May 4, 2023 at 2:09:35 AM UTC-4 Carsten Fuchs wrote:

> Hello,
>
> unfortunately, the subject lines of the emails sent by the forum have the 
> forum category prepended. These prefixes are long and make it difficult to 
> parse a large number of emails quickly, which significantly reduces one of 
> the main strengths of mail(ing-list)s.
>
> To be honest, I'm surprised that not more mailing list members argue in 
> favor of the mailing list. 
>
> The mailing list makes it easy to read or at least glance at every single 
> message, if desired, while enabling readers to skip uninteresting threads 
> quickly. This is a lot more difficult on the forum, especially with the 
> user interface as implemented by Discourse, which wastes a lot of white 
> space (lines with much vertical spacing, as with the topic lines on the 
> Latest page, are difficult to parse quickly) und whose „last visit“ line is 
> unreliable, especially if you read the forum on multiple devices (home, 
> office, mobile, …) with possibly several tabs open at the same time.
>
> I'm aware that I'm in a minority and that there is no way to convince the 
> relevant people to keep the mailing-lists, but in my opinion the switch the 
> forum is a step backwards in accessibility, usability and easy of use.
>
> Best regards,
> Carsten
>
> Am 04.05.23 um 07:49 schrieb Jure Erznožnik:
>
> This has been answered affirmatively in this very thread before. 
>
> The forum even has a "Mailing list mode" in addition to several other 
> mailing options (including a nifty "activity summary").
>
> LP,
> Jure
> On 4. 05. 23 07:28, Curtis Maloney wrote:
>
> Does the Forum allow me to get email notifications / summaries?
>
> If not, it will mean I disconnect with that part of the community.
>
> --
> Curtis
>
> On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:
>
> Yes please!
>
>
>
> On May 3, 2023 at 11:19:12 PM, jure.er...@gmail.com (jure.er...@gmail.com) 
> wrote:
>
>
> +1
>
>  
>
> *From:* django-d...@googlegroups.com  *On 
> Behalf Of *natali...@gmail.com
> *Sent:* sreda, 03. maj 2023 20:10
> *To:* Django developers (Contributions to Django itself) <
> django-d...@googlegroups.com>
> *Subject:* Re: Can we move the activity on this list to the Forum now?
>
>  
>
> Hello everyone!
>
>  
>
> I was wondering if we could make a decision about this topic. On the one 
> hand, and as far as I understand, the forum is the preferred channel of 
> communication. On the other hand, having multiple channels of communication 
> can spread important discussions too thin, making it difficult to have 
> productive conversations in one place.
>
>  
>
> As a newcomer to the contributing community, I can attest that the current 
> situation causes some confusion. IMHO, the same applies to the chat 
> options: there is IRC and the Discord server (though perhaps I should start 
> a new forum topic about that in order to keep decisions separated).
>
>  
>
> In summary, I'm +1 to "move on-mass (all few of us :) over there"!
>
>  
>
> Thank you!
>
> Natalia.
>
>
>

-- 
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/2c6cf8cc-91f5-48d9-a3a9-337fff1f3439n%40googlegroups.com.

Re: Doc make error: make: *** [Makefile:59: html] Error 127

[Tim Graham]

It looks like Sphinx isn't installed. Did you `pip install 
docs/requirements.txt`?
On Monday, April 10, 2023 at 9:12:48 AM UTC-4 Ezekiel Adetoro wrote:

> I want to generate the documentation for Django, I have the folloe error
>
> sphinx-build -b djangohtml -n -d _build/doctrees -D language=en   . 
> _build/html
> make: sphinx-build: No such file or directory
> make: *** [Makefile:59: html] Error 127
>
> I have install all requirement and no error.
> Any help on how to go about this?
>

-- 
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/34976b65-dbcc-49d8-820c-abee7de9ba28n%40googlegroups.com.

Re: Opensource Django Project

[Tim Graham]

Yes. See 
https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/

On Saturday, April 8, 2023 at 10:50:17 AM UTC-4 Naresh Pahariya wrote:

> Me too...
>
> I think there is a documentation for django contribution. 
>
> Thanks,
> Naresh
>
> On Sat, 8 Apr, 2023, 3:51 pm Dipankar,  wrote:
>
>> Hi All,
>>
>> I want to contribute  to the Open Source Django Project as a developer.
>> Can anybody help me please?
>>
>> -- 
>> Warm Regards,
>> Dipankar B.
>>
>> -- 
>> 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/CAFdBwp-m8nUVrP0Jd4o16XwBEOOOkE9ys42yYXRze58aUQZ4qQ%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/bb49f44b-056f-4e9d-95b2-c7f0462ddcd0n%40googlegroups.com.

Stalebot on djangoproject.com issues

[Tim Graham]

Hello,

In October 2022, a stalebot was activated for djangoproject.com issues:

https://github.com/django/djangoproject.com/issues/1219
https://github.com/django/djangoproject.com/pull/1220

It comments on an issue if there's no activity in the last six months: "This 
issue has been automatically marked as stale because it has not had recent 
activity. It will be closed if no further activity occurs. Thank you for 
your contributions."

The bot closes the issue if there's no activity in the next seven days.

I didn't see much discussion among the djangproject.com team outside of the 
issue and PR,  but the rationale from the issue is this: "Idea copied from 
DRF PR #8423  - Add 
a StaleBot, configured with the lowest possible run limit. The intent here 
is to help us sweep through the issue and pull request backlog, and review 
what does and does not need to remain open at this point in time."

Here is what I said at the time: "I think this is a lame way to handle old 
issues. The result seems to be Carlton triaging all issues that the bot 
comments on. You could have asked him to do that without a bot adding 
noise. Should a useless "issue still valid" comment be required every 180 
days? Why not have a human triage each issue now that more people are 
maintaining this site? Using a bot comes off to me as passive aggressive. 
Why try to automatically discard years of issues (even if minor)? It's not 
like the passage of time or lack of activity means the problem went away. A 
responsible reporter will look through existing issues so they don't report 
a duplicate and not necessarily leave a comment like "issue still valid." 
If we close the issue automatically, what did that accomplish? I would 
think triaging issues would be a good way for new team members to develop 
their understanding of the site. If you're feeling unknowledgable about an 
old issue, feel free to ping me for advice. I hope you might reconsider the 
usefulness of the bot."

It's six months later, and I'm now having to again comment on inactive 
issues "stalebot, please don't close." to keep valid issues open.

Paolo Melchiorre (author of this initiative) says, "activating the stalebot 
last year allowed us to close many old issues. I think an issue opened 7 
years ago should be closed if no one takes care of it despite two reminders 
in the last year. As the removal of the stalebot is not only up to me, I 
think it is worth discussing it in a separate issue or on the developer 
mailing list."

I remain of the opinion that continued attempts to automatically abandon 
valid issues are not helpful and do not reflect project maintenance best 
practices. I would like to hear your thoughts on the matter. Thanks!

-- 
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/84d1ee45-401b-4a52-8243-1a40fcf32955n%40googlegroups.com.

Re: Claiming Tickets

[Tim Graham]

Correct

On Saturday, January 28, 2023 at 11:32:21 AM UTC-5 jonathan...@gmail.com 
wrote:

> Hi all, 
>
> I was reading up on the documentation for new contributors and was reading 
> the "Claiming Tickets" section where it says "If a ticket for this issue 
> already exists, make sure nobody else has claimed it. To do this, look at 
> the “Owned by” section of the ticket. If it’s assigned to “nobody,” then 
> it’s available to be claimed. Otherwise, somebody else may be working on 
> this ticket." Is it also safe to claim a ticket that has a blank "Owned by" 
> field? If so I figured this could be a quick PR for me to get started with 
> updating the documentation.
>
> Thanks for the help!
>

-- 
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/b30e4d63-9e63-497b-b195-9767292a7151n%40googlegroups.com.

Re: Error

[Tim Graham]

Hi, You've found the wrong mailing list for this post. This mailing list is 
for discussing the development of Django itself, not for support using 
Django. This means the discussions of bugs and features in Django itself, 
rather than in your code using it.

For support, please follow the "Getting Help" page: 
https://docs.djangoproject.com/en/stable/faq/help/ . This will help you 
find people who are willing to support you, and to ask your question in a 
way that makes it easy for them to answer.

Did the place you found this mailing list make this unclear?
On Sunday, January 22, 2023 at 2:48:48 PM UTC-5 arshakar...@gmail.com wrote:

> When I want to auto generate models from already existing mongodb 
> collections by inspectdb it raises : # The error was: 'NoneType' object is 
> not subscriptable
> Please, any solutions
>

-- 
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/558ba312-efee-49d3-a8ad-3c6a8b2b64e6n%40googlegroups.com.

Re: Reverse for 'car_details' with arguments '('',)' not found. 1 pattern(s) tried:

[Tim Graham]

Hi, You've found the wrong mailing list for this post. This mailing list is 
for discussing the development of Django itself, not for support using 
Django. This means the discussions of bugs and features in Django itself, 
rather than in your code using it.

For support, please follow the "Getting Help" page: 
https://docs.djangoproject.com/en/stable/faq/help/ . This will help you 
find people who are willing to support you, and to ask your question in a 
way that makes it easy for them to answer.

Did the place you found this mailing list make this unclear?

On Saturday, January 21, 2023 at 5:01:55 PM UTC-5 bipuld...@gmail.com wrote:

>   In Views.py def car_details(request, id): redirect_to=1 
> single_car = get_object_or_404(Car, pk=id), 
>  data = { 'single_car': single_car, # 'url': url, }
>  # reverse('single_car', args=(id)) 
>  return render(request, 'cars/car_details.html', data)
>  In urls.py of my app 
> urlpatterns = [ path('', views.cars, name='cars'), 
>  path('\/car_details', views.car_details, name='car_details'),]
>  and In my templates cars.html
>  {% for car in cars %}  {{car.car_title}} 
> 
>   {{car.state}}, {{car.city}}  
> {% endfor %} 
> when i tried to call this car_details.html with urls function it show me 
> this error Reverse for 'car_details' with arguments '('',)' not found. 1 
> pattern(s) tried: I also tried with reverse function it doesnot work,How 
> can I solve this error  
>

-- 
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/bc79e6cc-70ef-4721-a5ef-0e11f058378fn%40googlegroups.com.

Re: Request for Guidance

[Tim Graham]

Hello, please take a look at 
https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/ 
to find advice for new contributors.

On Tuesday, January 17, 2023 at 2:07:02 PM UTC-5 gair...@somaiya.edu wrote:

>  
>
>  
>
> Hello sir, i am Gairick a second year MCA student and want to contribute 
> ,can you please point to me some resources by reading i can contribute to 
> codebase and learn new technologies and please share me the guide for 
> installation 
>
> Regards,
>
> Gairick
>
>  
>
>  
>
>
> 
>  
> Virus-free.www.avast.com 
> 
>  
> <#m_-5157259906153594593_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Disclaimer
> This email is governed by the Disclaimer Terms of  somaiya.edu which may 
> be viewed at https://www.somaiya.edu/en/email-disclaimer
>
> Finally, please do not print this email unless it is necessary. Every 
> unprinted email helps the environment.
>
>

-- 
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/7add6b7e-c4fc-44d1-8259-498be3f37b9fn%40googlegroups.com.

Re: Proposal for a "RegExpMatches" PostgreSQL ORM function

[Tim Graham]

Hi, please consolidate your proposal when your ideas are complete. There's 
no need to start a separate thread for every function. Also, please search 
this mailing list and ticket tracker for past discussions that might be 
relevant. A quick search turned up at least 
https://groups.google.com/g/django-developers/c/jHhzEmZk4xE/m/_EErl1GGDAAJ 
and https://code.djangoproject.com/ticket/28805 (Add database functions for 
regular expressions, e.g. RegexpReplace) which duplicates this proposal.

On Tuesday, January 17, 2023 at 11:41:26 AM UTC-5 niccol...@gmail.com wrote:

> How would you see adding the "REGEXP_MATCHES" function to the current set 
> of PostgreSQL ORM functions?
>

-- 
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/e4e678fe-3a89-4729-8e9b-008af20ddf5an%40googlegroups.com.

Re: GSOC 2023

[Tim Graham]

Hello all, please take a look at 
https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/ 
to find advice for new contributors.

On Tuesday, January 10, 2023 at 11:26:12 AM UTC-5 arpitasriv...@gmail.com 
wrote:

> Hello Everyone , myself Arpita Srivastava a pre final year computer 
> science student.
> I want to contribute in GSoC 2023 as my skill sets include python , 
> Django. So I have chosen Django as the organization to contribute in.  
> I was hoping If I could get some help from the Django & python community. 
> About how to start.
>

-- 
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/c8d64741-629a-4381-af9e-809c8a7c50bfn%40googlegroups.com.

Re: Backport for ticket 34063?

[Tim Graham]

Incidentally, I don't think it's important for the ultimate decision here, 
but I looked at the below analysis of ticket #32189. Carlton's analysis on 
the ticket that request.POST is empty when using 'content-type': 
'application/json' remains true. The results of the tests provided in the 
description of #32189 remain unchanged by the fix for #34063 
(test_request_factory_data_multipart passes and 
test_request_factory_data_json fails in the same way as in the ticket 
description). I would triage #32189 exactly as Carlton did. I don't see 
anything in that ticket that leads to the "AssertionError: Cannot read more 
than the available bytes from the HTTP incoming data." as in #34063. It's 
possible I made a mistake or that my knowledge is lacking, but I see 
nothing that would make me mark #32189 as a duplicate of #34063 (which I 
was planning to correct for posterity if it's indeed the case). It's 
possible that reporter did encounter the "Cannot read..." AssertionError at 
some point, but I see nothing concrete in the ticket that reproduces it. I 
hope that's clarifying!


> > James argues that this bug that went unreported for 2+ years is now very 
> important and is going to cause massive pain for many users. Only time will 
> answer this, but I'm skeptical. So far I believe we've seen two people 
> affected, James and the ticket reporter. 
>
> Well. 
>
> I had been trying to avoid bringing this up because I felt that the 
> backport policy and the severity of the bug were the things to focus 
> on, and because I was trying to avoid singling out individual mistakes 
> that contributed to the situation we have now. But there is at least 
> one other report of this bug in the Django Trac instance. It is the 
> first one I found when trying to diagnose the problem in my own code 
> (and the one I mentioned in my initial question on IRC, as anyone who 
> saw that can confirm), and it is one that was filed only a couple of 
> months after the release of Django 3.1, so well within the window of 
> time when the backport policy would have said to apply the fix to the 
> 3.1 branch as well as to main. It also correctly diagnosed the source 
> of the bug and provided an attempt at a patch. 
>
> That ticket was #32189: 
>
> https://code.djangoproject.com/ticket/32189 
>
> But it was closed invalid as a user error. We can debate whether the 
> user should have been trying to access request.POST for their 
> particular use case, but we cannot debate whether this is the 
> underlying bug that user was encountering. It also was clearly not the 
> normal behavior one ought to see from accessing request.POST, even in 
> a non-POST request or supposedly non-appropriate context, and likely 
> either should not have been closed, or should have produced a 
> follow-up ticket to investigate why that specific behavior was 
> occurring. 
>

-- 
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/05fef0dd-e608-46d2-a850-ddc5574183c2n%40googlegroups.com.

Re: Backport for ticket 34063?

[Tim Graham]

I guess it's nice to have a strict backport policy, partly to avoid hours 
of discussion like this, which ultimately boils down to a 
judgment/prediction about severity and whether or not the current backport 
policy should be amended. If I encountered a similar issue, I would have 
just worked around it and moved on. Surely there are other issues like this 
one that don't meet the current backport criteria but that could be 
similarly argued by someone persistent enough. It would be nice if the 
outcome here avoided that in the future.

I guess there's not much to add on either side of the argument at this 
point. Perhaps the best solution is what Shai outlined: to propose amending 
the backport criteria, either by expanding the LTS backport categories 
beyond security and data loss issues, or by allowing the steering council 
to vote on backport proposals on a case-by-case basis, at least if there's 
no consensus on the mailing list.
On Sunday, January 1, 2023 at 5:41:03 PM UTC-5 James Bennett wrote:

> On Sun, Jan 1, 2023 at 12:54 PM Tim Graham  wrote:
> > Older Django releases are currently maintained with minimal support that 
> allows existing projects to continue running securely. I don't think we 
> should invest resources in promoting them as a place to use experimental 
> features. A benefit of running an old LTS release like 3.2 is that any 
> release at this point is probably a very important upgrade (security or 
> data loss issue). If we start making new LTS bug fix releases to fix 
> experimental features, releases may be more frequent and less important. Of 
> course, with more changes, the risk of unrelated regressions increases, 
> including the possible bad situation in which users put off a bug fix 
> upgrade because it doesn't have any security fixes only to face issues 
> updating to a subsequent security release because of an issue in an interim 
> bug fix release. (Maybe mergers can estimate how many other async fixes 
> would be eligible for a backport based on the proposed criteria.)
>
> The backport policy already says that Django will backport certain
> things into older releases. I do not agree with your assessment of the
> risk of backporting, but even if we grant it for sake of argument, the
> Django project overall has already clearly endorsed -- through the
> current backport policy -- the idea that some fixes are important
> enough to override such concerns and to backport even into releases
> that are on "minimal" support.
>
> I happen to think that this is one such fix, for reasons that I have
> laid out at length. I also think the backport policy should be amended
> to prevent an issue like this from "slipping through the cracks" again
> in the future. I am still considering the wording Shai proposed,
> though on first read I thought it was getting at the right idea.
>
> > James argues that this bug that went unreported for 2+ years is now very 
> important and is going to cause massive pain for many users. Only time will 
> answer this, but I'm skeptical. So far I believe we've seen two people 
> affected, James and the ticket reporter.
>
> Well.
>
> I had been trying to avoid bringing this up because I felt that the
> backport policy and the severity of the bug were the things to focus
> on, and because I was trying to avoid singling out individual mistakes
> that contributed to the situation we have now. But there is at least
> one other report of this bug in the Django Trac instance. It is the
> first one I found when trying to diagnose the problem in my own code
> (and the one I mentioned in my initial question on IRC, as anyone who
> saw that can confirm), and it is one that was filed only a couple of
> months after the release of Django 3.1, so well within the window of
> time when the backport policy would have said to apply the fix to the
> 3.1 branch as well as to main. It also correctly diagnosed the source
> of the bug and provided an attempt at a patch.
>
> That ticket was #32189:
>
> https://code.djangoproject.com/ticket/32189
>
> But it was closed invalid as a user error. We can debate whether the
> user should have been trying to access request.POST for their
> particular use case, but we cannot debate whether this is the
> underlying bug that user was encountering. It also was clearly not the
> normal behavior one ought to see from accessing request.POST, even in
> a non-POST request or supposedly non-appropriate context, and likely
> either should not have been closed, or should have produced a
> follow-up ticket to investigate why that specific behavior was
> occurring.
>
> As for whether anyone else is affected: my searching turned up several
> references on other sites to the exact error message the bug produces,
> which all see

Re: Backport for ticket 34063?

[Tim Graham]

Older Django releases are currently maintained with minimal support that 
allows existing projects to continue running securely. I don't think we 
should invest resources in promoting them as a place to use experimental 
features. A benefit of running an old LTS release like 3.2 is that any 
release at this point is probably a very important upgrade (security or 
data loss issue). If we start making new LTS bug fix releases to fix 
experimental features, releases may be more frequent and less important. Of 
course, with more changes, the risk of unrelated regressions increases, 
including the possible bad situation in which users put off a bug fix 
upgrade because it doesn't have any security fixes only to face issues 
updating to a subsequent security release because of an issue in an interim 
bug fix release. (Maybe mergers can estimate how many other async fixes 
would be eligible for a backport based on the proposed criteria.)

James argues that this bug that went unreported for 2+ years is now very 
important and is going to cause massive pain for many users. Only time will 
answer this, but I'm skeptical. So far I believe we've seen two people 
affected, James and the ticket reporter.

This bug will be a non-issue for third-party apps with the release of 
Django 5.0 in December if they follow the suggested Django version support 
policy:

"Following the release of Django 5.0, we suggest that third-party app 
authors drop support for all versions of Django prior to 4.2. At that time, 
you should be able to run your package’s tests using python -Wd so that 
deprecation warnings appear. After making the deprecation warning fixes, 
your app should be compatible with Django 5.0."

Until then, apps could run the affected tests only on Django 4.2 (which 
will have an alpha release in about two weeks) if they don't want to work 
around the bug.
On Sunday, January 1, 2023 at 10:21:48 AM UTC-5 Shai Berger wrote:

> Hi,
>
> I think at this point it would help to move the discussion forward, if
> we tried to step beyond the specific issue and phrase the revision in
> the backporting policy. This will let us, I hope, have a more
> principle-based discussion.
>
> If I get it right -- please correct me, James -- it would be something
> like this addition:
>
> "In a new domain of functionality, which is considered major and
> central, bugs which would have been release blockers if found in time
> will be considered as candidates for backporting if found within the
> next two LTS versions" -- or even "... if found before use of the new
> domain of functionality becomes mainstream" -- or something similar.
>
> I think looking at it from that angle will be more fruitful. I will say
> that looking at this principle, thinking about the vicious cycle
> mentioned by James, I tend towards accepting his arguments.
>
> We may want to phrase it a different way: Think of such major domains
> as "experimental". We did that in the Python3 transition -- we had
> "experimental support" from 1.5, and IIRC that "experimental" label
> wasn't dropped until 1.8. I doubt we can retroactively declare async
> views as still experimental, but we can modify the backporting policy
> to say "release-blocker-level bugs in experimental features will be
> candidates for backporting as long as the feature is experimental";
> and we can set an exception that says "async is still experimental for
> backporting considerations", in view of the little use we've seen so
> far.
>
> (I can see the argument against the last proposition, that says
> "experimental means potentially broken, so it should be less worthy of
> backports rather than more"; I disagree, because (a) we do want to
> encourage such experimentation, and (b) no, it doesn't really mean
> potentially broken, it means the API is not yet covered by the
> stability guarantees; we're at more liberty to change things when we
> fix)
>
> HTH,
> Shai.
>

-- 
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/35bad7b0-1811-4a1e-a396-bd8e6591699fn%40googlegroups.com.

Re: Backport for ticket 34063?

[Tim Graham]

As perfectionists, it's always hard to say (and hear) "no" when this sort 
of request comes up. I'm unconvinced it's a serious issue that requires a 
break from normal policy. (Unreported for 2 years in 4 major releases; 
simple workaround present.)

Incidentally, escalating an issue to the steering council after less than 
24 hours (during a holiday week, no less) probably isn't something we want 
to model as a best practice in forming consensus.
On Friday, December 30, 2022 at 12:48:47 PM UTC-5 James Bennett wrote:

> I have put it to the Steering Council:
>
>
> https://forum.djangoproject.com/t/request-for-technical-board-steering-council-vote-requested-backport-ticket-34063/17920/1
>

-- 
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/7ef540fb-939f-4afa-9e05-33f988f6b0b0n%40googlegroups.com.

Re: `call_command` raises ValueError during testing

[Tim Graham]

Hi Ferran,

It looks like opt.option_strings is empty because "poll_ids" (in 
parser.add_argument()) isn't prefixed with a dash or double dash. 

You could instead use call_command() like this: call_command("closepoll", 1)

But I think your invocation could be fixed (or at least not fail so 
obscurely).
On Sunday, October 2, 2022 at 7:49:26 AM UTC-4 Ferran Jovell wrote:

> Hello everyone,
>
> I was working on a admin command today, and when setting up tests and 
> fixtures for running the command during testing I found this error:
>
> Traceback (most recent call last):
>   File "/home/fjm/code/django-stuff/tutorial/polls/tests.py", line 10, in 
> test_command_output
> call_command("closepoll", poll_ids=1, stdout=out)
>   File 
> "/home/fjm/.local/share/virtualenvs/tutorial/lib/python3.10/site-packages/django/core/management/__init__.py",
>  
> line 168, in call_command
> parse_args.append(min(opt.option_strings), default=0)
> ValueError: min() arg is an empty sequence
>
> However, what is weird is that when run from with the manage.py script, 
> everything seems to be working just fine.
>
> This is the command code
>
> from django.core.management.base import BaseCommand
>
>
> class Command(BaseCommand):
> def add_arguments(self, parser):
> parser.add_argument("poll_ids", nargs="+", type=int)
>
> def handle(self, *args, **options):
> pass
>
> And this is the test code:
> from io import StringIO
>
> from django.core.management import call_command
> from django.test import SimpleTestCase
>
>
> class ClosepollTest(SimpleTestCase):
> def test_command_output(self):
> out = StringIO()
> call_command("closepoll", poll_ids=1, stdout=out)
> self.assertIn("Expected output", out.getvalue())
>
> I set up a repo with the minimal code to reproduce this:
> https://github.com/mrswats/django-polls-test
> Is this a bug? Am I doing something wrong? Have I missed anything?
>
> I checked the bug tracker but could not find anything related to this and 
> before opening an issue I figured I'd ask. If it is indeed a bug I will 
> happily write a ticket in the tracker.
>
> Thanks in advance.
>
>

-- 
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/da3b35c5-eaed-49e8-9b61-eec4b3fc4736n%40googlegroups.com.

Re: Model-level validation

[Tim Graham]

> Among the dozen of Django applications I have worked on, at 3 companies, 
not a single one was actually running any kind of validation. It has always 
been a mistake, 100% of the time, *never* the desired behavior.

Besides not taking time to understand how Django works, it seems they 
weren't doing any manual testing or writing tests for invalid data either, 
so for me, this doesn't add much weight to the argument.

> I was able to find was that it was for "performance reasons", and I 
refuse to believe that a mature web framework like Django would prioritize 
performance (let's face it - even my millions-of-requests-per-day API 
service doesn't care about a few extra milliseconds here and there) over 
the most basic data safety concerns by default. 

I'm not sure it's correct to dismiss performance considerations, 
particularly when Model.full_clean() could add database queries for 
validating unique or other constraints. I believe doing validation 
redundantly (e.g. with form validation) or unnecessarily (e.g. bulk loading 
good data) would add undesired overhead. I think that forcing the entire 
Django ecosystem to opt out of automatic model validation as needed would 
be a heavy requirement to impose at this point. And apparently it was 
considered too heavy a requirement to impose when model validation was 
added in Django 1.2, released May 2010. 

I would try to keep an open mind to a concrete proposal, but I'm skeptical 
and it's surely non-trivial.
On Friday, September 30, 2022 at 7:53:24 PM UTC-4 aa...@aaronsmith.co wrote:

> If `ModelForm` were truly where validation logic lived, django would not 
> even use foreign keys. All constraints would be handled at the Form layer. 
> But we do use FKs, and also do other database-level consistency and 
> validity features, because data objects should understand and enforce their 
> own constraints. So what we have now is some types of validation happen 
> below Model, and some live above in the Form. This means that the data 
> store is not a single thing that's implemented with a simple interface, it 
> is a network of things which in inherently more difficult to work with, 
> understand, and maintain.
>
> If Forms were truly the validation layer, why am I able to specify things 
> like maximum length and allowed choices on the Model? Shouldn't those 
> things be specified at the Form layer?
> On Friday, September 30, 2022 at 4:27:13 PM UTC-7 Aaron Smith wrote:
>
>> Jorg,
>>
>> I do not believe it violates any separation of concerns. `full_clean()` 
>> is already a method on the Model class itself. The Model is already where 
>> all validation logic lives, except for the actual *triggering* of the 
>> validation.
>>
>> What I believe violates separation of concerns is that models do not run 
>> something which is already internal to itself, i.e. they are not actually 
>> fully functional as a data store layer, unless an external thing 
>> (ModelForm) is implemented. That feels wrong to me.
>> On Friday, September 30, 2022 at 2:19:35 PM UTC-7 
>> j.bre...@netzkolchose.de wrote:
>>
>>> @Aaron 
>>>
>>> Oh well, if anecdotal personal evidence counts for you - here is mine: 
>>>
>>> Working here since 2008 with Django in tons of projects in different 
>>> positions. The project sizes were from small websites to big API-driven 
>>> SPA cluster installations (with and w'o DRF). Ofc it is not all rainbows 
>>> and ponies with Django, but python-side data validation never crossed my 
>>> way as seriously flawed in Django. NOT EVEN ONCE. (Could list at least 
>>> 5-7 other topics that are somewhat tedious to get done with Django, but 
>>> thats offtopic here.) 
>>>
>>> Plz dont jump from personal frustration about poor development processes 
>>> you have observed to all-conclusions, that depict most Django users as 
>>> total noobs. (Still funny to read, as it reminded me on those flaming 
>>> wars between Perl and Python folks ~18ys ago, which abruptly ended when 
>>> Perl6 finally made its debut.) 
>>>
>>> > The question is not whether you /can/ compose validation into django 
>>> > models. The concern is that it should be done /by default/ to protect 
>>> > the average naive newbie developer from mistakes. 
>>>
>>> I'm sorry if I didn't answer that more directly for you - nope, imho it 
>>> should not be done by default on `Model.save`. It violates the path in 
>>> separation of concerns Django has chosen with form validation, thus the 
>>> -1 from my side. 
>>>
>>>
>>> Regards, 
>>> Jörg 
>>>
>>

-- 
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/2331d0d6-a890-42dc-8c6d-c627e540f0ean%40googlegroups.com.

Re: PASSWORD_HASHERS Check

[Tim Graham]

On Friday, June 24, 2022 at 10:14:48 PM UTC-4 Francisco wrote:

> Here is a real-world example I found on a quick search: 
> https://github.com/dimagi/commcare-hq/blob/6be7be39cb3f554670685e811a15720d46cc4a2d/settings.py#L192
>

In this case, it appears that making SHA1 the default hasher wasn't 
accidental: 
https://github.com/dimagi/commcare-hq/commit/afa8f603bf1d2f3c335aba6ed8a16d46a2740f8b.
 
It's unknown whether adding a system check would cause this project to make 
a change or if there's an ongoing reason that they're using that hasher (in 
which case a warning would only be an annoyance to suppress with 
SILENCED_SYSTEM_CHECKS).

All things considered, I agree with Mariusz that this is probably not a big 
problem in the Django ecosystem that justifies adding more code.

On Fri, Jun 24, 2022 at 11:00 PM Francisco Couzo  
> wrote:
>
>> If you happen to be using pytest and want to detect if you're testing, 
>> there's a really bad recommendation on this ticket: 
>> https://github.com/pytest-dev/pytest-django/issues/333, now that alone 
>> works, but if you were to import pytest, you would be running some test 
>> settings and be none the wiser.
>>
>> Also I think it's a good practice, you could have modified 
>> PASSWORD_HASHERS years ago, and the hasher that was once secure is not any 
>> more.
>>
>> On Tue, Jun 21, 2022 at 12:31 PM Tim Graham  wrote:
>>
>>> For context, Francisco proposed this at 
>>> https://code.djangoproject.com/ticket/33793 which was marked wontfix by 
>>> Mariusz 
>>> with the comment: 
>>>
>>> >  Django keeps "weak" password hashers for support with legacy systems 
>>> and ​speeding up the tests 
>>> <https://docs.djangoproject.com/en/stable/topics/testing/overview/#password-hashing>.
>>>  
>>> Moreover they are not enabled by ​default 
>>> <https://docs.djangoproject.com/en/stable/ref/settings/#password-hashers>, 
>>> so you must add them explicitly to the PASSWORD_HASHERS. Folks that do 
>>> this should be aware of their weakness. IMO there is not need for a new 
>>> system check.
>>>
>>> Francisco, have you seen this mistake made? It doesn't seem very likely 
>>> to me. Typically, the setting is customized in a test settings file; thus, 
>>> I don't see how this could propagate to a production environment.
>>>
>>> On Tuesday, June 21, 2022 at 11:18:04 AM UTC-4 Francisco wrote:
>>>
>>>> I think it would be a good idea to add a check for insecure hashers on 
>>>> PASSWORD_HASHERS[0], 
>>>> I know the insecure ones are not enabled by default, but I think it would 
>>>> be useful to warn users that have enabled them that it's a bad idea.
>>>>
>>>> They could have enabled them on production while thinking they only 
>>>> enabled them for testing for example.
>>>>
>>> -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/django-developers/CBdwSCiDKwY/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to 
>>> django-develop...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/4632834e-7864-48a9-947b-61aa0ccb11d6n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/4632834e-7864-48a9-947b-61aa0ccb11d6n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/44096686-0b13-4e5c-8152-3fc560a385c5n%40googlegroups.com.

Re: PASSWORD_HASHERS Check

[Tim Graham]

For context, Francisco proposed this at 
https://code.djangoproject.com/ticket/33793 which was marked wontfix by Mariusz 
with the comment: 

>  Django keeps "weak" password hashers for support with legacy systems and 
​speeding up the tests 
.
 
Moreover they are not enabled by ​default 
, 
so you must add them explicitly to the PASSWORD_HASHERS. Folks that do this 
should be aware of their weakness. IMO there is not need for a new system 
check.

Francisco, have you seen this mistake made? It doesn't seem very likely to 
me. Typically, the setting is customized in a test settings file; thus, I 
don't see how this could propagate to a production environment.

On Tuesday, June 21, 2022 at 11:18:04 AM UTC-4 Francisco wrote:

> I think it would be a good idea to add a check for insecure hashers on 
> PASSWORD_HASHERS[0], 
> I know the insecure ones are not enabled by default, but I think it would 
> be useful to warn users that have enabled them that it's a bad idea.
>
> They could have enabled them on production while thinking they only 
> enabled them for testing for example.
>

-- 
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/4632834e-7864-48a9-947b-61aa0ccb11d6n%40googlegroups.com.

Re: Proposals of GSOC.

[Tim Graham]

A proposal that was accepted last year is linked from 
https://code.djangoproject.com/wiki/SummerOfCode2022.

On Wednesday, March 9, 2022 at 10:34:59 PM UTC-5 sarthak...@gmail.com wrote:

> Can anyone share me old proposals of GSOC for django software application. 
>

-- 
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/d172c9ba-9097-4ec0-ac0a-9ef297b65231n%40googlegroups.com.

Re: Why I'm not able to see any organization?

[Tim Graham]

I see it now... 
https://summerofcode.withgoogle.com/programs/2022/organizations/django-software-foundation-8o

On Tuesday, March 8, 2022 at 8:23:22 AM UTC-5 sarthak...@gmail.com wrote:

> Trying this from last night , is this with me or everyone is facing this 
> problem ?

-- 
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/7562b4f9-8a82-493f-b9b4-5585817001dan%40googlegroups.com.

Re: Proposal on how add configuration options to Email Backends

[Tim Graham]

The idea was pursued in https://code.djangoproject.com/ticket/22734 but 
ultimately abandoned.
On Saturday, January 29, 2022 at 6:01:30 PM UTC-5 jacob...@gmail.com wrote:

> This proposal attempts to address the following issues:
> https://code.djangoproject.com/ticket/6989  (14 years old)
> https://github.com/django/django/pull/13728
> and
> https://code.djangoproject.com/ticket/31885
> https://github.com/django/django/pull/13305
>
> Currently all the parameters to configure the email backend are located
> in the global namespace, typically starting with EMAIL_...
> This in the past led to discussions whenever a new configuration parameter
> was required, because it added another entry to the yet too long list of 
> configuration
> settings.
>
> Since Django allows us to use more than one email backend concurrently,
> why don't we configure them in a similar way as we already do it with
> database, caching or template engine backends?
>
> Such a configuration setting then may look like:
>
> EMAIL = [
> {
> 'BACKEND': 'django.core.mail.backends.smtp.EmailBackend',
> 'HOST': 'smtp.example.org',
> 'HOST_USER': 'smtp_user',
> 'HOST_PASSWORD': 'smtp_secret',
> 'PORT': 25,
> 'FQDN': 'example.org',
> # all other related directives 
> }
> ]
>
> This would allow each email backend to "bring" its own configuration 
> settings
> contained in their own dictionary. Adding extra settings to this dict will 
> certainly
> lead to less discussions as we currently have.
>
> Personally, I would prefer SMTP = {...} as the main configuration 
> directive, but EMAIL seems to be more popular in Django.
>
> This would mean that the configuration directives starting from here 
>  will 
> have
> to be replaced, by their counterparts as explained before.
>
>

-- 
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/f124b879-4913-42ab-a635-ed3c570e7a83n%40googlegroups.com.

Re: Roadmap and communication of features planned for releases

[Tim Graham]

Hi Jason,

I'm not aware of any formally planned features. (If there were any, I'd 
expect they'd be discussed on this mailing list.)

The next release will include whatever features the community contributes 
by the feature freeze deadline. See 
https://code.djangoproject.com/wiki/Version4.1Roadmap for the timetable.
On Saturday, January 29, 2022 at 8:41:01 AM UTC-5 Jason Johns wrote:

> This came up via a query at Reddit 
> https://reddit.com/r/django/comments/setc9n/official_roadmap/ and I 
> wasn’t able to find anything other than what is already in the comments. 
> That also made me curious and feel that more communication about planned 
> features and changes could be useful.
>
> Thanks!
>
>
>

-- 
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/00b41a73-4480-4948-8815-f77502f58801n%40googlegroups.com.

Re: Snowflake db backend

[Tim Graham]

Cedar Cares, Inc. funded me to write a Snowflake backend. The first alpha 
for Django 3.2 was released this week. Testers and feedback are welcome!
https://github.com/cedar-team/django-snowflake
https://pypi.org/project/django-snowflake/
I didn't find the implementation particularly onerous, but perhaps there 
are things that the team at Disney implemented which I haven't addressed. I 
haven't triaged 100% of Django's tests, but I think I've covered the major 
stuff.

Regarding what Scott pointed out about Django's TestCase assuming support 
for nested atomic blocks when DatabaseFeatures.supports_transactions=True: 
I addressed this by running Django's test suite with a forked copy of 
Django that (among other things) modifies TestCase so that when running 
with Snowflake, it doesn't do any setup at the class level (which is 
usually does in its own Atomic [cls_atomics]) and instead does the 
following for each test (in TestCase._fixture_setup()):
- starts a transaction [self._enter_atomics()]
- populates class-level data [self.setUpTestData()]
- loads initial data from migrated apps; loads fixtures 
[super()._fixture_setup()]
- runs the test
- rolls back the transaction [self._rollback_atomics(self.atomics)]
This is on the order of 10x faster than not using transactions at all and 
truncating the tables after each test.

Later I thought that a faster approach could be to do the class-level 
setup, then run each test in its own transaction, then truncate the tables 
at the end of the test class. I'm guessing it might be faster for some test 
classes and not for others, depending on how much work setUpTestData() does.

I hope to incorporate this TestCase work into Django so that users of this 
backend can take advantage of it too (with a stock Django the backend can't 
transactions to speed up tests), but this won't happen sooner than Django 
4.1 since such a change doesn't qualify for a backport in Django.

I've added some other DatabaseFeatures in my Django fork that I also hope 
to contribute upstream (enforces_foreign_key_constraints, 
enforces_unique_constraints, supports_indexes, supports_tz_offsets... all 
False for Snowflake).
On Wednesday, April 21, 2021 at 1:36:02 AM UTC-4 Taylor wrote:

> Sorry, I meant to write Scott, not Tim. I shouldn't write emails late at 
> night.
>
> - Taylor
>
> On Tuesday, April 20, 2021 at 10:29:46 PM UTC-7 Taylor wrote:
>
>> Hey Everyone,
>>
>> Sorry to open up an old thread. 
>>
>> Tim - were you ever able to open source your Snowflake backend? We would 
>> love to use it and even devote resources (developers or funding for 
>> contractors) to improving it and getting the tests passing. At Cedar, we 
>> were planning on creating our own Snowflake backend, but it would be great 
>> to not duplicate work here. What are your thoughts?
>>
>> Best,
>> Taylor
>>
>> On Wednesday, January 27, 2021 at 1:08:13 AM UTC-8 f.apo...@gmail.com 
>> wrote:
>>
>>> Hi Scott,
>>>
>>> Thank you for your response, this is very helpful.
>>>
>>> On Tuesday, January 26, 2021 at 11:38:18 PM UTC+1 
>>> foug...@apps.disney.com wrote:
>>>
 Snowflake does not support lastrowid.  So, we grab the last ID inserted 
 with a 'SELECT MAX(pk_name) FROM table_name'.  This is obviously prone to 
 failure.  Assigning an ID during the INSERT would provide similar results 
 on all backends.

>>>
>>> U, the 'SELECT MAX()' is not going to fly well, you are right. 
>>> Assigning an ID during INSERT has it's own problems. In postgresql it would 
>>> be possible because you could just select the next value from the created 
>>> sequence (more or less), but with IDENTITY columns this might get harder. I 
>>> do not think there is a sensible way to do this in MySQL at all. While 
>>> lastrowid support is a nice to have, Django should work (mostly?) without 
>>> it: 
>>> https://github.com/django/django/blob/464a4c0c59277056b5d3c1132ac1b4c6085aee08/django/db/models/sql/compiler.py#L1372-L1387
>>>  
>>> -- the requirement here is that your database is at least able to return 
>>> values after insert. From the looks of it, it does not I think? Or 
>>> differently put: Which ways does snowflake offer to get an ID? Solely by 
>>> providing it directly into insert?
>>>
>>> The feature flag `supports_transactions` really means 
 `supports_nested_transactions`.  Snowflake supports a single level of 
 transaction, BEGIN + (ROLLBACK|COMMIT).  Multiple BEGINS contribute to the 
 current (only) transaction.  Since I have to set this flag to False, no 
 transactions are used, even ones that are supported and testing grinds to 
 a 
 crawl with all of the table truncations and repopulation.  Since Django 
 *normally* operates in auto-commit mode, this isn't a huge deal. 
  Snowflake also doesn't support save points, but the feature flag seems to 
 do what is expected when disabled.

>>>
>>> Hu, which database support nested BEGIN? As far as I am aware Django 
>>> does 

Re: Violating unique constraint in the admin

[Tim Graham]

Hi, there have been some past discussions, e.g. 
https://groups.google.com/g/django-developers/c/Dju2vvbzECI/m/vYDnYekgBQAJ

On Friday, October 8, 2021 at 6:34:02 AM UTC-4 Fab wrote:

> Hi,
>
> When I violate a unique constraint in the admin I get an error page.
>
> I know I can check this myself and show an error message when the form is 
> cleaned but I feel like this should be handled by default.
>
> Are there any reasons why it shouldn't show an error message on the admin 
> page?
>
> Cheers,
>
> Fabian
>

-- 
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/f9de59af-cf84-4218-a373-21fdcc0a3241n%40googlegroups.com.

Re: deconstruct returns 3-tuple?

[Tim Graham]

That documentation is for serializing classes. There's a note box that 
says, "This return value is different from the deconstruct() method for 
custom fields 

 
which returns a tuple of four items."

On Saturday, September 18, 2021 at 11:06:41 AM UTC-4 Christian González 
wrote:

> Hi,
>
> before I issue a bugreport, I'll ask here first.
>
> On 
> https://docs.djangoproject.com/en/3.2/topics/migrations/#adding-a-deconstruct-method
>  
> I can read that deconstruct() returns a 3-tuple.
>
> When I see the code in django.db.models.fields.__init__.py, 
> Field.deconstruct() does a
>
> return (self.name, path, [], keywords)
>
> 
>
> This is a 4-tuple, and even the clone() method written after it calls it 
> with
>
> name, path, args, kwargs = self.deconstruct()
>
> So, is 3.2 documentation here on a <1.9 status? Am I understanding 
> something not correctly?
>
> Thanks,
>
> Christian
>
> -- 
> Dr. Christian Gonzálezhttps://nerdocs.at
>
>

-- 
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/069eb2d7-e406-4fb5-a736-bd1b8507f937n%40googlegroups.com.

Re: Recognising Contributions

[Tim Graham]

I started including ticket numbers in patch releases because there aren't 
too many changes there and every change has a release note. I think the 
ticket numbers are useful to quickly identify the cause of some change or 
regression in a patch release where upgrades should generally be safer and 
therefore may have less testing than with a major release upgrade.

I think linking to tickets and/or mentioning authors in major releases 
notes would detract from readability (but maybe just beauty), and of 
course, not every commit (like bug fixes) in major releases requires a 
release note.

As an infrequent contributor these days, I'm not seeking any more 
recognition from my contributions, nor would more recognition encourage me 
to contribute more. I'd rather the Django team spend their efforts on 
building software than on publicity.
On Wednesday, August 18, 2021 at 2:20:25 PM UTC-4 chris.j...@gmail.com 
wrote:

> Related to this discussion, what's the current policy / practice around 
> linking to tickets from the release notes? It looks the release notes for 
> patch releases already link to tickets, e.g.
> https://docs.djangoproject.com/en/dev/releases/3.2.6/
>
> However, for feature release, it looks like the tickets aren't linked to, 
> e.g.
> https://docs.djangoproject.com/en/dev/releases/3.2/
> https://docs.djangoproject.com/en/dev/releases/4.0/
>
> Is the difference deliberate? Is it currently being done manually for 
> patch releases -- is that why it's being done / can only be done there?
>
> --Chris
>
>
> On Wednesday, August 18, 2021 at 3:37:21 AM UTC-4 carlton...@gmail.com 
> wrote:
>
>> Hey David. 
>>
>> Thanks for the follow-up here. 
>>
>> I think at least for 4.0 we should focus on adding callouts/recognition 
>> to the release blog post, rather than the release notes. 
>>
>> For one, release notes only contain new features, and we want to call out 
>> all the different contributions that don’t fall under that. The bug fixes, 
>> the docs changes, the translations teams, triage and review folks, and so 
>> on… — there’s much more than just new features. It would be nice to call 
>> out the new contributors (and the old too, but especially the new) — I 
>> think we can (and have time) to pull together something good in the more 
>> discursive format the release announcement allows. 
>>
>> For another, more narrowly practical point, I’d like a test-bed before we 
>> change the release note process, which is part of our daily workflow. Doing 
>> it in the release announcement is a one-shot opportunity to try ideas and 
>> see how it goes. If there are elements we then want to bring into the 
>> release notes going forward then that’s open. (But softly, softly… being 
>> the thought.) 
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On 18 Aug 2021, at 09:20, smi...@gmail.com  wrote:
>>
>> Hi All,
>>
>> Just coming back to this again (time flies), although we've got a while 
>> until 4.0 is released so no rush here.
>>
>> I've got a few different thoughts here:
>>
>> *Data*
>>
>> I had a look at the various tools discussed above to see if any give us 
>> what we need. While on that journey I came accross git's `shortlog`. 
>> Apparently git use this to create their release notes, there's a few 
>> options here but something like the following will give the list of 
>> contributors (and number of commits) since 3.2.
>>
>> What I like about this is it "coalesce together commits by the same 
>> person". The other tools above would have resulted in a number of different 
>> entries for many folk as they use different email addresses (or their 
>> GitHub "email" gets used). 
>>
>> $ git shortlog 3.2..main -n -s --group=author 
>> --group=trailer:co-authored-by
>>
>> I'm not quite sure how git then get to new and returning users, but 
>> presumably that could be a fairly short script to work out the new names 
>> since 3.2. 
>>
>> *Release Notes*
>>
>> Adding names and tickets seemed to receive a positive response earlier in 
>> the year. So the question here, is what format? 
>>
>> Python uses a couple of different formats
>> 1)  :  : Patch by 
>> 2)  (Contributed by  in )
>>
>> I think the main thing is to choose something, does anyone have a 
>> preference, either one of the above styles or something different? (My vote 
>> would be for the second option above)
>>
>> [1] https://docs.python.org/3/whatsnew/changelog.html
>> [2] https://docs.python.org/3/whatsnew/3.8.html
>>
>> *Events*
>>
>> Responding to Tom's point above, I think we'd want to reach out to one of 
>> the organisers of an event to see if folk would be interested in exploring 
>> this further. It's far more complex than "just" adding some text to a 
>> release note. However, given that it's a gathering of Django folk it seems 
>> like an opportunity to do _something_. 
>>
>> While I've seen what recognition can look like at corporate events those 
>> tend to rely on being Exclusive (think VIP areas et al), rather than 
>> Inclusive. I 

Re: datetime_safe deprecation

[Tim Graham]

Hi, did you consult the ticket? https://code.djangoproject.com/ticket/32738

On Sunday, August 1, 2021 at 1:09:04 PM UTC-4 mrhe...@gmail.com wrote:

> I note that datetime_safe is to be removed in Django 5.0 
> .
>   
> This module fixed the issue with the date padding for years < 1000, however 
> this issue still remains .
>
> Please can anyone advise what the guidance is to fix this date formatting 
> issue prior to the removal of the datetime_safe module?
>
> thank you
>

-- 
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/9cb806e7-614c-40fd-92f1-6eeef67afc32n%40googlegroups.com.

Re: Paid Contributions for specific feature in Django

[Tim Graham]

Hi Taylor,

As Adam said, it would be nice not to duplicate work that Disney's already 
done, but if I can help, I'm open to consulting and have written backends 
for CockroachDB (https://github.com/cockroachdb/django-cockroachdb) and 
Google Cloud Spanner 
(https://github.com/googleapis/python-spanner-django/). I still maintain 
the former and the latter has been turned over to Google.

(Incidentally, I'd rather reply privately but that option seems to be 
disabled for this group? "Reply to author" is greyed out and when I hover 
it says, "You do not have permissions to reply to author in this group." 
I'm not sure it was intentionally configured like that as I believe that 
option was available before Google Groups rolled out their latest 
interface.)
On Tuesday, April 20, 2021 at 5:39:34 PM UTC-4 Taylor wrote:

> Hi All,
> I am not sure if this is the place to ask this question, so sorry in 
> advance, but I am looking to pay for a feature request. I would like for 
> someone to build a Django DB adapter for Snowflake DB. 
> https://www.snowflake.com/
>
> It would be happy if it was a part of Django core or a separate package. 
> Either way, it would be 100% open source after completion. Is there any 
> process for this type of thing? If there isn't, is there anyone on here 
> interested in this type of work?
>
> Best,
> Taylor
>

-- 
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/23067fa0-3497-4e4e-a12d-4b8efd159ca9n%40googlegroups.com.

remove SECURE_BROWSER_XSS_FILTER setting?

[Tim Graham]

Hi, I think this setting and its functionality could be removed without a 
deprecation.

Django's docs says, "Modern browsers don’t honor X-XSS-Protection HTTP 
header anymore. Although the setting offers little practical benefit, you 
may still want to set the header if you support older browsers."
https://docs.djangoproject.com/en/3.2/ref/settings/#secure-browser-xss-filter

According to Mozilla's docs, the header is supported by IE8 and Safari.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

In Django 3.0, the system check that suggested using this setting was 
removed: https://code.djangoproject.com/ticket/30680.

-- 
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/bb6d7e16-7f8a-4c20-a3a6-4ebe3b2f05c2n%40googlegroups.com.

Re: Test fails silently when using --tag

[Tim Graham]

This was fixed a week ago (will be in Django 4.0). 
https://code.djangoproject.com/ticket/29127

On Monday, April 5, 2021 at 5:18:45 AM UTC-4 Adam Johnson wrote:

> Please don't report bugs here but to the ticket tracker. If you're not 
> sure there's a bug, django-users, the forum, or IRC are the recommended 
> venues.
>
> That said, I cannot reproduce your problem. Using django's main branch, I 
> started a new project with a tests.py file using your exact content and it 
> errors on import as expected:
>
> $ ./manage.py test --tag abc
> System check identified no issues (0 silenced).
> E
> ==
> ERROR: example.core.tests (unittest.loader._FailedTest)
> --
> ImportError: Failed to import test module: example.core.tests
> Traceback (most recent call last):
>   File "/.../python3.9/unittest/loader.py", line 436, in _find_test_path
> module = self._get_module_from_name(name)
>   File "/.../python3.9/unittest/loader.py", line 377, in 
> _get_module_from_name
> __import__(name)
>   File "/.../example/core/tests.py", line 4, in 
> assert 0
> AssertionError
>
>
> --
> Ran 1 test in 0.000s
>
> FAILED (errors=1)
>
> On Sun, 4 Apr 2021 at 14:26, Cammil Taank  wrote:
>
>> Hi All,
>>
>> When I run tests using the --tag option, and there is a module level 
>> exception, the tests seem to pass without any errors.
>>
>> Steps to reproduce:
>> 1. Add this to tests:
>> from django.test import TestCase
>> from django.test import tag
>>
>> assert 0 
>>
>> @tag('abc')
>> class TempTest(TestCase):
>>
>> def test_basic(self):
>> self.assertFalse(True)
>>
>> 2. Run python manage.py test
>> This should fail as expected
>>
>> 3. Run python manage.py test --tag=abc
>> This for me passes without any error
>>
>> Cammil
>>
>> 
>> ontono.com/cammil
>> taanktech.com
>> linkedin.com/cammiltaank 
>>
>> -- 
>> 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/CACc%3DA%3D1gOcps2ameDdo4qkDo64%3DcRB99SrbH%3DxrKx5XeSE%2Bk5Q%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/63cd73b5-1099-4bb0-876c-b75370b5bff8n%40googlegroups.com.

Re: Request for Comment: settings growth configuring Email Backend.

[Tim Graham]

I don't think there's a big cost to additional entries in 
docs/ref/setttings.txt. I think it's far more common to browse that 
document for needed functionality rather than to read the entire thing. 
There are 23 DATABASES 'TEST' settings that probably aren't used very 
frequently, yet I don't think it would be an improvement to remove all 
those and instead instruct users to subclass the database backend instead. 
In any case, the documentation has to be somewhere. If it's not a setting, 
then readers have to discover that functionality elsewhere. If we introduce 
some distinction between "commonly used options" and "less commonly used 
options", that creates extra work to figure out whether the option is 
considered "common" (setting) or "uncommon" (subclass). And further, some 
users may look no further than the settings page and never even discover 
the uncommon options.

If some functionality is so obscure that it doesn't merit a setting, 
perhaps it doesn't need to be in Django. If it's merely the number of 
settings that irk you, perhaps something like EMAIL_SSL_CONTEXT = 
{'cafile': ..., 'capath': ..., 'cadata': ...} would ameliorate your 
concerns in this case.
On Thursday, April 1, 2021 at 4:40:00 AM UTC-4 carlton...@gmail.com wrote:

> Hey Tim, 
>
> Thanks for following up here. 
>
> Thanks also for the link to the previous discussion, very interesting. 
>
> So, looking at that, this was first discussed 7 years ago, when there were 
> (just) 
> 6 email related settings. 
>
> I liked Jannis' initial reaction at the time: "Oh god, YES!!"
>
> It didn't get accepted in the end for arguments along the lines of 
> "Just for purity" and "No cost to adding an additional setting". 
>
> All this time later though, I would argue that those judgements, whilst 
> reasonable at the time, underplayed the costs. 
>
> We currently have 11 `EMAIL_` settings in `global_settings.py`[0]. 
>
> The suggested PR here[1] would add three more. And there's another PR[1] 
> open 
> suggesting adding yet another.  
>
> That would make 15 `EMAIL_` prefixed settings. 
>
> I would suggest that's too much. That it's time we changed tack. 
>
>
>
> The issue for me is that we're failing to insulate our users from a whole 
> swathe of unnecessary complexity that they shouldn't have to deal with. 
>
> As it is every reader of `settings.txt` has to go through each of these
> `EMAIL_` settings, parse them, and answer the questions _Does this apply 
> to me?
> And how?_. Instead of encapsulating the details of the SMTP, and now 
> SSLContext
> modules, we've added a set of pass-through parameters which force users to
> address them. 
>
> Particularly for the proposed SSLContext parameters, most user will never 
> need
> them — they'll just want the default `None` to use the default system CA 
> certs.
> So, we're adding to the cognitive load of all users, to address a use case
> affecting only a small subgroup. 
>
> I don't see/accept/agree with the "boilerplate" point. I need to create a 
> subclass yes: 
>
>
> ```
> from django.core.mail.backends.smtp import EmailBackend as SMTPBackend
>
>
> class EmailBackend(SMTPBackend):
> def __init__(self, *args, **kwargs):
> # Set Environment kwargs here.
> ```
>
> So it's an import and two lines for the class and init definitions. 
>
> The trade-off for that is insulating the plurality of users for whom these 
> advanced configuration options just simply aren't relevant. 
>
> The pay-off is that, by moving some of the more esoteric options out of 
> settings, we make Django's settings easier to navigate and comprehend for 
> every 
> body.
>
> It's like a form or the Sorites Paradox[3]: it turns out that in project 
> with the
> lifespan of Django, the seemingly harmless, "There's little cost to adding 
> one
> more setting" fails the induction rule. 
>
> FWIW: I think this same issue applies to the HTTP security headers thread,
> which we're still thinking about. We should encapsulate these with sane
> defaults, in a module that users can go and investigate, customise and 
> apply,
> with a single setting, rather than added an every longer list, which forces
> every user to face decisions that we should have made for them, for 
> ourselves.
>
> So that's my concern. 
>
> To address yours, I certainly don't think configuration details should be 
> "scattered". 
>
> I'd recommend a `project.conf.email` module (or package if needs be) 
> containing
> all the email related details. Keeping it all together makes it easier to
> maintain. (It's locality of behaviour: Where's email stuff? It's all in 
> there.)
>
> I'd then have a `EmailBackend` subclass per environment and set it with 
> the 
> `EMAIL_BACKEND` setting. (Folks can use environment variables and all the 
> rest 
> of it as they see fit here, much as they do now.)
>
> I think most users are using SMTP, and they **all** need to set
> host/username/password, so those settings should likely remain.
>
> The email section in 

Re: Request for Comment: settings growth configuring Email Backend.

[Tim Graham]

I don't think settings create any harm. They seem cleaner than suggesting 
subclassing the backend. If I'm understanding correctly, that would force 
everyone to write something like:

class MySMTPBackend(smtp.EmailBackend)
def __init__(self, *args, **kwargs):
super().__init__(*args, keyfile='', **kwargs)

That sort of code probably isn't suitable for `settings.py` itself which 
means configuration data like `''` is scattered elsewhere, or 
else developers are forced to write boilerplate and create their own 
settings to refer to `''`.

See also past discussion "Move SMTP / email settings to a dictionary" 
(wontfix)
https://code.djangoproject.com/ticket/22734
On Thursday, November 26, 2020 at 5:03:19 AM UTC-5 carlton...@gmail.com 
wrote:

> Hi Michiel.
>
>
> On 25 Nov 2020, at 17:53, Michiel Beijen  wrote:
>
> the old ones should be marked deprecated and
> probably should have been marked as such some Django releases ago.
>
>
> There you are, super. 
>
> Thank you for your input! 
>
> 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/5223f927-f30b-40f7-bba0-a7c2f30e6a28n%40googlegroups.com.

Re: Django 3.2rc1: models.W042 is raised on inherited manually specified primary key.

[Tim Graham]

Hi, It would be helpful to link to the ticket and/or explain the issue in 
more detail.

On Thursday, March 25, 2021 at 9:28:09 AM UTC-4 Caram wrote:

>
> This issue was raised in alpha1, but I still had the issue in beta1 and 
> now also in rc1.
>
> As a result, I have to manually edit the migrations files and remove lines 
> that alter fields to become BigField().
>
> Has this really been fixed? Am I missing something obvious?
>
> Caram
>

-- 
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/7d7a94c3-e9bf-46bd-bebc-4fb35b97150cn%40googlegroups.com.

Re: Help with ticket #28426

[Tim Graham]

I'd like to see what your code looks like so far. Personally, this is 
sounding a lot more complicated than I imagined when I accepted the ticket. 
I doubt this is a highly requested feature that couldn't be solved another 
way (e.g. downloading the template file without Django), and It's not clear 
to me that adding logic to Django is worth it.

On Thursday, March 4, 2021 at 11:01:41 AM UTC-5 benc...@gmail.com wrote:

> Thanks for the fast reply
>
> I found these test cases but I am not sure how to extend them with basic 
> auth, because I don't know if the *LiveServerTestCase *is capable of 
> doing basic auth. As I see currently there is no testcase checking basic 
> auth here and it has to be checked by hand.
>
> I am sorry but could you elaborate on this please because I couldn't find 
> these functions.
>
>
> *"first add view (in admin_scripts/urls.py is fine) to first check for 
> basic auth credentials and then pass off to `serve` (as the existing route 
> already does). That should give us the reproduce (or we can closed as 
> fixed)."*
>
> Best Regards,
>Bence
>
> Carlton Gibson  ezt írta (időpont: 2021. márc. 4., 
> Cs, 11:15):
>
>> Hi Bence, welcome! 
>>
>> There are already a couple of tests in place to check the remove 
>> fetching: 
>>
>>
>> https://github.com/django/django/blob/05bbff82638731a6abfed2fe0ae06a4d429cb32f/tests/admin_scripts/tests.py#L2047-L2072
>>
>> Without changing the command code I'd first add view (in 
>> admin_scripts/urls.py is fine) to first check for basic auth credentials 
>> and then pass off to `serve` (as the existing route already does). That 
>> should give us the reproduce (or we can closed as fixed). 
>>
>> Then I think it's easier if you open a PR with your suggested change 
>> after that (but more-or-less sounds plausible without looking in depth.) 
>>
>> Hopefully that gets you going? 
>>
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/66771c44-5b9f-4c29-b92a-91cd3092e016n%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/814187f8-dc2b-47e1-b91d-76d0ab78241an%40googlegroups.com.

Re: New to the Community

[Tim Graham]

It's expected. Some tests are only applicable to certain databases. Search 
for all mentions of "skip" at 
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/.
  
You can run the tests with "-v 2" to see the reason why a test was skipped.

On Thursday, February 25, 2021 at 10:34:27 AM UTC-5 muham...@gmail.com 
wrote:

> I just set up the project on my system and it's skipping a lot of tests, 
> is there anything I can do about it?
> I installed all  the dependencies in py3.txt 
> [image: Screenshot from 2021-02-25 14-53-27.png]
>
> On Wed, Feb 24, 2021 at 8:43 AM 'Adam Johnson' via Django developers 
> (Contributions to Django itself)  wrote:
>
>> Welcome!
>>
>> There are many different ways to contribute to Django - the forum, 
>> blogging, translating, documenting, writing code, and more. As Harouna 
>> pointsout, our Contributing Guide can help you get started with many of 
>> these: https://docs.djangoproject.com/en/stable/internals/contributing/
>>
>> If you’re looking to work with the code base (for documentation or code), 
>> check out the “Advice for New Contributors” section: 
>> https://docs.djangoproject.com/en/stable/internals/contributing/new-contributors/
>>  
>> . Then see if you can work through the “Writing Your First Patch” tutorial: 
>> https://docs.djangoproject.com/en/stable/intro/contributing/ .
>>
>> If you get stuck or have questions, post back here or in the “Mentorship” 
>> section on the forum: 
>> https://forum.djangoproject.com/c/internals/mentorship/10
>>
>> Hope that helps,
>>
>> Adam
>>
>> On Wed, 24 Feb 2021 at 00:04, Harouna Diallo  wrote:
>>
>>> Go to this link : 
>>> https://docs.djangoproject.com/en/3.1/intro/contributing/
>>>
>>> Le mar. 23 févr. 2021 à 23:58, Mhd Ali  a écrit :
>>>
 Hello everyone, my name is Muhammed Ali, I'm looking to contribute to 
 Django, please what are the prerequisites   

 -- 
 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/4ae7c78e-c547-4c7c-bd1e-effde973c6efn%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-develop...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/CAO73PDr_coaw%2B1qOWgGftWfz03E53kDeF9LZJ7F8hG_Akkesaw%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-develop...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAMyDDM0HLZusDnV7yksZ-2RosB%2BKxGbW5Upp_8Cdfmw5Rar6jw%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/5f125874-f7d7-4785-9e36-3d33990f8e07n%40googlegroups.com.

Re: Feature request: wigets attribute for ModelFormMixin class

[Tim Graham]

This has been proposed before (closed as wontfix):
https://code.djangoproject.com/ticket/24589
https://groups.google.com/g/django-developers/c/34HJqx48h6Y/m/Nm3UMTK4BgAJ

On Wednesday, February 17, 2021 at 9:53:07 AM UTC-5 jonask...@gmail.com 
wrote:

>
> # Feature request: wigets attribute for ModelFormMixin class
>
> ### Status quo
>
> The `ModelFormMixin` class currently implements the `fields` attribute by 
> it self and pass it to the `modelform_factory`:
>
> ```python
> class ModelFormMixin(FormMixin, SingleObjectMixin):
> """Provide a way to show and handle a ModelForm in a request."""
> fields = None
>
> def get_form_class(self):
> """Return the form class to use in this view."""
> if self.fields is not None and self.form_class:
> raise ImproperlyConfigured(
> "Specifying both 'fields' and 'form_class' is not 
> permitted."
> )
> if self.form_class:
> return self.form_class
> else:
> ...
> return model_forms.modelform_factory(model, fields=self.fields)
> ```
>
> On generic `CreateView` for example the field can be configured like:
>
> ```python
> class MonitoringRunNewView(CreateView):
> model = MonitoringRun
> fields = ('metadatas', )
> ...
>
> ```
>
> Same can be done in `UpdateView` and so on.
>
> ### Enhancement
>
> Provide the possibility to declare widgets for the configured fields also 
> like:
>
> ```python
> class ModelFormMixin(FormMixin, SingleObjectMixin):
> """Provide a way to show and handle a ModelForm in a request."""
> fields = None
> widgets = None
>
> def get_form_class(self):
> """Return the form class to use in this view."""
> if self.fields is not None and self.form_class:
> raise ImproperlyConfigured(
> "Specifying both 'fields' and 'form_class' is not 
> permitted."
> )
> if self.form_class:
> return self.form_class
> else:
> ...
> return model_forms.modelform_factory(model, 
> fields=self.fields, widgets=self.widgets)
> ```
>
> ```python
> class MonitoringRunNewView(CreateView):
> model = MonitoringRun
> fields = ('metadatas', )
> widgets = {'metadatas': forms.HiddenInput()}
> ...
>
> ```
>
> Configuring of `labels`, `help_texts` and `error_messages` could also be 
> helpfull. For that we also simply need to pass the attributes as in the 
> example above described.

-- 
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/be430d12-c5d8-46e9-8356-0548ae6cb39en%40googlegroups.com.

Re: Easy Pickings

[Tim Graham]

Hi David, I agree with your definition of easy as "ideal first issue" but I 
don't think aiming for a certain number of easy tickets makes sense. If 
those issues are quickly solved, then what happens... mark the next 20-30 
easiest tickets? I'd say feel free to mark any tickets as "easy pickings" 
that you feel are appropriate, especially if the issue isn't so 
straightforward but you are willing to mentor someone on it. To be honest, 
I've always kind of dreaded using the "easy pickings" flag because it would 
often take me a lot more time and effort to guide someone new than to do it 
myself. If you have the patience for that, I salute you.
On Wednesday, February 10, 2021 at 3:41:22 PM UTC-5 smi...@gmail.com wrote:

> Hi all,
>
> tl;dr - I'm proposing we make more use of the 'easy pickings' flag on trac 
> and should aim to have 20-30 tickets with this flag. More options here will 
> hopefully help new contributors. If there is support, I'm happy to help 
> review tickets to push the number up. 
>
>
> I've been thinking about the 'easy pickings' filter and it feels to me 
> like a bit of a missed opportunity. As a new contributor, I think filtering 
> Trac by this tag is one of the first things I'd do in the hope for an 
> 'easy' ticket that is available. Without this we expect folk to pick a 
> component and then judge which is 'easy'. I think having somewhat of a 
> curated list under this flag could help folk find "easier" tickers. Side 
> note: as discussed elsewhere "easy" isn't a great word here, "easier" or 
> maybe "ideal first issue" could be better, but is a slightly separate 
> topic. 
>
> Currently, we have only 8 out of c1,100 tickets marked in this category. I 
> think a reasonable target would be for say 20-30 tickets (c.2.0%-2.5%) to 
> be in this category. A slightly higher number than now means that there 
> would be more chance for folk to pick up an available ticket. 
>
> While "easy" is subjective, I think as well as the very rare but obviously 
> "easy" tickets (such as re-ordering a list of items in the docs) those 
> tickets which are "almost" there (had a prior patch and feedback, and 
> "just" need a few tweaks) could fall into this category, as could those 
> "just" needing docs. Tickets that have had some thought and work put into 
> them, are likely to be far easier than those without. 
>
> Appreciate thoughts. I'm more than happy to review some tickets to bump up 
> the number. 
>
> Thanks
>
> David
>
>

-- 
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/3edd4a95-4549-47b7-87ed-b944e3c3c7d7n%40googlegroups.com.

Re: Deprecating django.utils.functional.cached_property() ?

[Tim Graham]

There's a ticket about it: https://code.djangoproject.com/ticket/30949

On Thursday, February 4, 2021 at 5:57:15 AM UTC-5 carlton...@gmail.com 
wrote:

> functools.cached_property is available from Python 3.8. 
>
> https://docs.python.org/3.9/library/functools.html#functools.cached_property
>
> Is there any benefit to maintaining our own version, or should we 
> deprecate django.utils.functional.cached_property() with Django 4.0? 
>
> Thanks.
> 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/3f66bd3e-c4ad-4dcd-adeb-8999d6eadbb5n%40googlegroups.com.

Re: Docs improvement? - MEDIA_URL in templates

[Tim Graham]

I have no problem with your solution, or use MEDIA_URL as described at 
https://docs.djangoproject.com/en/dev/ref/settings/#media-url.

Generally for resized versions I'd use a third-party solution that offers 
some helpers like 
https://sorl-thumbnail.readthedocs.io/en/latest/examples.html#template-examples.
On Saturday, January 30, 2021 at 5:47:00 PM UTC-5 mjnich...@gmail.com wrote:

> Thanks for the suggestion for that specific case. I'll definitely use that!
>
> It doesn't, however, address the general case. I have images saved at 
> different URLs that aren't tied to a File field (eg. Resized versions). So 
> the question remains: are the docs clear enough to explain how to do this? 
>
> On Sat, 30 Jan 2021, 17:16 Tim Graham,  wrote:
>
>> Hi Mike,
>>
>> I think you want to use {{ user.avatar.url }}.
>>
>>
>> https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.fields.files.FieldFile.url
>>
>> For future reference, since this is more of a usage question, it would be 
>> better to post to django-users. If you want to suggest a documentation 
>> change after some discussion there, you can create a ticket at 
>> https://code.djangoproject.com/.
>>
>>
>> On Saturday, January 30, 2021 at 10:56:36 AM UTC-5 mjnich...@gmail.com 
>> wrote:
>>
>>> Not sure if this is something worth posting here or not, but I was 
>>> encouraged to put it up for discussion at least by somebody that knows more 
>>> than me :) 
>>>
>>> I was recently wanting to display user-uploaded media from a template 
>>> (an avatar pic in my navbar), and I couldn't really work out the "right" 
>>> way of doing this  from the docs. Docs for using static files in templates 
>>> are comprehensive - less so for media files from what I can tell. 
>>>
>>> A few SO questions, a bit of trial and error, and finding the 
>>> https://docs.djangoproject.com/en/3.1/ref/templates/builtins/#get-media-prefix
>>>  
>>> docs led me to the solution where I have
>>>
>>> 
>>>
>>> in my base template, then 
>>>
>>> >>
>>> in my navbar. 
>>>
>>> This works nicely, though I still don't really know if it would be 
>>> regarded as the "right" way to do it or if I now have a somewhat "hacky" 
>>> solution :)
>>>
>>> On the page 
>>>
>>> https://docs.djangoproject.com/en/3.1/howto/static-files/ 
>>>
>>> it talks about deploying static and media files in prod, and gives an 
>>> example of  how to use static files in a template, but no example for media 
>>> files. It strikes me that it would be handy if this page gave an example of 
>>> how to include a media file in a template. 
>>>
>>> Hope I'm not wasting people's time here!
>>>
>>> Cheers
>>>
>>> Mike
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/T1d3HBXrol4/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> django-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/d355974a-931f-425e-a0b7-5f08e7c808b6n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/d355974a-931f-425e-a0b7-5f08e7c808b6n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/02ab0e34-6a06-472c-abca-c375018c237an%40googlegroups.com.

Re: Docs improvement? - MEDIA_URL in templates

[Tim Graham]

Hi Mike,

I think you want to use {{ user.avatar.url }}.

https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.fields.files.FieldFile.url

For future reference, since this is more of a usage question, it would be 
better to post to django-users. If you want to suggest a documentation 
change after some discussion there, you can create a ticket at 
https://code.djangoproject.com/.


On Saturday, January 30, 2021 at 10:56:36 AM UTC-5 mjnich...@gmail.com 
wrote:

> Not sure if this is something worth posting here or not, but I was 
> encouraged to put it up for discussion at least by somebody that knows more 
> than me :) 
>
> I was recently wanting to display user-uploaded media from a template (an 
> avatar pic in my navbar), and I couldn't really work out the "right" way of 
> doing this  from the docs. Docs for using static files in templates are 
> comprehensive - less so for media files from what I can tell. 
>
> A few SO questions, a bit of trial and error, and finding the 
> https://docs.djangoproject.com/en/3.1/ref/templates/builtins/#get-media-prefix
>  
> docs led me to the solution where I have
>
> 
>
> in my base template, then 
>
> 
> in my navbar. 
>
> This works nicely, though I still don't really know if it would be 
> regarded as the "right" way to do it or if I now have a somewhat "hacky" 
> solution :)
>
> On the page 
>
> https://docs.djangoproject.com/en/3.1/howto/static-files/ 
>
> it talks about deploying static and media files in prod, and gives an 
> example of  how to use static files in a template, but no example for media 
> files. It strikes me that it would be handy if this page gave an example of 
> how to include a media file in a template. 
>
> Hope I'm not wasting people's time here!
>
> Cheers
>
> Mike
>

-- 
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/d355974a-931f-425e-a0b7-5f08e7c808b6n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Tim Graham]

Looking at this again, I'm not sure it would be six versions. Carlton's 
suggested policy has the effect of dropping a lot of Python versions right 
before the LTS since it's supported for 3 years. For example, in Django 5.2 
LTS, I think it's incorrect that Python 3.10 and 3.11 would be supported 
since their support expires in Oct 2026 & 7, before Django 3.2's expiration 
in April 2028)? The current policy means we have Django LTS's supporting 
some Python's well after they expire. I never liked that aspect of it. 
Anyway, the decision won't affect my life.
On Tuesday, January 26, 2021 at 5:32:50 AM UTC-5 Mariusz Felisiak wrote:

> Hi y'all,
>
> I think we should keep the current policy. There is never a good time 
> to drop support for anything and extending support especially for Python 
> 3.7 will end with more exceptions in the future. Current policy is really 
> patronizing and with the new Python release schedule we can reach 6 
> supported versions of Python for every LTS. I would make it even more 
> aggressive :) It's not only about the maintenance burden but also about new 
> features and syntax, we have tickets waiting 2-3 years until Python X 
> becomes the minimal Python supported by Django. My 2 cents 路
>
> 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/4dd42d46-ffe7-432f-8572-5a261c4fd0fcn%40googlegroups.com.

Re: PR review request

[Tim Graham]

Hi William, 3.2 alpha marked the feature freeze. Only non-release blocking 
bug fixes may be backported at this point (from 
https://code.djangoproject.com/wiki/Version3.2Roadmap#schedule). There are 
28 other patches in the review queue, many of which have been there longer 
than your tickets, so for future reference, I'd say no need to write to the 
mailing list at this point. If you have any colleagues, you could ask them 
to review your patches and mark the ticket as "ready for checkin" if 
appropriate.  Only the final review is limited to Django's team of mergers.

On Tuesday, January 26, 2021 at 3:01:23 PM UTC-5 wksch...@gmail.com wrote:

> Django committers,
>
> The docs recommend 
> 
>  
> posting here if a pull request hasn't seen any action in awhile—I'm sorry 
> if this nudge is premature! There are a couple of PRs I'd love to get 
> merged into 3.2 before the upcoming beta release. Both PRs' tickets were 
> approved as cleanups/optimizations before the 3.2 feature freeze.
>
>- More important: #32316 's 
>PR-13841 , which reduces 
>use of __file__ at the module level. The PR has already seen one round 
>of review and fixes, so hopefully it's (close to) done.
>- Less important: #32317 's 
>PR-13842 , which 
>refactors the loaddata command. The PR has not yet been reviewed.
>
> Thanks for working with me on these (and several other recent) PRs!
>
> Best,
> William
>

-- 
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/cf32f567-c886--83f4-54bec01a0f60n%40googlegroups.com.

Re: Rethink (?) how we handle security headers.

[Tim Graham]

If we go with something like:

SECURITY_HEADERS = {
"REFERRER_POLICY": "same-origin",
"HSTS": {
"PRELOAD": True,
"SECONDS": 1_000_000,
 },
}

should we have an empty dictionary as the default or a dictionary with 
defaults for all settings? 

A drawback of an empty dictionary is that any code that wants to retrieve a 
setting has to do something like 
settings.SECURITY_HEADERS.get('REFERRER_POLICY', '') which 
means the fallback value is duplicated every place the setting is 
consulted.  Maybe a way to mitigate that is to add a 
"get_security_header()" function that retrieves from django.conf.settings 
(user-defined settings) and falls back to some defaults.

A drawback of a fully-populated default is that overriding it either 
requires users to redefine the entire dictionary or writing code like:

from django.conf.global_settings import SECURITY_HEADERS
SECURITY_HEADERS['REFERRER_POLICY'] = '...'

If users redefine the entire dictionary, then adding new SECURITY_HEADERS 
options in future Django versions will require something like 
"get_security_header()" since we won't be able to assume the key is there 
in projects upgrading from older versions.

I'm not so sure the benefit of consolidating to a single setting is worth 
this additional complexity.
On Tuesday, January 19, 2021 at 8:27:58 AM UTC-5 Adam Johnson wrote:

> I don't see the need for adding a setting to add headers to outgoing 
> responses. A middleware to do so is a handful of lines:
>
> class SecurityHeadersMiddleware:
> def __init__(self, get_response):
> self.get_response = get_response
>
> def __call__(self, request):
> response = self.get_response(request)
> response["Cross-Origin-Embedder-Policy"] = "require-corp"
> return response
>
> Also there are many non-security related headers one might want to add, so 
> having the ability to add them in a setting called SECURITY_HEADERS could 
> be confusing for maintenance.
>
> On Tue, 19 Jan 2021 at 12:02, Tim Graham  wrote:
>
>> I guess there have been a few different proposals here, but I imagined 
>> SECURITY_HEADERS would allow setting any security-related header without 
>> making changes in Django. If the setting is more than header/value pairs, 
>> then it seems this won't be the case.
>>
>> On Tuesday, January 19, 2021 at 4:39:54 AM UTC-5 Adam Johnson wrote:
>>
>>> I'd imagined the setting would be more like a roll-up of the existing 
>>> settings, so no need for parsing:
>>>
>>> SECURITY_HEADERS = {
>>> "REFERRER_POLICY": "same-origin",
>>> "HSTS": {
>>> "PRELOAD": True,
>>> "SECONDS": 1_000_000,
>>>  },
>>> }
>>>
>>>
>>> On Tue, 19 Jan 2021 at 01:30, Tim Graham  wrote:
>>>
>>>> The proposal seems to be a setting of the form:
>>>>
>>>> SECURITY_HEADERS = {
>>>> 'Strict-Transport-Security': 
>>>> 'max-age=60; includeSubDomains; preload',
>>>> ...
>>>> }
>>>>
>>>> Currently we have system checks to suggest 
>>>> setting SECURE_HSTS_SECONDS, SECURE_HSTS_PRELOAD, etc. Do you envision 
>>>> trying to keep these checks? It seems it'll be more complicated to parse 
>>>> and validate arbitrary string values instead of individual settings.
>>>>
>>>> It seems some headers may still need special handling in 
>>>> SecurityMiddleware. For example, 'Strict-Transport-Security' is only set 
>>>> if 
>>>> request.is_secure().
>>>> On Friday, August 21, 2020 at 12:53:33 PM UTC-4 Adam Johnson wrote:
>>>>
>>>>> A single SECURITY_HEADERS (or perhaps SECURITY) setting sounds good. 
>>>>> Would love to get CORS into core too.
>>>>>
>>>>> The Opener-Policy ticket has been marked as someday/maybe because the 
>>>>> header is still not widely supported.
>>>>>
>>>>> On Thu, 20 Aug 2020 at 00:02, James Bennett  
>>>>> wrote:
>>>>>
>>>>>> While I think Adam's right that adding one or two new settings
>>>>>> wouldn't be a problem, I do worry about the ongoing proliferation, and
>>>>>> it's a thing that I keep wanting to try to find the time to work on
>>>>>> but never actually succeed at.
>>>>>>
>>>>>> Separate from the suggestion of a generic way to add headers on every
>>>

Re: Snowflake db backend

[Tim Graham]

Hi Scott,

Recently I've written backends for CockroachDB and Cloud Spanner. Perhaps 
those databases aren't as different as Snowflake, but I didn't have any 
major obstacles. I've had good success at contributing database backend API 
changes to Django to make future maintenance of those backends easier. It 
sounds like you might like to do the same.

Based on past discussions, I don't expect any more backends will be 
included in Django soon, nor did I expect any of the backends in core will 
be removed. That would only increase the maintenance burden since it would 
require coordinating changes across several repositories. Third party 
backends have to "catch up" to database API changes and new features at 
their convenience, but Django's development would be slowed if contributors 
had to be proficient in every database under the sun that has a backend for 
Django.

You can read past threads in the mailing list for more discussions:
Removing Oracle from Django core in 3.0
https://groups.google.com/g/django-developers/c/dg8BUVHKOo4
Moving database backends out of the core 
https://groups.google.com/g/django-developers/c/O-g06EM6XMM

On Friday, January 22, 2021 at 5:34:14 PM UTC-5 foug...@apps.disney.com 
wrote:

> Snowflake (at this point) isn't as fast as PostgreSQL for smaller 
> transactions.  PostgreSQL couldn't handle the performance we needed to 
> drive our apps and we really didn't want to support a hybrid db app.  We 
> give up a little speed for the convenience of having everything in one 
> system.  At a recent Snowflake event, they stated that 30% of their users 
> were using Snowflake for application backends.  They are also working to 
> improve their execution time on smaller transactions.
>
> Honestly, I don't think we'd release this as a third party package.  We 
> have had to code around a lot of core db specific code to get Snow SQL to 
> work.  If there was a hard API for DB backends my response would be 
> different.  It would only make sense for us if this backend were part of 
> standard Django testing and support consideration.
>
> "Merging the backend straight to core would impose the requirement that 
> all changes to Django core consider Snowflake"
> That's what has made the process harder than it should be to support a 
> non-core db.  It creates second class system support in favor of the core 
> dbs that are code and tested against.  Remove all of the db backends and 
> make them all third party and you'd see a lot more db support.
>
> Scott
>
> On Friday, January 22, 2021 at 5:22:24 PM UTC-5 Adam Johnson wrote:
>
>> Yes we would favour a third party backend. Merging the backend straight 
>> to core would impose the requirement that all changes to Django core 
>> consider Snowflake, which is a fairly steep cost when there's only one 
>> organization using it (at current). If you release as a third party package 
>> and show some adoption, it could then be argued that it's worth merging.
>>
>> Additionally Scott - would love to see Disney appear on this page, 
>> perhaps the "Platinum" section would feel comfortable: 
>> https://www.djangoproject.com/fundraising/ ;)
>>
>> On Fri, 22 Jan 2021 at 21:57, Tom Forbes  wrote:
>>
>>> I think this should definitely be released as a third party package, and 
>>> if there is enough community interest it might be considered for inclusion. 
>>> We could definitely update the docs to link to the package though.
>>>
>>> On a side note, is Snowflake fast enough for general purpose web apps? 
>>> When we evaluated it the performance characteristics where similar to 
>>> Redshift, optimised for large analytical aggregation rather than fast, 
>>> smaller result sets typically seen with Django apps.
>>>
>>> Tom
>>>
>>> On 22 Jan 2021, at 21:49, Scott Fought  wrote:
>>>
>>> 
>>>
>>> We have written a Snowflake DB backend that we use internally in several 
>>> projects and are considering releasing it for public use.  My preference 
>>> would be to incorporate it as a core backend so the nuances of Snowflake 
>>> SQL are considered when changes are made to the core system.  Is this 
>>> something we should pursue?
>>>
>>>
>>> Thanks,
>>>
>>>
>>> Scott
>>>
>>> -- 
>>> 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/3e5034a8-6c75-4f28-9830-2c87b671ae86n%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 

Re: Polymorphics relationship

[Tim Graham]

Search the archives of this mailing list for "polymorphic" to see past 
discussions. There hasn't been consensus that it needs to be in Django 
itself. There's already 
https://django-polymorphic.readthedocs.io/en/stable/.
On Thursday, January 21, 2021 at 3:41:13 PM UTC-5 jonnath...@gmail.com 
wrote:

> I have inspect the code base of django core and database, and we need to 
> add this feature to framework (if doest not exists) for more efficiency 
> database queries and workflow. I have been programming with django 3 month 
> ago, and I'd like to contrib for this feature. So what do you think about 
> it?

-- 
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/eb48205b-0a1a-4511-9568-a6a6ec6fe783n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Tim Graham]

Hi Carlton, This chart doesn't look quite right for the policy you wrote. 
For example, I wouldn't expect Django 4.2 LTS (supported until April 2026) 
to support Python 3.8 (only supported until October 2024). It seems like 
this policy makes it more likely that the last Django version to support a 
Python would be a non-LTS rather than an LTS. Maybe that's fine.

It might also be helpful to clarify the backport policy for Python version 
support. Something like, "the latest stable version of Python will be 
supported in the latest stable version of Django (and the latest Django 
LTS)". For example, unlike your chart, I had Python 3.13 backported to 4.2 
and 5.0.
On Wednesday, January 20, 2021 at 3:21:44 AM UTC-5 carlton...@gmail.com 
wrote:

> OK, so... 
>
> Updating Tim's table to have "A version of Django will support current 
> Python versions who's EOL date is not before it's own EOL date" would give 
> us: 
>
> Django  Released  End of life  Support Python 
> Versions
> 4.0 December 2021  April 2023   3.7, 3.8, 3.9, 3.10
> 4.1 August 2022December 20233.8, 3.9, 3.10, 3.11 
> (Oct 2022)
> 4.2 LTS April 2023 April 2026  3.8, 3.9, 3.10, 
> 3.11, 3.12 (Oct 2023)
> 5.0December 2023   April 2025  3.9, 3.10, 3.11, 
> 3.12
> 5.1August 2024 December 2025   3.10, 3.11, 3.12, 3.13 
> (Oct 2024)
> 5.2 LTS April 2025 April 2028 3.10, 3.11, 
> 3.12, 3.13, 3.14 (Oct 2025)
>
> Python  Released   End of life
> 3.7 June 2018June 2023
> 3.8 October 2019   October 2024
> 3.9 October 2020October 2025
> 3.10October 2021   October 2026
> 3.11October 2022   October 2027
> 3.12October 2023   October 2028
> 3.13October 2024   October 2029
> 3.14October 2025   October 2030
>
> This looks like it would mean in general supporting 4 versions of Python 
> and 5 for the LTS. 
> The .1 and LTS would drop a version against the .0
>
> I'd go for this, at least through the next cycle or so. 
> (Django 6.0 might look as if it's on the hook for the full 5 versions 樂 
> but I think we could revisit before then.)
>
> My concern is the paragraph in Tim's reply above that begins "Part of the 
> rationale for dropping Python versions after an LTS is was to avoid getting 
> "stranded" on a non-LTS version of Django." — I'm not sure we can do 
> anything there apart from maybe say that people have to update their 
> Python. (I'm not sure we have the capacity or duty to do more if folks are 
> lingering here?)
>
> How do we decide? Mariusz has opened the PR to drop both 3.6 and 3.7 
> support. 
> https://github.com/django/django/pull/13915
> We can merge the 3.6 stuff, but it would be nice to settle this. 
> (I don't know)
>
> Kind Regards,
>
> Carlton
>
>
> On Tuesday, 19 January 2021 at 20:36:21 UTC+1 Claude Paroz wrote:
>
>> When I see that Python 3.7 will be supported the whole time of the 4.0 
>> support period, it's enough for me. For the rest, let the people choose and 
>> see by themselves through the support graphs what their interest is. I 
>> think we should stop patronizing developers.
>>
>> Claude
>>
>

-- 
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/a616ce7b-2096-4800-957b-1f92e1a525a4n%40googlegroups.com.

Re: Permission to discuss

[Tim Graham]

django-users is suitable for that. This mailing list is limited to 
discussion of the development of Django itself.

On Tuesday, January 19, 2021 at 4:56:47 PM UTC-5 Benny wrote:

> Hi developers,
>
> I have an idea for a Django related project and I’d like to get input from 
> users and developers before I decide to move forward with it. This does not 
> directly apply to the Django backend or development, but I do believe input 
> from the developers would be just as valuable.
>
> So as to not violate any spamming/advertising policy, I’d like to ask 
> permission before launching an email to either (or both) groups. And to 
> that point, would permission to discuss here apply to the users group, or 
> should I ask there as well?
>
> Best,
> Benny

-- 
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/1964547a-09bb-4166-b637-a21541628b78n%40googlegroups.com.

Re: Rethink (?) how we handle security headers.

[Tim Graham]

I guess there have been a few different proposals here, but I imagined 
SECURITY_HEADERS would allow setting any security-related header without 
making changes in Django. If the setting is more than header/value pairs, 
then it seems this won't be the case.

On Tuesday, January 19, 2021 at 4:39:54 AM UTC-5 Adam Johnson wrote:

> I'd imagined the setting would be more like a roll-up of the existing 
> settings, so no need for parsing:
>
> SECURITY_HEADERS = {
> "REFERRER_POLICY": "same-origin",
> "HSTS": {
> "PRELOAD": True,
> "SECONDS": 1_000_000,
>  },
> }
>
>
> On Tue, 19 Jan 2021 at 01:30, Tim Graham  wrote:
>
>> The proposal seems to be a setting of the form:
>>
>> SECURITY_HEADERS = {
>> 'Strict-Transport-Security': 'max-age=60; includeSubDomains; preload',
>> ...
>> }
>>
>> Currently we have system checks to suggest 
>> setting SECURE_HSTS_SECONDS, SECURE_HSTS_PRELOAD, etc. Do you envision 
>> trying to keep these checks? It seems it'll be more complicated to parse 
>> and validate arbitrary string values instead of individual settings.
>>
>> It seems some headers may still need special handling in 
>> SecurityMiddleware. For example, 'Strict-Transport-Security' is only set if 
>> request.is_secure().
>> On Friday, August 21, 2020 at 12:53:33 PM UTC-4 Adam Johnson wrote:
>>
>>> A single SECURITY_HEADERS (or perhaps SECURITY) setting sounds good. 
>>> Would love to get CORS into core too.
>>>
>>> The Opener-Policy ticket has been marked as someday/maybe because the 
>>> header is still not widely supported.
>>>
>>> On Thu, 20 Aug 2020 at 00:02, James Bennett  wrote:
>>>
>>>> While I think Adam's right that adding one or two new settings
>>>> wouldn't be a problem, I do worry about the ongoing proliferation, and
>>>> it's a thing that I keep wanting to try to find the time to work on
>>>> but never actually succeed at.
>>>>
>>>> Separate from the suggestion of a generic way to add headers on every
>>>> response, I've been leaning for a while toward the idea of
>>>> consolidating the security-header settings the way we've already
>>>> consolidated database and template settings. We can paint the bikeshed
>>>> whatever color, but suppose for sake of an example name we add a
>>>> SECURITY_HEADERS setting, with each one configured under its own key.
>>>> That would allow X-Frame-Options, content sniffing, HSTS,
>>>> Referrer-Policy, opener policy, and future stuff like CSP, built-in
>>>> CORS, etc. to all be defined in a single place that doesn't
>>>> proliferate a huge number of new settings, or require adding and
>>>> supporting a new setting every time a new one comes along (which, with
>>>> security headers, is about twice a week these days).
>>>>
>>>> For now I think the best thing would be to accept the opener-policy
>>>> work as-is, then get consensus around a proposal for how future
>>>> security headers should be handled.
>>>>
>>>> -- 
>>>> 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/CAL13Cg8Uf3FdNtK6kbEdZ9Ja7sa5jhg4ptnUGotpzO8hj9B49g%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-develop...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/26f74d84-4a8a-41a7-8824-e016e3e15dcfn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/26f74d84-4a8a-41a7-8824-e016e3e15dcfn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> -- 
> 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/3ae8a31f-a53a-4415-8e51-6ce3faee85a1n%40googlegroups.com.

Re: Rethink (?) how we handle security headers.

[Tim Graham]

The proposal seems to be a setting of the form:

SECURITY_HEADERS = {
'Strict-Transport-Security': 'max-age=60; includeSubDomains; preload',
...
}

Currently we have system checks to suggest 
setting SECURE_HSTS_SECONDS, SECURE_HSTS_PRELOAD, etc. Do you envision 
trying to keep these checks? It seems it'll be more complicated to parse 
and validate arbitrary string values instead of individual settings.

It seems some headers may still need special handling in 
SecurityMiddleware. For example, 'Strict-Transport-Security' is only set if 
request.is_secure().
On Friday, August 21, 2020 at 12:53:33 PM UTC-4 Adam Johnson wrote:

> A single SECURITY_HEADERS (or perhaps SECURITY) setting sounds good. Would 
> love to get CORS into core too.
>
> The Opener-Policy ticket has been marked as someday/maybe because the 
> header is still not widely supported.
>
> On Thu, 20 Aug 2020 at 00:02, James Bennett  wrote:
>
>> While I think Adam's right that adding one or two new settings
>> wouldn't be a problem, I do worry about the ongoing proliferation, and
>> it's a thing that I keep wanting to try to find the time to work on
>> but never actually succeed at.
>>
>> Separate from the suggestion of a generic way to add headers on every
>> response, I've been leaning for a while toward the idea of
>> consolidating the security-header settings the way we've already
>> consolidated database and template settings. We can paint the bikeshed
>> whatever color, but suppose for sake of an example name we add a
>> SECURITY_HEADERS setting, with each one configured under its own key.
>> That would allow X-Frame-Options, content sniffing, HSTS,
>> Referrer-Policy, opener policy, and future stuff like CSP, built-in
>> CORS, etc. to all be defined in a single place that doesn't
>> proliferate a huge number of new settings, or require adding and
>> supporting a new setting every time a new one comes along (which, with
>> security headers, is about twice a week these days).
>>
>> For now I think the best thing would be to accept the opener-policy
>> work as-is, then get consensus around a proposal for how future
>> security headers should be handled.
>>
>> -- 
>> 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/CAL13Cg8Uf3FdNtK6kbEdZ9Ja7sa5jhg4ptnUGotpzO8hj9B49g%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/26f74d84-4a8a-41a7-8824-e016e3e15dcfn%40googlegroups.com.

Re: Adding Origin header checking to CSRF middleware (#16010)

[Tim Graham]

OWASP Cheat Sheet says, "It is important to note that [the SameSite 
Cookie] attribute should be implemented as an additional layer *defense in 
depth* concept. This attribute protects the user through the browsers 
supporting it, and it contains as well 2 ways to bypass it as mentioned in 
the following section 
. 
This attribute should not replace having a CSRF Token. Instead, it should 
co-exist with that token in order to protect the user in a more robust way."
On Tuesday, January 12, 2021 at 5:44:56 AM UTC-5 jacob...@gmail.com wrote:

> Shouldn't we consider to put the CSRF token onto the deprecation list 
> anyway?
> All browsers released later than 2017 support the 'SameSite' cookie 
> attribute , making the CSRF token 
> obsolete.
> I don't know what kind of policy the Django Project follows in deprecating 
> browsers, but we can expect 
> that IE, Edge<16, Safari<12, Chrome<51, etc. won't play a major role when 
> Django-4 (or maybe 5?) will be released.
>
> Strictly speaking, the CSRF token is a hack/workaround which in an ideal 
> world shouldn't be required anyway.
> And it always has been painful having to fiddle with it in my Django Form 
> Views.
>
> Just my two cents,
> Jacob 
>

-- 
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/915ff447-502e-45c2-8d18-bf5bee848c52n%40googlegroups.com.

Adding Origin header checking to CSRF middleware (#16010)

[Tim Graham]

Hello, I've updated this 10 year old patch but some more changes are 
needed. I'll target it for Django 4.0.
https://code.djangoproject.com/ticket/16010
https://github.com/django/django/pull/13829

Here are a few design decisions and questions that have come up:

1. It seems the main reason this wasn't merged 10 years ago is because the 
patch didn't consider cross-domain POSTs. At the time, there was only 
CSRF_COOKIE_DOMAIN to consider.

These days referer checking allows cross-domain POSTs by considering 
SESSION_COOKIE_DOMAIN,  CSRF_COOKIE_DOMAIN, and CSRF_TRUSTED_ORIGINS (along 
with the request's host) [0]. Unfortunately, these settings only include 
the domain or a wildcard for all subdomains like '*.example.com'. However, 
origin checking requires including the scheme and port (if non-default).

We could add another setting CSRF_ALLOWED_ORIGINS (taking naming 
inspiration from  CORS_ALLOWED_ORIGINS in django-cors-headers [1]) which 
would be a list of hosts, including the schema and port. For example:

CSRF_ALLOWED_ORIGINS = [
"https://example.com;,
"https://sub.example.com;,
"http://localhost:8080;,
"http://127.0.0.1:9000;,
]

Unfortunately such a name is very similar and not well differentiated from the 
already existing CSRF_TRUSTED_ORIGINS setting. That setting could possibly 
be deprecated as netlocs for referer checking could be parsed from 
CSRF_ALLOWED_ORIGINS.

(Another possibility would be to have a Django 4.0 upgrade step be 
modifying the hosts in CSRF_TRUSTED_ORIGINS to include the scheme. This 
would be backward incompatible if trying to run older versions of Django 
concurrently though.)

Following the pattern of django-cors-headers, another setting may be needed 
to support all subdomains.

CSRF_ALLOWED_ORIGIN_REGEXES = [
r"^https://\w+\.example\.com$;,
]

However, it's less straightforward (if possible at all) to extra netlocs 
from arbitrary regular expressions. I'm not sure that full regular 
expression support is really needed. Perhaps it would be enough to support 
asterisks in CSRF_ALLOWED_ORIGINS (e.g. '"https://*.example.com;). urlparse() 
can handle that case.

2. There's also a question of backward compatibility. Since 
CSRF_ALLOWED_ORIGINS would be empty by default, only same-origin requests 
will be allowed unless the new settings are set. I can't think of a useful 
deprecation path here, but perhaps a system check to flag an empty 
CSRF_ALLOWED_ORIGINS if CSRF_TRUSTED_ORIGINS isn't empty (or if 
CSRF_COOKIE_DOMAIN 
or SESSION_COOKIE_DOMAIN are used) could be helpful in giving a heads up.

3. OWASP Cheat Sheet Series [2] says, "If the Origin header is not present, 
verify the hostname in the Referer header matches the target origin." which 
suggests to me that referer checking can be skipped if the origin header 
can be verified. Agreed?

4. OWASP Cheat Sheet also has some discussion of when 'Origin' is 'null'. 
I'm not sure if Django's checking needs to consider this. Maybe it would be 
enough to discard a null header and fall back to referer checking.

Thanks for any feedback.

[0] 
https://github.com/django/django/blob/407d3cf39cd6a62f7277e401d646a4c7e8446879/django/middleware/csrf.py#L257-L281
[1] https://github.com/adamchainz/django-cors-headers
[2] 
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#checking-the-referer-header

-- 
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/953b044e-655c-4edc-a4ca-31bd82bacf77n%40googlegroups.com.

Re: Technical Board Decision Needed: Admin append_slash behaviour.

[Tim Graham]

I wouldn't object to a wontfix. It seems like we've already spent a lot of 
effort here for little benefit, if any.
On Thursday, January 7, 2021 at 8:16:57 AM UTC-5 carlton...@gmail.com wrote:

> OK, thanks all. So... 
>
> Two new options then: 
>
> 1. Add the catch-all view to admin to stop the unauthenticated probing, as 
> per the Security Teams initial idea, but not the AdminSite.append_slash 
> option.
> 2. Don't even add the catch-all, and close the ticket as wontfix. 
>
> A site concerned here still has the middleware option with 2, but I 
> imagine Jon arguing whether this is sufficiently secure by default.
>
> Additional points: 
>
> * Middleware option did come up in the original discussion and on the PR. 
> * It SEEMS to me that the catch-all view does serve it's purpose as as the 
> AdminSite.admin_view decorator redirects all non-staff requests equally to 
> login (whether they exist or not, because the catch-all view exists.) This 
> is prior to any per-view timing variation. (I think )
> * So I'd say Option 1 here — I'll adjust the PR on that basis, but if you 
> conclude that actually Option 2, do say. 
>
> Thanks again. This has been a difficult issue to think about and deal 
> with, and I do appreciate the input and guidance. 
>
> 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/836bbb46-0009-4e03-9a02-b9263800eafan%40googlegroups.com.

Re: Technical Board Decision Needed: Admin append_slash behaviour.

[Tim Graham]

As a non-technical board member, I'd prefer option 1. I also think that for 
most use cases, staff users are at least somewhat trusted and even if they 
are not, model enumeration isn't likely to be a security problem.

On Wednesday, January 6, 2021 at 5:07:44 AM UTC-5 carlton...@gmail.com 
wrote:

> Hi Uri. 
>
> Can I please ask that this discussion not get side-tracked. 
>
> I'm asking for a Technical Board decision on the specific question, under 
> the rules of DEP 10. 
>
> The PR in question has been in progress for six months, and we want to 
> resolve it in time for the Django 3.2 feature freeze next week. 
> Thanks. 
>
> On Wednesday, 6 January 2021 at 11:02:47 UTC+1 Uri wrote:
>
>> Hi,
>>
>> For security reasons, I would recommend protecting any url which starts 
>> with /admin/ (or the website's admin url prefix) with an HTTPS password 
>> from the web server directly (such as Nginx or Apache), so that even the 
>> login to the admin will be protected. You may consider adding this 
>> suggestion to Django's documentation. For example, if you enter 
>> https://en.speedy.net/admin/accounts/user/ you will be asked for an 
>> HTTPS authentication password. Only if you know the password, then you will 
>> be redirected to the login page, and only after you login you will be able 
>> to view the admin views. This increases security, as you will have to login 
>> twice. In my opinion you can consider adding this suggestion to Django's 
>> documentation.
>>
>> Thanks,
>> Uri Rodberg
>> Speedy Net
>> אורי
>> u...@speedy.net
>>
>>
>> On Wed, Jan 6, 2021 at 11:43 AM Carlton Gibson  
>> wrote:
>>
>>> Hi all, 
>>>
>>> I need to ask for a Technical Board decision on the resolution of Ticket 
>>> #31747. 
>>>
>>> Ticket #31747: Avoid potential admin model enumeration
>>> https://code.djangoproject.com/ticket/31747
>>>
>>> PR #13134: Fixed #31747 -- Fixed model enumeration via admin URLs. 
>>> https://github.com/django/django/pull/13134
>>>
>>>
>>> ## Summary
>>>
>>> The initial issue is that there is a difference in HTTP response code 
>>> for admin
>>> URLs depending on whether a URL routes to an existing model or not:
>>>
>>> http://127.0.0.1:8000/admin/auth/user/ -> 302 to login
>>> http://127.0.0.1:8000/admin/auth/group/ -> 302 to login
>>> http://127.0.0.1:8000/admin/auth/foo/ -> 404
>>>
>>> In principle an attacker could use this to leak information about the 
>>> app's
>>> models, which could be part of a further attack. 
>>>
>>> This was originally reported to the Django Security Team, who declined 
>>> to take
>>> it as a security issue, but recommended adding a final catch-all view to 
>>> the
>>> admin, which would redirect all unauthenticated requests to login, thus 
>>> masking
>>> the private model info. 
>>>
>>> Jon Dufresne picked this issue up, and submitted a PR, but in so-doing 
>>> noticed
>>> that a very similar (the same?) issue occurred with APPEND_SLASH 
>>> behaviour in
>>> the admin too. (Try URLs without the slash, looking for a redirect to 
>>> the 
>>> correct URL **before** being redirected to login.)
>>>
>>> The initial thought was that we might need to remove APPEND_SLASH URL
>>> normalisation for the admin. We were able to avoid that by restricting 
>>> the
>>> append_slash-style URL normalisation for the admin to authenticated staff
>>> users. This addresses the main force of the original report (which is
>>> unauthenticated users remotely probing the site) but Jon noted that it 
>>> still
>>> allows a staff-user to potentially discover the existence of model for 
>>> which 
>>> they don't have permissions in this way. 
>>>
>>> In order to avoid this last threat Jon felt that we still needed to 
>>> disable
>>> append slash URL normalisation for the admin. 
>>>
>>> In contrast, I felt the threat of a staff user discovering models in 
>>> this way
>>> would apply to only a tiny fraction of all installations, and that the 
>>> utility
>>> of URL normalisation vastly outweighs that on balance. 
>>>
>>> We have a trade-off between balancing privacy and usability here. 
>>>
>>> After much discussion and thought, Jon and I came to agree (I think ) 
>>> that an
>>> `AdminSite.append_slash` toggle was needed to control the behaviour 
>>> here. If
>>> privacy is paramount, you can set that to `False` to disable the URL
>>> normalisation in the admin. If you don't need to keep models secret from 
>>> staff
>>> users you can have it `True` and still get the benefits of append slash
>>> behaviour. 
>>>
>>> We felt this was something that everyone could live with. Wherever you 
>>> are on
>>> the spectrum, for the simplest case, where you're just using the default 
>>> admin
>>> site, you toggle the behaviour with a single line in your URL conf: 
>>>
>>> from django.contrib import admin
>>>
>>> admin.site.append_slash = ...set True/False as you want here...
>>>
>>> (On the way, we also found a way of opting-out for a single ModelAdmin, 
>>> but
>>> let's not talk about 

Re: SynchronousOnlyOperation: bug or misconfiguration?

[Tim Graham]

Hi, this mailing list isn't appropriate for "is it a bug?" questions. 
Please use django-users instead.

On Friday, December 18, 2020 at 11:00:30 AM UTC-5 Federico Capoano wrote:

> I have a celery task which performs queries and network operations.
>
> When deployed with celery with gevent concurrency, I occasionally (but not 
> always) get reports of SynchronousOnlyOperation exceptions being raised.
>
> I described the problem in detail on StackOverflow: SynchronousOnlyOperation 
> from celery task using gevent execution pool 
> 
> .
>
> I tried debugging the issue and looking for information about similar 
> issues with django+celery+gevent with little luck, but I have started to 
> wonder if the fact that Django is raising this error there is a bug.
>
> I see this error is raised if django detects an event loop, should this 
> apply also to when gevent is using the eventloop?
>
> Thanks in advance
> Best regards
> Federico
>

-- 
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/341402be-2684-42cc-b4ac-77b778952794n%40googlegroups.com.

Re: App label with dot

[Tim Graham]

app_label "should be a valid Python identifier." Dots aren't allowed.

https://docs.djangoproject.com/en/stable/ref/applications/#django.apps.AppConfig.label

On Friday, December 18, 2020 at 10:47:45 AM UTC-5 Federico Capoano wrote:

> Defining the app_label of an AppConfig with a dot, like "myproject.subapp" 
> is allowed, but raises an exception in the migration framework (too many 
> values to unpack).
>
> Did anybody notice this?
>
> Is it supposed to be allowed or not at all?
>
> Best regards
> Federico Capoano
>

-- 
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/134214d9-e3c1-4f74-9920-f0a62d4d675bn%40googlegroups.com.

Re: Proposal: Make the domain part of the Email Message-ID configurable

[Tim Graham]

You don't need to announce a patch on the mailing list. Instead check 
"According to the ticket's flags 
,
 
the next step(s) to move this issue forward are" on the ticket and update 
it accordingly. Thanks.

On Monday, December 7, 2020 at 8:11:12 AM UTC-5 jacob...@gmail.com wrote:

> Here is a pull request to fix https://code.djangoproject.com/ticket/6989 
> https://github.com/django/django/pull/13728
>
>

-- 
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/4c9097e0-2a61-449e-9e76-cf26243213b3n%40googlegroups.com.

Re: Feedback on PR "Add warning when inspectdb find multi-columns primary keys"

[Tim Graham]

What value does the traceback add for you? I'd think that most users don't 
care about the inner workings of inspectdb.

On Tuesday, December 1, 2020 at 10:25:54 AM UTC-5 damio wrote:

> Since the warning is to stderr, it doesn't break the main usecase of doing 
> "python manage.py inspectdb > models.py"
>
> Django use comment to tell that there was an error when the table 
> introspection failed, but it should be a with a detailed traceback in my 
> opinion.
>
> But it looks like it's me who have an unpopular opinion so I will 
> implement the PR with a comment instead of a warning.
>
> Le mar. 1 déc. 2020 à 16:18, Tim Graham  a écrit :
>
>> Please try to make it easy to understand the issue without looking at 
>> tickets and pull requests. Even after I did that, I couldn't find why you 
>> believe it should be a warning and not a comment. Why is this situation 
>> different from all the other places Django uses comments to indicate where 
>> introspection may not be perfect?
>>
>> Wouldn't a warning break the documented usage of inspectdb because there 
>> would be non-Python text in models.py from the warning output? 
>>
>> $ python manage.py inspectdb > models.py
>>
>> On Tuesday, December 1, 2020 at 9:12:53 AM UTC-5 damio wrote:
>>
>>> Hi,
>>>
>>> I got some feedback on the ticket that I should use comments to display 
>>> the warning instead of stderr, since I don't really agree with that, I'm 
>>> requesting more feedback to know which way I should do it.
>>>
>>> Ticket: https://code.djangoproject.com/ticket/32234
>>> PR: https://github.com/django/django/pull/13736
>>>
>>> Thanks,
>>> Damien
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/NhhpjqeQ8MQ/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> django-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/b455bb92-6b91-4f2f-bdaa-8932d3cb2893n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/b455bb92-6b91-4f2f-bdaa-8932d3cb2893n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/f8ce3796-dc64-470d-8ff5-ec0f400c11b4n%40googlegroups.com.

Re: Feedback on PR "Add warning when inspectdb find multi-columns primary keys"

[Tim Graham]

Please try to make it easy to understand the issue without looking at 
tickets and pull requests. Even after I did that, I couldn't find why you 
believe it should be a warning and not a comment. Why is this situation 
different from all the other places Django uses comments to indicate where 
introspection may not be perfect?

Wouldn't a warning break the documented usage of inspectdb because there 
would be non-Python text in models.py from the warning output? 

$ python manage.py inspectdb > models.py

On Tuesday, December 1, 2020 at 9:12:53 AM UTC-5 damio wrote:

> Hi,
>
> I got some feedback on the ticket that I should use comments to display 
> the warning instead of stderr, since I don't really agree with that, I'm 
> requesting more feedback to know which way I should do it.
>
> Ticket: https://code.djangoproject.com/ticket/32234
> PR: https://github.com/django/django/pull/13736
>
> Thanks,
> Damien
>

-- 
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/b455bb92-6b91-4f2f-bdaa-8932d3cb2893n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Tim Graham]

Dropping support for Python versions as they go EOL in existing Django 
releases would be disruptive. Distros "support" Python versions longer than 
the PSF does. If a Django version inadvertently breaks compatibility with 
an old version of Python because we stop testing with it, we'll get bug 
reports about it. It's happened before although I can't remember the exact 
circumstances offhand. It's not good to put users in the position of 
unpredictably being unable to update to a Django security release because 
their Python is old and a security update inadvertently broke 
compatibility. That would be a heavy stick whereas there's already been 
some hesitance here to the "carrot" argument of the current policy which 
restricts older Python users to a Django LTS.

I also thought about something like "support X versions of Python," and 
while I haven't studied the implications in detail, it doesn't strike me as 
significantly better or worse than the alternatives. I think we should wait 
a few years to see how Python's annual releases interplay with Linux 
distros before considering making Django's Python support policy more 
aggressive in dropping old Python versions.
On Tuesday, November 24, 2020 at 3:41:29 AM UTC-5 carlton...@gmail.com 
wrote:

> Hi Tim. 
>
> Thanks for the breakdown, and context on the rationale. 
>
> Do you think we can drop support for Python versions as they go EOL? 
> i.e. for Django 2.2 we COULD HAVE stopped testing against Python 3.5 when 
> it went EOL earlier this year. 
> Given the backport policy, there's no reason to suspect it would break, 
> but we'd not guarantee that.
> (I do worry a bit about saying we support somebody else's EOL software...) 
>
> Assuming that, there's a diagram in PEP 602 (on the Annual Release Cycle) 
> that shows we'd essentially be on the hook for 5 Python versions forever.
> https://www.python.org/dev/peps/pep-0602/#the-testing-matrix
>
> If that's too many, how would something like "Django supports the latest 4 
> versions of Python" sound? 
> This would mean dropping the oldest version ≈12 months before it reached 
> end of life. 
> (We'd have to think about mapping to our 8 month release cycle.)
>
> 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/583eb421-345f-4e19-b713-aeac9a1bca55n%40googlegroups.com.

Re: Hello Everyone

[Tim Graham]

Hi Vineet, this is an extremely common question on this mailing list. 
Please search the archives for something like "contribute to django" and 
you'll see many answers. Have fun!

On Monday, November 23, 2020 at 8:40:47 AM UTC-5 vinee...@gmail.com wrote:

> I am Vineet Sharma, pursing computer science and Engineering as my major 
> subject, I want to contribute to django and would love to be a part of the 
> community. I myself have been using django for past 1 year and now want to 
> contribute to it. I am looking forward to GSOC 2021 as a part of django 
> community and would love to be guided by you on my first steps. 
>
> Thank You
> Vineet Sharma
>
>

-- 
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/c854bdb7-340b-4f92-aa09-48cb612a39aen%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Tim Graham]

Part of the rationale for dropping Python versions after an LTS is was to 
avoid getting "stranded" on a non-LTS version of Django. For example, if we 
keep Python 3.7 support in Django until Python 3.7 is end of life in June 
2023, that would probably make Django 4.1 the latest version to support it 
(4.2 is scheduled for April 2023, a few months before Python 3.7 EOL). At 
that point, someone stuck on Python 3.7 would receive Django security 
updates a few months longer if they had stuck with 3.2 LTS (supported until 
April 2024) compared with Django 4.1 (supported until December 2023). 
That's not so bad, but if the version following an LTS is the last to 
support a particular version of Python, like would happen with Django 5.0 
and Python 3.8 in my forecast below, then this "Django security gap" for a 
particular Python version would be one year.

Historically, Django has supported 3-5 version of Python. With Python 
moving to a yearly release cadence, that's going to increase the number of 
versions of Python that Django has to support under the current policy to 
4-6. Amending the Python version support policy as suggested would mean it 
would always be 5-6. That makes for some large build matrices. I'm 
especially thinking about the downstream effects to all the third party 
apps that follow Django's Python support.

(Incidentally, it occurred to me that more rapid Python releases *might* 
actually mean that being a little more aggressive in dropping old Python 
versions from Django might be less disruptive than it was in the past, 
that's if new Python versions make it out to the distros more quickly. It's 
probably too soon to tell, but someone who follows distro releases might be 
able to give a forecast.)

This chart assumes "support a Python version up to the Django release 
that's a few months before that Python EOL." I didn't proof it super 
carefully but it should give a general idea of what's coming.
- Stars indicate of version of Python that wouldn't be supported under the 
current "Typically, we will support a Python version..." guideline.
- Dates in parentheses indicate Python version support added after a major 
version's initial release.

Django  ReleasedEnd of life
2.2 LTS April 2019  April 2022  3.5, 3.6, 3.7, 3.8, 3.9
3.0 December 2019   April 2021  3.6, 3.7, 3.8, 3.9
3.1 August 2020 December 2021   3.6, 3.7, 3.8, 3.9
3.2 LTS April 2021  April 2024  3.6, 3.7, 3.8, 3.9, 3.10 
(Oct 2021), 3.11 (Oct 2022)
4.0 December 2021   April 2023  3.7*, 3.8, 3.9, 3.10, 3.11 
(Oct 2022)
4.1 August 2022 December 2023   3.7*, 3.8, 3.9, 3.10, 3.11 
(Oct 2022)
4.2 LTS April 2023  April 2026  3.8, 3.9, 3.10, 3.11, 3.12 
(Oct 2023), 3.13 (Oct 2024)
5.0 December 2023   April 2025  3.8*, 3.9*, 3.10, 3.11, 
3.12, 3.13 (Oct 2024)
5.1 August 2024 December 2025   3.9*, 3.10, 3.11, 3.12, 
3.13 (Oct 2024)
5.2 LTS April 2025  April 2028  3.10, 3.11, 3.12, 3.13, 
3.14 (Oct 2025), 3.15 (Oct 2026)

Python  Released   End of life
3.5 September 2015 September 2020
3.6 December 2016  December 2021
3.7 June 2018  June 2023
3.8 October 2019   October 2024
3.9 October 2020   October 2025
3.10October 2021   October 2026
3.11October 2022   October 2027
3.12October 2023   October 2028
3.13October 2024   October 2029
3.14October 2025   October 2030

References
Status of Python branches: 
https://devguide.python.org/#status-of-python-branches
Annual release cycle for Python: https://www.python.org/dev/peps/pep-0602/

On Saturday, November 21, 2020 at 12:52:08 AM UTC-5 carlton...@gmail.com 
wrote:

> Note that this is discussing support in Django 4.0 (which is the main 
> development branch after stable/3.2.x is created). 
>
> 4.0 will be released December 2021. Python 3.6 is EOL that very month
>
> > 3.6 2021-12-23
>
> The next version of Django (3.2) will support Python 3.6
>
>

-- 
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/e1e965a3-9dfd-4c9a-bb36-eca8d970abe8n%40googlegroups.com.

Re: Adding a security concerned feature

[Tim Graham]

I'm not convinced that a system check promoting security by obscurity adds 
much value. The original poster wrote "sometimes it can be a security 
concern." Maybe that's the case (how so?) but for most sites I would say 
it's not.
On Wednesday, November 18, 2020 at 7:33:47 AM UTC-5 Carles Pina Estany 
wrote:

>
> Hi,
>
> On Nov/16/2020, Carles Pina i Estany wrote:
>
> > Either way: I'd be happy to write a django check to make sure that
> > 'admin/' is not routed to admin.
>
> Regarding this check: this morning I've done a very preliminary/for fun
> draft to play with.
>
>
> https://github.com/cpina/django/commit/199c2fb26dc6b323195b8136bda596d1cc9857f1
>
> I'm not sure what is the best way to check if /admin is routed to
> django.contrib.admin. At the moment it's doing:
>
> resolve(admin_url)._func_path == 'django.contrib.admin.sites.index'
>
> Yes, I know! :-)
>
> I could also do something along the lines of:
> resolve(admin_url).func.admin_site == admin.site
>
> This causes problems on the unit test side (need to import admin.site).
> Still I don't really like it.
>
> Does anyone have any better suggestions or comments? (or code pointer).
> Otherwise later on I'll have another look.
>
> Thank you very much,
>
> -- 
> Carles Pina i Estany
> https://carles.pina.cat
>

-- 
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/df485a53-2ad2-461f-95c8-f8f3857d67dbn%40googlegroups.com.

Re: Primary Key AutoField -> UUID Field

[Tim Graham]

Hi Brian, There are existing threads about that (try searching the archives 
for 'default pk' to find some of them). Here's a PR that adds the setting 
you described: https://github.com/django/django/pull/13179. Perhaps you 
would like to try it out and see if it meets your needs.

On Saturday, November 14, 2020 at 11:32:38 AM UTC-5 brianrc...@gmail.com 
wrote:

> Feature Request:
>
> I like to use the UUIDField as the primary key in my models, and I think 
> it would be nice to have django expose a setting in the settings.py to 
> override the default primary key on models. 
>
> Currently, if I don’t specify a field as the primary key, Django 
> automatically uses an AutoField (auto-incrementing integer). I’d like to be 
> able to automatically use a UUID field, but then still be overridden in a 
> specific model if I specify a different primary key.
>
> Brian Carter
> brianrc...@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/2cd6c330-0439-4ee7-88f5-b2ac708c78e0n%40googlegroups.com.

Re: Advancing with the Triage & Review Team idea.

[Tim Graham]

t least for Merge PRs.
>>
>> The idea was to have a team for folks that are active on repo. This would 
>> provide some recognition for efforts, allow extra hands to help manage 
>> tickets — closing spam ones seems relevant this week…  — and so on. 
>>
>> The GitHub Team I created has GitHub’s Triage role. This allows for one 
>> thing to request a review from a Merger. Nick is the only member of that 
>> team currently (see above about pausing) but it’s worked well when he's 
>> reviewed PRs from the backlog, seen that they're ≈ready and asked for a 
>> review from me. This has been very helpful, and quite smooth. (It’s in a 
>> similar vein to marking tickets on Trac Ready for Commit, which also helps 
>> them to show about the mass.) 
>>
>> Ultimately I think a Triage & Review Team is an opportunity to widen the 
>> contributor pool and spread the work.
>>
>> I would suggest the following list for members to flesh out the team 
>> initially. Happy to add more, but the idea was currently active (if 
>> you're offended I missed you, sorry, do shout! — not intentional. ) 
>>
>> - David Smith
>>
>> - Hasan Ramezani
>>
>> - Jon Dufresne
>>
>> - Nick Pope
>>
>> - Simon Charette 
>>
>> - Tim Graham
>>
>> (I didn’t include Mergers or TB members.)
>>
>> Some other points: 
>>
>> - I’d like to start measuring non-commit contributions somehow. This is 
>> something I’m thinking about but for now I think by-eye is sufficient. 
>>
>> - I’d be happy to make the list twice as long. 
>>
>> - As I say, currently active — we should review each cycle. 
>>
>> - It’s still all men — but the team would provide a way of recognising 
>> anyone finding Triage as a Hobby appealing, so I’d hope it would act as 
>> an incentive to participate, with a clear path to recognition (and from 
>> there candidacy in a TB election say…)
>>
>> Hopefully that’s clear enough. Can I ask for thoughts, and if we’re keen, 
>> what would we need to do to make it formal?
>>
>> Thanks all. 
>>
>> 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-develop...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/c34045c8-55fa-4073-b64e-20f2d719d12an%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/c34045c8-55fa-4073-b64e-20f2d719d12an%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>

-- 
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/4937819d-d59e-40fa-93eb-b6afe08eb0b7n%40googlegroups.com.

Re: Proposal: Make the domain part of the Email Message-ID configurable

[Tim Graham]

Hi, I think https://code.djangoproject.com/ticket/6989 has some discussion 
related to this.

On Sunday, September 6, 2020 at 7:30:15 AM UTC-4 jacob...@gmail.com wrote:

> When Django's mail subsystem generates an email, it creates a unique 
> Message-ID. This is a requirement specified in RFC2822.
> The domain part of that Message-ID is generated by the Python network 
> utilities. It defacto is the domain name determined by a reverse DNS lookup.
>
> This can cause some problems:
>
>1. Django web services often run on private networks and its DNS 
>resolution could make that name quite common, such as 
>1.0.0.10.in-addr.arpa. This reduces the entropy to the generated 
>Message-IDs.
>2. It may expose some details of the internal network setup. Not every 
>sysadmin wants that.
>
>
> Current state
> The Message-ID is generated by:
> django.core.mail.message.EmailMessage.message() 
> Currently there is no way to configure the domain part inside this method.
>
> Proposed state
> Therefore I would suggest to add a new configuration directive to Django, 
> say EMAIL_MESSAGEID_FQDN. Another possibility would be to allow to 
> replace the hard-coded Message-ID generator email.utils.make_msgid() with 
> a self-written callable.
>
>

-- 
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/f94782f9-739d-4902-a24d-763cbc249e12n%40googlegroups.com.

Re: Updates to PR are not reflected in Jenkins, checks failing

[Tim Graham]

Hi, I'd try rebasing your branch against master to eliminate the merge 
conflict.

On Monday, August 31, 2020 at 4:37:15 PM UTC-4 ba...@google.com wrote:

> Hi All!
>
> I have an open PR  and am 
> having difficulty getting the Jenkins checks to pass. I have amended my 
> original commit a few times but these changes are not reflected in Jenkins.
>
> One test, test_middleware_headers, was failing with my original commit. I 
> had forgotten to update this test to reflect the new default header I added 
> to the security middleware. I added the new header to the list of expected 
> headers in this test and amended my commit. 
>
> The checks were run again with new builds but the changes I made to the 
> commit were not reflected in Jenkins. The error message about this failing 
> test did not change at all. In Jenkins it appears that this test is not 
> altered as the expected output of the test has not been updated to reflect 
> the changes I made to it. However, I can see that the changes to this test 
> were added as a part of my commit in test_settings.py.
>
> This test passes locally but does not pass on any configuration in 
> Jenkins. How can I get my changes to this test to reflect correctly in 
> Jenkins so that the checks will pass?
>
> Thank you! 
>

-- 
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/7b9cba21-7c65-4549-9d76-b69bf763ae93n%40googlegroups.com.

Re: Make tag name a variable in form templates

[Tim Graham]

My point is that if Django used variables for tag names in its widget 
templates, it would suggest developers write code that's inconsistent with 
Django's design philosophy. As was pointed out with things like the 'type' 
attribute, these templates aren't meant to be generic templates for web 
components.
On Friday, July 24, 2020 at 2:47:37 PM UTC-4 1337 Shadow Hacker wrote:

> You're absolutely right, except that I'm not trying to contribute a 
> datepicker in Django, i'm not trying to make a reusable datepicker, I'm 
> just trying to change the tag name as easily as I can change the tag 
> attributes because it's now a valid W3C standard.
>
>

-- 
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/e9ed300b-a845-49db-83a3-011460577550n%40googlegroups.com.

Re: Make tag name a variable in form templates

[Tim Graham]

A datepicker is rather different from a plain TextInput widget so I think 
it's good design to use a separate widget. If Django provided datepicker 
functionality, I'm fairly sure it would be provided as a separate widget 
rather than instructing users to use something like 
forms.TextInput(tag='duet-date-picker'). Consider widgets 
like NumberInput,  EmailInput, URLInput. We use separate widgets rather 
than something like forms.TextInput(input_type='number').
On Friday, July 24, 2020 at 1:18:27 PM UTC-4 1337 Shadow Hacker wrote:

> If I understand correctly:
>
> - changing attrs declaratively is "clean enough"
> - changing the tag input declaratively is "not clean enough, a custom 
> widget and template must be done"
>
> This seems contradictory to me.
>
> Should I subclass every widget to add a custom template that allows 
> changing the tag name ?
>

-- 
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/c1d3eb5d-b5aa-4b12-a585-2e1b74d0c68cn%40googlegroups.com.

Re: Make tag name a variable in form templates

[Tim Graham]

For me, a custom widget (that could use its own template) looks cleaner. 
Something like birth_date=DatePicker() seems more readable and doesn't 
require repeating "tag='duet-date-picker'"" each time. If you prefer your 
one-line version, you could override the input.html template and make the 
tag name a variable. I wouldn't advocate for that change in Django's 
input.html template.
On Friday, July 24, 2020 at 8:07:10 AM UTC-4 1337 Shadow Hacker wrote:

> For those who haven't followed, I'll try to re-explain prior to showing 
> example code:
>
> Currently, we can change the attrs declaratively without going through 
> whatever override/boilerplate. 
>
> In 2020, we can use custom elements, which means that we also need to 
> change the tag name.
>
> We don't need special constructors because custom elements configures with 
> attrs, which are already available declaratively.
>
> Now for some examples:
>
> class YourForm(forms.ModelForm):
> class Meta:
> model = YourModel
> widgets = dict(
>  birth_date=forms.TextInput(attrs={'type': 'date', 'max': 
> max_date})
> )
>
> Victory ! We now have a native date field with a one-liner ! But what if 
> we want to change to a duet date picker ? You need to change the tag name 
> from "input" to "duet-tag-picker":
>
> forms.TextInput(attrs={'type': 'date', 'max': max_date}, 
> tag='duet-date-picker')
>
> It seems the reason for being able to set attrs this way but not the tag 
> name too is because this was designed prior to the custom element W3C 
> standard that's now implemented in every browser.
>
>

-- 
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/06c4b43d-2f30-47db-93ae-5c12b75457f3n%40googlegroups.com.

Re: Should the docs suggest namespace packages?

[Tim Graham]

(It was already reverted in 578b3046e3b4adc43655bb5dd955054b7bf19f89. Sorry 
if raising a related issue on this thread was confusing.)

On Sunday, July 19, 2020 at 4:27:59 PM UTC-4 Aymeric Augustin wrote:

> I was still planning to revert ccc25bf. It's just a matter of finding time.
>
> -- 
> Aymeric.
>
>
> On 19 Jul 2020, at 22:25, Tim Graham  wrote:
>
> On the topic of namespace packages, I noticed this line in the 3.1 release 
> notes:  "Migrations are now loaded also from directories 
> without __init__.py files." https://code.djangoproject.com/ticket/30300
>
> The ticket's rationale seems to be "We've just finished migrating our 
> codebase to all-python 3, and nuked all our __init__py files. We are now 
> upgrading to Django 2.1, and noticing the various places where they're 
> still de-facto required by Django. This particular case seemed unnecessary 
> and easy to fix."
>
> Another commenter remarked, "We had a similar issue with test discovery. 
> One of our developers read an article that __init__.py files are not 
> required on Python3 and started removing them. Everything seemingly worked 
> but some tests were not discovered and did not run in CI (which made it 
> difficult to spot). I think Django should not required them if technically 
> possible or at least it should be made clear in the documentation (sorry if 
> I overlooked it)."
>
> Supporting namespace packages without a real use case seems contrary to 
> the consensus in this thread (which I see as not promoting implicit 
> namespace packages). Based on that consensus, my inclination wouldn't be to 
> try to make Django work with as few __init__.py files as possible. What do 
> you think?
>
>
> On Thursday, May 21, 2020 at 7:52:49 AM UTC-4 Adam Johnson wrote:
>
> +1 for reverting ccc25bf .
>>
>> On Wed, 20 May 2020 at 19:54, Aymeric Augustin <
>> aymeric@polytechnique.org> wrote:
>>
> Hello,
>>>
>>> Commit ccc25bf refers to ticket #23919 in the commit message. In that 
>>> ticket, I argued that the __init__.py files should be kept: 
>>> https://code.djangoproject.com/ticket/23919#comment:102. No one brought 
>>> a counter argument.
>>>
>>> It's weird that the __init__.py files were removed anyway without 
>>> further discussion (that I can find with my browser's search on that page, 
>>> at least).
>>>
>>> It's fairly minor, but I think thatccc25bf should be reverted.
>>>
>>
>>> Best regards,
>>>
>>> -- 
>>> Aymeric.
>>>
>>>
>>>
>>> On 20 May 2020, at 14:58, René Fleschenberg  
>>> wrote:
>>>
>>> On Github, Tim pointed out that with
>>>
>>> https://github.com/django/django/commit/ccc25bfe4f0964a00df3af6f91c2d9e20159a0c2
>>> ,
>>> various __init__.py files in Django's own code were removed.
>>>
>>> I tend to say it would be good to revert that change. Or we could update
>>> the docs only, since they serve much more directly as an example for
>>> user code.
>>>
>>> -- 
>>> René Fleschenberg
>>>
>>> -- 
>>> 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/5d689d5c-01ab-d017-249c-a53a6d9b1f87%40fleschenberg.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-develop...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/C9E429E5-DC4C-4C47-8126-17B32D31D245%40polytechnique.org
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/C9E429E5-DC4C-4C47-8126-17B32D31D245%40polytechnique.org?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> -- 
>> 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

Re: Should the docs suggest namespace packages?

[Tim Graham]

On the topic of namespace packages, I noticed this line in the 3.1 release 
notes:  "Migrations are now loaded also from directories 
without __init__.py files." https://code.djangoproject.com/ticket/30300

The ticket's rationale seems to be "We've just finished migrating our 
codebase to all-python 3, and nuked all our __init__py files. We are now 
upgrading to Django 2.1, and noticing the various places where they're 
still de-facto required by Django. This particular case seemed unnecessary 
and easy to fix."

Another commenter remarked, "We had a similar issue with test discovery. 
One of our developers read an article that __init__.py files are not 
required on Python3 and started removing them. Everything seemingly worked 
but some tests were not discovered and did not run in CI (which made it 
difficult to spot). I think Django should not required them if technically 
possible or at least it should be made clear in the documentation (sorry if 
I overlooked it)."

Supporting namespace packages without a real use case seems contrary to the 
consensus in this thread (which I see as not promoting implicit namespace 
packages). Based on that consensus, my inclination wouldn't be to try to 
make Django work with as few __init__.py files as possible. What do you 
think?


On Thursday, May 21, 2020 at 7:52:49 AM UTC-4 Adam Johnson wrote:

> +1 for reverting ccc25bf .
>
> On Wed, 20 May 2020 at 19:54, Aymeric Augustin <
> aymeric@polytechnique.org> wrote:
>
>> Hello,
>>
>> Commit ccc25bf refers to ticket #23919 in the commit message. In that 
>> ticket, I argued that the __init__.py files should be kept: 
>> https://code.djangoproject.com/ticket/23919#comment:102. No one brought 
>> a counter argument.
>>
>> It's weird that the __init__.py files were removed anyway without further 
>> discussion (that I can find with my browser's search on that page, at 
>> least).
>>
>> It's fairly minor, but I think that ccc25bf should be reverted.
>>
>> Best regards,
>>
>> -- 
>> Aymeric.
>>
>>
>>
>> On 20 May 2020, at 14:58, René Fleschenberg  
>> wrote:
>>
>> On Github, Tim pointed out that with
>>
>> https://github.com/django/django/commit/ccc25bfe4f0964a00df3af6f91c2d9e20159a0c2
>> ,
>> various __init__.py files in Django's own code were removed.
>>
>> I tend to say it would be good to revert that change. Or we could update
>> the docs only, since they serve much more directly as an example for
>> user code.
>>
>> -- 
>> René Fleschenberg
>>
>> -- 
>> 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/5d689d5c-01ab-d017-249c-a53a6d9b1f87%40fleschenberg.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-develop...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/C9E429E5-DC4C-4C47-8126-17B32D31D245%40polytechnique.org
>>  
>> 
>> .
>>
>
>
> -- 
> 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/d725cf0c-b0bd-4fe0-83b0-7315d0c742ben%40googlegroups.com.

Re: Making startproject's settings more 12-factor-y

[Tim Graham]

Have you read past discussions on the mailing list?

For example:

Making Django more PaaS-friendly
https://groups.google.com/d/topic/django-developers/BAGhOKXGj4I/discussion

Searching the archives for "12-factor" yields some other results.

That may help you to craft your proposal.

On Friday, June 5, 2020 at 5:45:07 PM UTC-4, Kit La Touche wrote:
>
> I'm interested in reducing the distance from running `startproject` to 
> having a deployable Django app, having recently had a number of 
> interactions with junior devs interested in using Django but finding 
> deployment a nightmare. Some of this is of course on the other side, on the 
> PaaS of choice, but some of it can (and I think should) be done on the 
> Django side.
>
> I'd like to start small. If I made a PR to replace a few key settings with 
> "get from the env, or fall back to this default", would people be 
> interested in approving that? I hope so!
>
> --Kit
>

-- 
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/a45204c6-5475-4ee9-a467-78c66736cfado%40googlegroups.com.

Re: Implement QuerySet.__contains__?

[Tim Graham]

(You can reopen https://code.djangoproject.com/ticket/24141 rather than 
creating a new ticket.)

On Friday, June 5, 2020 at 9:06:48 AM UTC-4, Aymeric Augustin wrote:
>
> If people agree QuerySet.contains() should be added, how do we move 
> forward?
>
>
> Yes, if there's no major new argument in a couple days, we can assume 
> consensus on adding .contains().
>
> * Create a ticket in Trac. Point to this discussion and to the previous 
> ticket where .contains() was suggested.
> * Submit a pull request in GitHub with code, tests, docs. This is worth 
> mentioning in the changelog.
>
> There's a lot of details in the docs, in the Contributing Guide, about how 
> to do allD this right.
>
> -- 
> Aymeric.
>
>
>
> On 5 Jun 2020, at 13:58, Johan Schiff > 
> wrote:
>
> Shai does make a good point about changing a well documented behaviour. 
> That argument wins me over.
>
> Adding .contains() and updating the documentation goes a long way to make 
> it easier for developers.
>
> Best case would be that Dajngo does not make assumptions about what the 
> developer wants, but to implement __len__(), __bool__() and __contains__(), 
> we have to assume one method or the other. I still think the wrong call was 
> made here, but changing it now is too much pain. *(Assuming queryset 
> should be evaluated is probably correct in most cases, but sometimes adds a 
> big performance hit when the code goes into production and the dataset 
> grows - code that looks reasonable and works like a charm in dev will cause 
> trouble in production. Assuming the opposite would have added a tiny 
> performance hit in most cases, but avoided the big one.)*
>
> Since I'm new here:
> If people agree QuerySet.contains() should be added, how do we move 
> forward?
> I'd be willing to write some code with tests and add a ticket, if that's 
> helpful.
>
> ‪Le ven. 5 juin 2020 à 11:42, ‫אורי‬‎ > a 
> écrit :‬
>
>> Hi,
>>
>> I'm thinking, maybe instead of:
>>
>> if obj in queryset:
>>
>> Users should write:
>>
>> if obj in list(queryset):
>>
>> Which I understand is already working? Why does the first line (without 
>> list()) should work anyway?
>>
>> And if users want performance, why not write:
>>
>> if queryset.filter(pk=obj.pk).exists():
>> אורי
>> u...@speedy.net 
>>
>>
>> On Tue, Jun 2, 2020 at 11:57 AM Johan Schiff > > wrote:
>>
>>> Is there a specific reason Djangos QuerySet does not implement 
>>> __contains__? It doesn't seem very complicated to me, but maybe I'm missing 
>>> something.
>>>
>>> When checking if an object is in e queryset I always use code lite this:
>>> if queryset.filter(pk=obj.pk).exists():
>>>
>>> The pythonic way would be:
>>> if obj in queryset:
>>>
>>> The way I understand it this latter version will fetch all objects from 
>>> queryset, while the first one is a much leaner db query.
>>>
>>> So, is there a reason QuerySet doesn't have a __contains__ method, or 
>>> would it be a good addition? My guess is that a lot of people use the "obj 
>>> in queryset" syntax, believing it does "the right thing".
>>>
>>> //Johan
>>>
>>> -- 
>>> 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/88c83b8d-658c-47cc-9162-fcfebebe9c4a%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/NZaMq9BALrs/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/CABD5YeE7_ORUfJcnt6f4aB4J0j-%3DyDK_BowEt_fefcaFMGdB1g%40mail.gmail.com
>>  
>> 
>> .
>>
>
>
> -- 
> Vänligen, Johan Schiff
> Radkompaniet AB
> 072-229 61 19
>
> -- 
> 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/CAD69rUBKOse%2Be2RedPT%2B-KWkcdC%3DiaG0zyt1Hakefp6gQ7vdLA%40mail.gmail.com
>  
> 

Re: Implement QuerySet.__contains__?

[Tim Graham]

And here's some past discussion:
https://code.djangoproject.com/ticket/24141 - contains() method for 
QuerySets (closed as needsinfo due to no mailing list discussion to find a 
consensus)
https://github.com/django/django/pull/3906 - Efficient 
QuerySet.__contains__ (closed as wontfix due to the behavior change)

On Tuesday, June 2, 2020 at 8:53:07 AM UTC-4, Tim Graham wrote:
>
> It may help to know that QuerySet.__contains__() was implemented until 
> Django 1.6 when chunked reads were removed from QuerySet iteration: 
>
>
> https://github.com/django/django/commit/70679243d1786e03557c28929f9762a119e3ac14
>
> On Tuesday, June 2, 2020 at 7:43:25 AM UTC-4, Aymeric Augustin wrote:
>>
>> On 2 Jun 2020, at 13:30, Florian Apolloner  wrote:
>>
>> On Tuesday, June 2, 2020 at 11:28:34 AM UTC+2, Adam Johnson wrote:
>>>
>>> If you already fetched the queryset, `if obj in queryset` will make a 
>>>> new database query
>>>
>>>
>>> I don't see why we couldn't implement __contains__ to do a walk through 
>>> _result_cache if it has been fetched?
>>>
>>
>> we are doing the same for len() IIRC. I have to say it sometimes makes it 
>> a little bit hard to debug, but if it is documented as such it should be 
>> okay.
>>
>>
>> These are good points.
>>
>> As far as I can tell, the current implementation of __len__ is to fetch 
>> the whole queryset:
>>
>> def __len__(self):
>> self._fetch_all()
>> return len(self._result_cache)
>>
>> I'm almost sure doing an automatic .count() was discussed in the past. I 
>> don't remember why we rejected it — perhaps because in most cases, when you 
>> need the length of a queryset, you will also iterate it?
>>
>> The suggestion for __contains__ is similar: doing an automatic .filter(pk=
>> obj.pk).exists(). We could do it only if the queryset isn't fetched yet, 
>> but I'm afraid this may be too magical. Is it reasonable to have `total = 
>> len(queryset); found = obj in queryset` make one SQL query while `found = 
>> obj in queryset; total = len(queryset)` makes two queries?
>>
>> Now I'm worried that we may be making inconsistent decisions between 
>> __len__ and __contains__... Let's make sure we're consistent across dunder 
>> methods.
>>
>> -- 
>> 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/5e16c857-d3c1-4d9d-b7cd-99fe77b7e13a%40googlegroups.com.

Re: Implement QuerySet.__contains__?

[Tim Graham]

It may help to know that QuerySet.__contains__() was implemented until 
Django 1.6 when chunked reads were removed from QuerySet iteration: 

https://github.com/django/django/commit/70679243d1786e03557c28929f9762a119e3ac14

On Tuesday, June 2, 2020 at 7:43:25 AM UTC-4, Aymeric Augustin wrote:
>
> On 2 Jun 2020, at 13:30, Florian Apolloner  > wrote:
>
> On Tuesday, June 2, 2020 at 11:28:34 AM UTC+2, Adam Johnson wrote:
>>
>> If you already fetched the queryset, `if obj in queryset` will make a new 
>>> database query
>>
>>
>> I don't see why we couldn't implement __contains__ to do a walk through 
>> _result_cache if it has been fetched?
>>
>
> we are doing the same for len() IIRC. I have to say it sometimes makes it 
> a little bit hard to debug, but if it is documented as such it should be 
> okay.
>
>
> These are good points.
>
> As far as I can tell, the current implementation of __len__ is to fetch 
> the whole queryset:
>
> def __len__(self):
> self._fetch_all()
> return len(self._result_cache)
>
> I'm almost sure doing an automatic .count() was discussed in the past. I 
> don't remember why we rejected it — perhaps because in most cases, when you 
> need the length of a queryset, you will also iterate it?
>
> The suggestion for __contains__ is similar: doing an automatic .filter(pk=
> obj.pk).exists(). We could do it only if the queryset isn't fetched yet, 
> but I'm afraid this may be too magical. Is it reasonable to have `total = 
> len(queryset); found = obj in queryset` make one SQL query while `found = 
> obj in queryset; total = len(queryset)` makes two queries?
>
> Now I'm worried that we may be making inconsistent decisions between 
> __len__ and __contains__... Let's make sure we're consistent across dunder 
> methods.
>
> -- 
> 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/55b4d7e0-ba30-48b2-8005-d27adacc7fd0%40googlegroups.com.

Re: Adding json lines (jsonl) serializer to django

[Tim Graham]

Hi Ali, as I noted on the PR, the ticket isn't in the review queue because 
"needs tests" is checked.

On Thursday, May 21, 2020 at 9:47:53 AM UTC-4, Ali Vakilzade wrote:
>
> Hi!
>
> A while back I opened a pull request on this topic and there is no updates 
> on the my request for a while. I know people might be busy and not having 
> time to review but I'm sending this mail hoping to bring the pull request 
> back up and not die on github. I think supporting "JSON lines" is a small 
> feature which can be very useful for many people.
>
> pull request: https://github.com/django/django/pull/12267
> ticket: https://code.djangoproject.com/ticket/30190
> previous discussion: 
> https://groups.google.com/forum/#!topic/django-developers/MMm1AGS2Ibg
>
> thanks
>

-- 
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/ad34bab0-5b83-45c4-a18a-2bfb9607be4f%40googlegroups.com.

Re: Disabling .delete() in querysets in Django

[Tim Graham]

Hi Uri,

I think you've mostly come across documented behaviors rather than 
"problems". You haven't provided enough details in the bug report to say 
for sure on that issue.

I don't think the things you've implemented are generally applicable to 
many Django projects such that they warrant the addition of new settings.

On Wednesday, May 20, 2020 at 8:57:08 AM UTC-4, Uri wrote:
>
> Django developers,
>
> I recently disabled .delete() in querysets in all managers in my project, 
> after encountering a bug in a bulk delete queryset in my tests [
> https://code.djangoproject.com/ticket/31600]. Actually it was quite 
> simple to disable .delete() in querysets, but I had to define my 
> own QuerySet class:
>
> class QuerySet(models.query.QuerySet):
> def delete(self):
> raise NotImplementedError("delete is not implemented.")
>
>
> I also disabled bulk_create() in managers for similar reasons. And I 
> thought, maybe you can introduce optional settings in which if it's set, 
> will disable delete() and bulk_create() in managers and querysets? I think 
> this may be useful, since the delete() and bulk_create() methods have 
> problems - they don't call the model's methods and in some cases (such as 
> in my case) related objects from other models don't get deleted (with 
> delete()) and models don't get validated (with bulk_create()).
>
> I also call each model's self.full_clean() method before saving, which 
> may also be a setting in Django. I don't want invalid objects to be saved 
> to the database.
>
> If you think this is a good idea and want me to implement it, I can try to 
> submit a PR.
>
> By the way, I checked and I found out that I can still delete objects from 
> our admin interface, so it probably doesn't use the delete() queryset.
>
> Thanks,
> Uri.
>
> אורי
> 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/943a7ea3-074c-42cb-a259-42714e32fc11%40googlegroups.com.

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

[Tim Graham]

I'm in favor of the change. It seems to me that most slugs I see these days 
have stop words in them and they read better because of that. I don't think 
JavaScript warnings would be helpful. A release note is sufficient. Admin 
users still get a preview of the slug and can edit it if needed.

On Friday, May 15, 2020 at 6:44:12 PM UTC-4, Scott Cranfill wrote:
>
> Does anyone else have an opinion on whether or not we should still be 
> removing these stopwords?
>
> Hopefully someone more involved in i18n can weigh in.
>>
>
> I'm not sure if there are any i18n concerns here. In fact, ceasing this 
> practice removes the impetus for the recurring issues being raised about 
> how this practice negatively affects the experience for users of other 
> languages, or doesn't remove words in their language, etc.
>
> Thanks for the suggested code, Adam. On the topic of deprecation, in 
> general: Andy I weren't really sure how to approach that for a 
> JavaScript-only change. We can't throw deprecation warnings in the Django 
> console like we could if we were talking about Python code, can we? I could 
> see adding some more aggressive messaging, maybe even in the Admin?
>

-- 
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/bd4e8c7d-4f7e-4c00-9e8b-49378eb261ee%40googlegroups.com.

Re: Loading lzma compressed fixtures

[Tim Graham]

Hi Paolo, Please don't ask for code reviews on this mailing list. It just 
adds noise. Patches are reviewed from "Patches needing review" at 
https://dashboard.djangoproject.com/. At this time there are ~30 patches in 
the queue. Requesting your feature to be moved to the front of the review 
queue the weekend before the feature freeze isn't appropriate.

On Saturday, May 9, 2020 at 6:22:13 AM UTC-4, Paolo Melchiorre wrote:
>
> Hi all, 
>
> Working at my latest merged PR [1] in Django I saw in the code the lack 
> of support for lzma compressed fixture for loaddata command so I opened 
> a ticket [2] and a related PR [3]. 
>
> I think is a small PR to accept before Django 3.1 feature freeze but it 
> can be a great improvement in loading big fixtures. 
>
> I would ask someone to review my PR [3]. 
>
> Thanks, 
> Paolo 
>
>
> [1] https://github.com/django/django/pull/12871 
> [2] https://code.djangoproject.com/ticket/31552 
> [3] https://github.com/django/django/pull/12879 
>
> -- 
> https://www.paulox.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/070f2da9-bf9c-4798-8cb5-64e3f91723f0%40googlegroups.com.

Re: Swappable sessions

[Tim Graham]

I don't see a strong argument for adding it. As far as I can tell, this 
would require adding 'request' to the signature of SessionStore.__init___() 
(so it could be stored as an attribute on SessionStore and thereby 
available in create_model_instance()). Backwards compatibility would be 
non-trivial and coupling the session store to the request seems unnecessary.

On Wednesday, April 15, 2020 at 5:38:18 PM UTC-4, Lorenzo Peña wrote:
>
> Yes, of course. I am already working things around in order to get what I 
> need.
>
> Now, the database backed SessionStore defines a method 
> "create_model_instance(self, data)" which is called from 
> "django.contrib.sessions.middleware.SessionMiddleware". Django docs invite 
> to redefine this method in order to populate the custom session with the 
> required data.
>
> My question is: would it be okay to formally ask that the request object, 
> which is already available there, be passed to that method when called, 
> like " create_model_instance(self, data, request=None)"?
>
> El miércoles, 15 de abril de 2020, 17:01:30 (UTC-4), Tim Graham escribió:
>>
>> Can't you copy whatever data you want from the request into the session 
>> data (request.session. = request.) in a view, 
>> middleware, or wherever? That seems like the proper separation of concerns.
>>
>> On Wednesday, April 15, 2020 at 11:50:13 AM UTC-4, Lorenzo Peña wrote:
>>>
>>> Now, in order to follow the path suggested in the Django documentation 
>>> for overriding database backed sessions, some of the data one might need to 
>>> store in the session model is coming from the request, and Django is not 
>>> passing the request when instantiating the session store.
>>>
>>> Do you think there is a point in requesting that the request object (if 
>>> available) is passed as an optional parameter when creating the session?
>>>
>>

-- 
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/6a00f99e-ce00-4003-b64e-5a2502d8ab86%40googlegroups.com.

Re: Swappable sessions

[Tim Graham]

Can't you copy whatever data you want from the request into the session 
data (request.session. = request.) in a view, 
middleware, or wherever? That seems like the proper separation of concerns.

On Wednesday, April 15, 2020 at 11:50:13 AM UTC-4, Lorenzo Peña wrote:
>
> Now, in order to follow the path suggested in the Django documentation for 
> overriding database backed sessions, some of the data one might need to 
> store in the session model is coming from the request, and Django is not 
> passing the request when instantiating the session store.
>
> Do you think there is a point in requesting that the request object (if 
> available) is passed as an optional parameter when creating the session?
>

-- 
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/d9eef373-28cf-4ccb-9801-90d7c38b3678%40googlegroups.com.

Re: Proposal to not implicitly create varchar/text-pattern opclass indexes on PostgreSQL

[Tim Graham]

I have some sympathy for this issue as I'm trying to make the 
createcachetable management command use SchemaEditor rather than some 
custom SQL construction logic*. The related problem I ran into is that the 
primary key column (a CharField) uses unique=True which means those 
undesired opclasses indexes are created. I couldn't find a way to prevent 
that index besides filtering it out of the list of SQL statements.

As for your proposal, how would you handle the upgrade path for existing 
projects? I imagine we could provide a script to run upon upgrade to remove 
all such existing indexes. No doubt some users won't run it. Would you keep 
around the code in Django's SchemaEditor like 
https://github.com/django/django/blob/53d229ff632c2a3e547f2820a94239f38ba4d4ac/django/db/backends/postgresql/schema.py#L178-L180
 
that assumes those indexes exist?

If Django stops creating those indexes, it could create a somewhat murky 
situation for some developers as they try to figure out the state of 
indexes in their database. It might depend on which version of Django was 
in use when certain migrations ran.

Some developers might be left debugging performance issues if those indexes 
are removed. It could be helpful to gives some numbers as to the possible 
performance impact on applications if these indexes are removed without a 
developer realizing it.

Third-party apps that need it could add an Index with opclasses but then 
they'd face the issue of duplicate opclasses indexes if their app is used 
on an older version of Django.

* https://github.com/django/django/pull/12590

On Sunday, April 12, 2020 at 10:30:50 AM UTC-4, Hannes Ljungberg wrote:
>
> Hi all, 
>
> I would like to continue the discussion started in this very old thread:
> https://groups.google.com/d/msg/django-developers/H2QFcQYsbo8/RmRb-8FVypwJ
>
> I’m sorry if I should've continued the discussion in that thread but it 
> felt a bit wrong to bring a 5 year old thread back to life :-)
>
> Anyway, as previously described in that thread the implicit creation of 
> the `*_pattern_ops` index when creating indexes on `CharField` and 
> `TextField` with `db_index=True` is not ideal. 
>
> In my experience `LIKE` expressions is not that common that it warrants to 
> always create an index to cover this. 
>
> For very large tables this can become a problem where insertion/update 
> performance is negatively affected and disc space usage is twice what 
> really is needed if no `LIKE` queries are used.
>
> And even if one would like to use `LIKE` expressions it’s not obvious that 
> the `*_pattern_ops` is the correct index. For leading wildcard patters as 
> `LIKE %foo` one has to use a GIN/GiST index with the `*_trgm_ops` opclass. 
> With the current implementation we would end up with 3 indexes when 2 would 
> be sufficient for this use case (the regular b-tree and the trigram).
>
> One could also argue that we’re not consistent with these implicit 
> indexes. The `iexact`/`icontains` lookups require an expression index on 
> `(UPPER(col))`  but that’s not created.
>
> One important detail is that this implicit index is _not_ created when 
> using the class based `Index` . In my opinion it’s not very clear that one 
> needs to handle the creation of a `*_pattern_ops` index manually when using 
> it.  
>
> This is the only documentation that I’ve been able to find about the 
> creation of these implicit indexes: 
> https://docs.djangoproject.com/en/dev/ref/databases/#indexes-for-varchar-and-text-columns
>
> My proposal is to remove the implicit index created by `db_index=True` and 
> add documentation that one should use `Index.opclasses` to utilise indexes 
> for `LIKE` queries on PostgresSQL. This would give a more consistent 
> behaviour and being more explicit about this would help people tune their 
> indexes.
>
> If there’s a consensus on this I would like to give this a shot. If 
> there’s not an agreement on removing the implicit index I think we should 
> at least make the documentation around this a bit more clear about the 
> gotchas of `Index` vs `db_index=True`.
>
> Here’s two tickets which have previously discussed this:
> https://code.djangoproject.com/ticket/24507
> https://code.djangoproject.com/ticket/24088
>
> Stay safe!
>
>

-- 
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/d95c53af-a2df-46a6-8786-c10861e58ced%40googlegroups.com.

Re: handle_uncaught_exception error logging

[Tim Graham]

The relevant commit might be 
https://github.com/django/django/commit/10b44e45256ddda4258ae032b8d4725a3e3284e6.
 
That change was made in Django 2.1. You didn't say what version of Django 
you're using.

You'll have to give more details about your case and what's behaving 
differently.

On Sunday, April 12, 2020 at 8:57:12 AM UTC-4, Gordon wrote:
>
> Why was the error log removed from handle_uncaught_exception?  I didn't 
> find mention about it but I've recently encountered a middleware causing a 
> 500 error and not getting a traceback log was unexpected.
>
>
> https://github.com/django/django/blob/stable/2.0.x/django/core/handlers/exception.py#L115
>
> Should it be added back or is it intentionally removed?
>

-- 
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/41b3957e-d39a-4078-b476-23e6c56815bf%40googlegroups.com.

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

[Tim Graham]

How would the strategy of having a setting generate new migrations work 
with third-party apps? Generally migrations can't easily be added to them 
by user projects and if more migrations are added to the third party app in 
a later version, there will be an inconsistent history.

On Thursday, April 9, 2020 at 3:06:51 PM UTC-4, Collin Anderson wrote:
>
> Having a DEFAULT_AUTOFIELD setting makes sense to me.
>
> On Monday, April 6, 2020 at 12:48:10 PM UTC-4, Adam Johnson wrote:
>>
>> Jure - yes switching the setting should generate migrations for all 
>> affected models. The migration guide would cover changing models' primary 
>> key fields to PositiveBigAutoFields one at a time, perhaps with a mixin as 
>> you've suggested. Maybe Django should provide such a mixin to ease the 
>> migration.
>>
>> primary keys might be GUID
>>>
>>
>> The proposal is not to move to GUID's/UUID's, as you've used in your 
>> example. It's to move to bigger integers.
>>
>> UUID's are a bad idea for database performance, as they distribute 
>> randomly across the table, preventing any cache wins. On autoincrement 
>> tables, the tail end of each table is normally most frequently read and 
>> written and thus cached in memory. I don't think Django should ever suggest 
>> UUID's as primary keys.
>>
>> On Mon, 6 Apr 2020 at 16:46, Jure Erznožnik  wrote:
>>
>>> Sorry if I understand stuff incorrectly, but:
>>>
>>> I agree with Adam where he discusses migration issues, but I also don't 
>>> see how "DEFAULT_AUTOFIELD" setting could leave tables out of the 
>>> migration(s). 
>>>
>>> My understanding is that it would cause immediate re-provisioning of all 
>>> the pk fields, including in the core django modules and third-party 
>>> modules. Some of them might have programmed their logic such as to include 
>>> some integer math around the primary keys (and now all auto primary keys 
>>> might be GUID).
>>>
>>> If I understand the above correctly, the setting would have to be 
>>> per-module. Could it simply be done like this:
>>>
>>> class PKMixin(object):id = models.UUIDField(primary_key=True, )
>>>
>>> Naturally, then all desired models would (also) derive from this mixin. 
>>> A bit of a chore, but it would not require reconfiguration of all 
>>> migrations, just the ones the programmer would specify - and would only be 
>>> limited to their own module.
>>>
>>> OTOH, JUST FOR the unsigned vs signed integer PK, it should be 
>>> relatively easy to modify makemigrations code detect existing migrations 
>>> for the model, detect that the only difference is IntegerField vs 
>>> PositiveIntegerField and in this case skip generating the migration (for 
>>> migrating the field to an unsigned one). There could also be a flag to the 
>>> management command specifying to force generating said migrations.
>>>
>>> Of course, ignore if this is gibberish.
>>>
>>> LP,
>>> Jure
>>>
>>>
>>> On 06/04/2020 17:11, Adam Johnson wrote:
>>>
>>> I'm in favour of the move. The setting strategy seems appropriate.
>>>
>>> Simon's comment on the PR that this affects a small % of projects is 
>>> true. But if your project does reach that scale, you're probably one of the 
>>> bigger Django organizations in the world - hopefully key advocates for the 
>>> framework. It's also possible to hit this on smaller projects with tables 
>>> that import a lot of new rows, such as rolling time series data imports.
>>>
>>> Also, this problem is *highly* asymmetric. Unnecessarily using big PK 
>>> fields wastes a little storage space - unlikely to be noticed. Migrating to 
>>> big PK fields can be a massive task (and can feel like "Django let you down 
>>> here with bad defaults") ("Ruby on Rails does it right!").
>>>
>>> It will need a careful migration guide though. Pre-existing projects may 
>>> need to migrate one table at a time to reduce downtime/load, or keep the 
>>> setting to the smaller auto field forever. I'm happy to help with this.
>>>
>>> One thing we *could* add is a deploy time system check (or a management 
>>> command, or something), to check what % of your tables' autofields' PK 
>>> values have been "used up." This allows larger projects to prioritize their 
>>> migrations.
>>>
>>> On Mon, 6 Apr 2020 at 15:37, Caio Ariede  wrote:
>>>
 Hi folks,

 I’ve been working on ticket #56 "Primary key columns should be 
 UNSIGNED"  (really old) for a while now. It’s cumbersome and hard to 
 fix for some reasons, including backwards compatibility, nothing that a 
 single PR can solve but I’ll try to summarize where things are at this 
 moment. Hopefully we can get to a consensus so I can continue.

 The problem: Django has been storing primary keys as signed integers 
 since the beginning and this is considered a waste of resources. Very few 
 people seem to use negative values as primary keys, apparently.

 The desired solution: We want to change that in a backwards-compatible 
 way to not cause 

Re: Does "Someday/Maybe" triage stage imply a low change of pull request getting merged?

[Tim Graham]

Generally "Someday/Maybe" tickets aren't ready for coding. Something else 
needs to happen first, perhaps a discussion on this mailing list to come to 
a consensus on how to proceed, or in the cast of that ticket (perhaps), the 
spec to be approved.

On Wednesday, April 8, 2020 at 2:56:44 PM UTC-4, Andy Robles wrote:
>
> Hi all, 
>
> Newcomer here.
>
> Looking to contribute for the first time on a ticket. Currently looking to 
> take on #31425 Support for Clear-Site-Data header because it seems 
> interesting to me. 
>
> However, I see it is marked as "Someday/Maybe" which leads me to think 
> that the chances of a completed pull request getting merged are slim. Is 
> this assumption correct and I should therefore seek a different ticket with 
> a different triage stage?
>
> Thanks in advance.
>
> -Andy
>

-- 
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/f2bdc6f1-33a7-451d-9310-65d1ba16ff27%40googlegroups.com.

Re: verbose_name used inconsistently in contrib.admin

[Tim Graham]

Hi, This behavior looks correct. Field names are used when displaying a 
model's fields, so a model's verbose_name doesn't have any effect there. 
Consider a model that has a two foreign keys to the same model. Displaying 
the model name in that case wouldn't allow distinguishing between the 
fields.

On Tuesday, April 7, 2020 at 2:32:58 PM UTC-4, Fran Hrženjak wrote:
>
> Hi all!
>
> If I set verbose_name on a model, it is reflected on this model's admin 
> list view and change view, but not in other areas of the admin, e.g. a FK 
> field on another model.
>
> Please see the attached screenshot.
>
> Is this ticket material?
>
>
>

-- 
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/056edc4e-06ab-41a0-b5c0-74f282a88275%40googlegroups.com.

Re: Improve migration conflict detection

[Tim Graham]

Have you considered what would happen if a migration has a RunPython or 
RunSQL? They may require a certain model state.

On Tuesday, February 18, 2020 at 12:08:03 PM UTC-5, caio wrote:
>
> I’m working on this as a standalone PoC app for now, I may be able to 
> share a repository with the code soon in order to get some feedback
>
> Here’s in simple words where I’m at:
>
> * I’ve replaced the restriction of only-one-leaf-node-per-app from the 
> Migration Loader [1] to only-one-leaf-node-per-app-per-model. It means that 
> with this, you can have more than one person changing different models in 
> the same app, without introducing conflicts. Migrations referring to the 
> same app and model would still cause a conflict
>
> * I’m now trying to get the migration graph’s forwards/backwards plan to 
> handle cases where there are more than one leaf node in the graph.
>
> I may be doing the wrong assumption here, but it seems to me that 
> migrations changing different models shouldn’t introduce a real conflict? 
> If I have the following migration graph:
>
> [ 0001_initial ] => [ 0002_auto ] => [ 0003_abc ] => [ 0003_def ] => [ 
> 0004_auto ]
>
> Where 0003_abc and 0003_def don’t have any model changes in common: no FK 
> references, nothing related at all
>
> If this assumption is correct, I could have the two migrations in ANY 
> order in the graph, that it would still give me the same result, for 
> example:
>
> [ 0001_initial ] => [ 0002_auto ] => [ 0003_def ] => [ 0003_abc ] => [ 
> 0004_auto ]
>
>
> Please let me know if I’m missing something, ideas and thoughts are really 
> welcome :)
>
>
> [1] 
> https://github.com/django/django/blob/2a038521c4eabdc5f6d5026d3dd6d22868e329cd/django/db/migrations/loader.py#L301-L313
>
> --
> Caio Ariede
> caio@gmail.com 
>
>
>
>
> On Feb 13, 2020, at 11:49, Dave Vernon  > wrote:
>
> If I had to guess, it would be that with more than one leaf node, you 
> would end up a substantial challenge resolving dependancies which would 
> create an Order(N) problem (i.e. there's a chance of excessive time to 
> complete the resolution).
>
> I certainly worked on some migration logic that took a similar approach to 
> this.
>
>
> On Thursday, February 13, 2020 at 2:10:40 PM UTC, Adam Johnson wrote:
>>
>> I don’t think many people can answer this off the top of their heads. I 
>> certainly can’t and I have contributed a couple things to migrations.
>>
>> It’s probably quite necessary there’s only one leaf node but I can’t say 
>> for sure.
>>
>> On Thu, 13 Feb 2020 at 13:58, caio  wrote:
>>
>>> Cool. If I'm understanding this correctly, it auto-resolves during 
>>> *makemigrations*?
>>>
>>> I'm looking for something that could handle conflicts during the 
>>> *migrate* command, but I'm not sure if that's really possible. I guess 
>>> it depends on how intrinsic the single-leaf-node restriction is to the 
>>> whole migration system
>>>
>>> Thanks!
>>>
>>> Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye 
>>> escreveu:

 Definitely a plus one on auto resolving migrations a test package still 
 in planning aims to solve this 
 https://github.com/jackton1/django-migration-resolver-hook

 On Feb 11, 2020, at 1:42 PM, Caio Ariede  wrote:

 Hey folks,

 I was looking at the code used to detect conflicts in migrations [1]. 
 It seems to use a very safe approach, by avoiding with multiple node leafs 
 in the migration graph.

 While this is safe, I’ve been having some problems when it comes to 
 scalability when having multiple migrations created in a short period of 
 time (for the same app).

 Questions:

 1. Are there any obvious impediments on improving the conflicts 
 detection?
 2. Does anyone have ideas on how to improve the conflict detection? 
 (eg. going down from app-level to model-level detection)


 Thanks!


 [1] 
 https://github.com/django/django/blob/e3f6e18513224c8ad081e5a19da641f49b0b43da/django/db/migrations/loader.py#L301-L313
  
 

 --
 Caio Ariede
 caio@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-d...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/FE717E60-7B66-4050-B233-20C47FBF6038%40gmail.com
  
 
 .


>>> -- 
>>> You 

Re: Relax system check on fields intermediary tables for db_table collision when database routers are installed

[Tim Graham]

The change for that ticket is already released. Please open a new ticket.

On Thursday, February 13, 2020 at 9:00:35 AM UTC-5, Anonymous Rabbit wrote:
>
> Before I move forward I just to want clarify, my changes are for the same 
> check specified in ticket #29092. Should I still open a new ticket in lieu 
> of re-opening #29092?
>
> On Thu, 13 Feb 2020 at 13:23, Adam Johnson > 
> wrote:
>
>> Please create a new ticket with a reference to the old one, and then a PR 
>> against that, since your change is for a different check.
>>
>> On Thu, 13 Feb 2020 at 12:15, Anonymous Rabbit > > wrote:
>>
>>> Hello there,
>>>
>>> This regards multi-database Django.
>>>
>>> On https://github.com/django/django/pull/11630, a change was made to 
>>> allow for multiple models with the same db_name, when a DATABASE_ROUTER is 
>>> present. 
>>> A ticket was open here for that issue: 
>>> https://groups.google.com/forum/#!searchin/django-updates/29092%7Csort:date/django-updates/K1VuUaa9BUc/IDmjZoiRCQAJ
>>>  . 
>>> Eventually it gets marked with wontfix, but with a notice: "Feel free to 
>>> reopen and offer a patch for evaluation if you think the implementation is 
>>> straightforward."
>>>
>>> I implemented the same changes of PR #11630, but with fields.E340 in 
>>> mind (fields.E340: The field’s intermediary table  clashes with 
>>> the table name of /..).
>>>
>>> I would like to open a PR for it, but I'm not sure of the process I have 
>>> to follow. Should the ticket be re-opened? Can I open the PR pointing at 
>>> the wontfix ticket instead? Should I open a new ticket for it?
>>>
>>> Best regards,
>>> Xavier
>>>
>>> -- 
>>> 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-d...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/7819a6e1-3f47-41c8-a6c0-d35de3f37578%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>
>>
>> -- 
>> Adam
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/Ypks34xj1AY/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> django-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAMyDDM3-F2%3DBC4bGqiMpf2cG5F47Hn217DgV3YaVGc%2BK9_VWAg%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/2e38cc16-ac9c-461b-80f8-8fc3e21d6a53%40googlegroups.com.

Re: Announcing CockroachDB support for Django ORM

[Tim Graham]

This is the mailing list for the development of Django itself. Please use 
django-users for messages like this.

On Monday, January 27, 2020 at 4:27:01 PM UTC-5, Charlotte Dillon wrote:
>
> https://pypi.org/project/django-cockroachdb/
>

-- 
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/79d26909-828f-4ea1-a10e-7dc000b14678%40googlegroups.com.

Re: Getting error while running tests for postgis

[Tim Graham]

Actually, this is somewhat on topic as it involves running the Django test 
suite.

To solve the failure, add this to your test settings:

PASSWORD_HASHERS = [
'django.contrib.auth.hashers.MD5PasswordHasher',
]

It seems like a bug that that test assumes MD5PasswordHasher.

As for the skipped tests, the skips might be expected. Run runtests.py with 
"-v 2" to see the reason.

On Thursday, January 23, 2020 at 2:08:15 PM UTC-5, Pratik kumar wrote:
>
> I was running the test With for GeoDjnago using the following commands
> ./runtests.py --settings=postgis
> with the following settings file
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.contrib.gis.db.backends.postgis',
> 'NAME':'defaultd',
> 'USER': 'user',
> 'PASSWORD':'password',
> 'HOST': '127.0.0.1',
> 'PORT': '5432',
> },
> 'other': {
> 'ENGINE': 'django.contrib.gis.db.backends.postgis',
> 'NAME':'otherd',
> 'USER': 'user',
> 'PASSWORD':'password',
> 'HOST': '127.0.0.1',
> 'PORT': '5432',
> }
> }
> SECRET_KEY = 'django_tests_secret_key'
> Got the following error, can't seem to understand the reason behind it. 
> how can i remove it
>
> [image: Screenshot from 2020-01-23 23-54-14.png]
>
>
> Also when i run test specifically for geoDjango there are 13 tests which 
> are skipped how to avoid skipping those tests.
>
> Any help will be appreciated
>

-- 
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/0b0a766d-aed9-4f2c-bb64-43112b2de63e%40googlegroups.com.

Re: [Feature Request] Allow a Field/DeferredAttribute object everywhere a field name as a string is currently expected

[Tim Graham]

If I understand correctly, currently this works:

Question.objects.order_by(Question.pub_date.field_name)

but your proposal is to avoid the need for ".field_name". I don't think I'd 
use that syntax as its more verbose and less readable (to me, anyway). 
Having more than one way to write things (string or field reference) isn't 
great for consistency. Strings would still be needed for referencing things 
like annotations.

On Monday, January 13, 2020 at 11:09:39 AM UTC-5, Matt del Valle wrote:
>
> Hiya,
>
> The title says it all. It would be dead useful if you could always use 
> fields rather than the string name of a field, for example in a QuerySet 
> order_by(), or in the BaseModelAdmin.ordering class attribute (and probably 
> many more locations).
>
> This has the huge advantage of avoiding string literals in your code, 
> which allows static code analysis (MyPy, Pycharm's inspections, etc.) tools 
> to warn you if you misspell the field name, or if you later rename the 
> field. Otherwise such errors end up being hidden until that line of code 
> happens to be actually run, which has the potential to slip through testing 
> and end up in production. It also allows refactor/rename tools to 
> automatically assist with renames in every such location across your Django 
> project, saving a lot of time and effort.
>
> It also seems really simple to implement. All you'd need would be a helper 
> function that did a few if-elif checks for instances of Field or 
> DeferredAttribute, and returned Field.name and 
> DeferredAttribute.field.name respectively. It would return strings 
> unchanged to preserve the current functionality.
>
> The tricky part would be then tracking down everywhere within Django where 
> such field name strings are expected and wrapping the input in this 
> function.
>
> Is there any chance something like this could be considered as a new 
> feature?
>
> Thanks in advance,
> Matt
>

-- 
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/5b3dba4c-2bfa-41dd-8190-bcab48616467%40googlegroups.com.

Re: Worth raising a warning when `order_by('?')` is used with specific backends?

[Tim Graham]

I think issuing a warning would be rude to developers who want to use that 
feature and are aware of the limitation... they would have to do extra work 
to silence the warning.

On Friday, January 10, 2020 at 10:14:23 AM UTC-5, Santiago Basulto wrote:
>
> Sadly I have to admit that I'm not involved with day to day development of 
> our app anymore (I miss it tremendously). Yesterday I felt nostalgic and 
> reviewed a few already-merged PRs, just "for fun" we could say. Great was 
> my surprise when I noticed that one of those PRs was merged with an 
> `order_by('?')`. We're (and we've always been) using Postgres, and I knew 
> already that `ORDER BY RANDOM()` is very slow. I just submitted a comment 
> and it's already been fixed, so it wasn't a big deal. But this got me 
> thinking:
>
> TLDR;
> Some less-experienced developers might not know the issues with 
> `order_by('?')` (at least with Postgres, the only engine I'm familiar 
> enough) and it's worth raising a warning. I don't know what's the state of 
> other engines, it's maybe even worth raising the issue for ANY engine.
>
> It could help newcomers catch these issues early. The docs clearly state 
> it 
> ,
>  
> but not everybody reads the docs with such level of detail:
>
> Note: order_by('?') queries may be expensive and slow, depending on the 
>> database backend you’re using
>
>
> PS: Sorry for the personal touch of this message, but I think it's worth 
> the explanation.
>

-- 
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/d11f0f8c-a73f-4e95-9b69-25d3195effb8%40googlegroups.com.

Re: Best Profanity filters for using in Python Django project

[Tim Graham]

Hi, I see you also posted to django-users. Please don't cross post to 
django-developers as this mailing list is about developing Django, not 
discussing usage questions.

On Thursday, December 26, 2019 at 12:47:54 PM UTC-5, Unprofessional coder 
wrote:
>
> I have a requirement where I need to use the profanity check for the list 
> of forms.If the profanity is detected then it should stop further actions. 
>
>
> Currently I am using "profanity_check" package for profanity detection, 
> however getting the below warning from python in cmd.
>
> FutureWarning: sklearn.externals.joblib is deprecated in 0.21 and will be 
> removed in 0.23. Please import this functionality directly from joblib, 
> which can be installed with: pip install joblib.If this warning is raised 
> when loading pickled models, you may need to re-serialize those models with 
> scikit-learn 0.21+
>
>
>
> Is the "profanity_check" package suggested, what are alternative solutions?
>
>
> Thank you.
>

-- 
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/c9f7d088-a600-44ca-ab77-e60543812fd9%40googlegroups.com.

Re: Allow overriding smtplib local_hostname

[Tim Graham]

Hi, there's already a ticket: https://code.djangoproject.com/ticket/6989

On Friday, December 20, 2019 at 7:33:35 AM UTC-5, David Nolan wrote:
>
> Hey all.
>
> In cloud environments, when using 
> django.core.mail.backends.smtp.EmailBackend, socket.getfqdn() is called 
> to resolve the 'reported hostname' for smtplib. This often resolves to an 
> internal DNS name, not the intended name.
>
> It would be convenient to provide a kwarg to allow overriding this 
> setting, which is currently hard-coded in the open() function.
> See 
> https://github.com/django/django/blob/master/django/core/mail/backends/smtp.py#L53
>
> I’m happy to create a ticket for this but the contribution guidelines 
> advise emailing the list first.
>

-- 
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/b7246683-5f94-4e83-9310-d7ed698fbb82%40googlegroups.com.

Re: Removing old branches from the Django Git repository.

[Tim Graham]

Same proposal from 
2016: https://groups.google.com/d/topic/django-developers/sf2adeIAkQA/discussion

On Thursday, October 10, 2019 at 4:09:24 PM UTC-4, Tom Forbes wrote:
>
> I second this, there are a few other branches in that list (successful or 
> not) that have historic value to Django. Is there a pressing need to delete 
> them, other than spring cleaning?
>
> I guess maybe it’s sentimental value, and nobody would ever check them 
> out, but still...
>
> Tom
>
> On 10 Oct 2019, at 20:15, Adam Johnson > 
> wrote:
>
> 
> Can we leave magic-removal as a tag since it’s such a pivotal point in 
> djangos history? xD
>
> On Thu, 10 Oct 2019 at 19:09, Mariusz Felisiak  > wrote:
>
>> Hi y'all,
>>
>> We're going to remove some old branches from the Django Git 
>> repository on 1st November 2019:
>>
>>- *9* old branches related with Google SOC projects:
>>- soc2009/admin-ui
>>   - soc2009/http-wsgi-improvements
>>   - soc2009/i18n-improvements
>>   - soc2009/model-validation
>>   - soc2009/multidb
>>   - soc2009/test-improvements
>>   - soc2010/app-loading
>>   - soc2010/query-refactor
>>   - soc2010/test-refactor
>>- *17* *attic* branches:
>>   - attic/boulder-oracle-sprint
>>   - attic/full-history
>>   - attic/generic-auth
>>   - attic/gis
>>   - attic/i18n
>>   - attic/magic-removal
>>   - attic/multi-auth
>>   - attic/multiple-db-support
>>   - attic/new-admin
>>   - attic/newforms-admin
>>   - attic/per-object-permissions
>>   - attic/queryset-refactor
>>   - attic/schema-evolution
>>   - attic/schema-evolution-ng
>>   - attic/search-api
>>   - attic/sqlalchemy
>>   - attic/unicode
>>
>> 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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/9837cb41-66bc-40f2-8296-75f0ad173ee3%40googlegroups.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-d...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2kqTztbjzBg%2BOtTCO1M-5TxpaguH60BNv3m5TUe2T-dw%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/c044ea54-e537-4141-ad1c-a3b034149f5d%40googlegroups.com.

Re: Make Development More Accessible

[Tim Graham]

Although I'm not engaged too much with Django development now, a big 
drawback of moving to GitHub issues for me would be that I could no longer 
do a Google search like "something something site:code.djangoproject.com". 
I could pretty much always find the ticket I was looking for that way. 
Maybe GitHub issue search would be just as good but I find Google results 
(with a snippet from the page) more useful.

Another migration consideration is that Trac tickets are formatted using a 
different syntax than GitHub issues.

A migration feels like weeks of work and it doesn't strike me as a "heck 
yea!" improvement. There would probably be benefits and drawbacks. As 
Carlton said, I think it's time that could be more usefully allocated.

I wonder how putting issues on GitHub would increase engagement? Is it that 
Trac isn't discoverable from GitHub? What if GitHub let us redirect 
https://github.com/django/django/issues (with the "Issues" tab) to 
code.djangoproject.com?

On Thursday, August 8, 2019 at 4:48:14 AM UTC-4, Carlton Gibson wrote:
>
> Just on this point: 
>
> > I agree with Andrew Godwins statement on Django loosing many 
> contributors over the years and being in largely maintenance mode. 
>
> First, I'm not sure Andrew actually said this. Rather I think he reported 
> is a point raised. However...
>
> I hear this kind of thing said. It ties-in with the "Django is boring" 
> trope, when that's not meant as a compliment. 
>
> I think it couldn't be further from the truth. 
>
> Yes, these ain't the wild west days of yore. (Granted)
>
> But Django has successfully transitioned (with large thanks to the effort 
> Tim Graham put in as Fellow over that time) from young to mature and it 
> still growing. 
>
> Even if you take out your favourite headline feature — don't say it :) — 
> v3.0 is going to be an awesome release. 2.2 was too. And 2.1. And it's 
> continuing forward. 
>
> I wish we'd drop negative self-talk. It lowers morale and isn't even 
> correct. Django is in great shape, and only getting stronger. 
>
> Could we do with more contributors? Yes. So let's do what we can to make 
> that better. 
>
> I think of the effort to move from Trac. Maybe it's worth it... But I 
> think of the same effort spent improving djangoproject.com, and the How 
> to contribute guides (I think Tobias said the Contributing docs are 
> X-thousands of words—all great but not necessarily that approachable), and 
> so on, and I wonder if it's the best ROI? (That's a genuinely open 
> question: DRF uses GitHub issues I don't see it leading to any more 
> engagement there...) 
>
> Go Django Go! 
>
>
>
>

-- 
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/e2f79302-0afe-46bf-97f5-34b48ffc9fd9%40googlegroups.com.

Re: Ideas for a new DEP on long-term Django API compatibility

[Tim Graham]

Pascal, you can read about the reason for the action actions change on the 
ticket https://code.djangoproject.com/ticket/29917 ...and on this mailing 
list... 
https://groups.google.com/d/topic/django-developers/-OWoYL_zryM/discussion. 
I hesitate to link to things like that in the release notes because the 
discussions can be long and somewhat difficult to follow. Rather, as 
appropriate, I tried to include a short summary of the rationale for 
backwards incompatible changes in the release notes.

In my years working on Django, I found it reasonable to occasionally make 
backwards incompatible changes if there's a consensus that a deprecation 
isn't feasible or worthwhile. Sometimes practicality beats purity, in my 
experience.

Luke's experience and views parallel mine. I think the current deprecation 
cycle works well.

On Tuesday, August 6, 2019 at 4:12:23 AM UTC-4, Pkl wrote:
>
> Hello Luke,
>
> thanks for your comments, mine are below
>
> On Thursday, August 1, 2019 at 10:34:22 AM UTC+2, Luke Plant wrote:
>>
>> Hi Pascal,
>>
>> I know this is a very late reply, but there have been some things going 
>> round my head that I thought I should get down.
>>
>> *First,* some positive changes I think we can make from your suggestions:
>>
>> 1. I think in our release notes, for breaking changes that might need 
>> some justification, we should link to the tickets and/or django-devs 
>> discussions behind them. Adding full reasoning in the notes themselves 
>> would likely bloat them far too much, but a link could be helpful for 
>> anything which is not obviously necessary.
>>
>
> Yes documenting the rationale behind breaking changes, via a ticket link 
> or another medium, would be indeed a nice improvement.
>  
>
>> 2. We should change the wording in our API stability docs 
>> , which 
>> does indeed initially sound like a promise never to break working code that 
>> follows docs:
>>
>> Django promises API stability and forwards-compatibility since version 
>> 1.0.
>>
>> We do have this line later on:
>>
>> If, for some reason, an API declared stable must be removed or replaced, 
>> it will be declared deprecated but will remain in the API for at least two 
>> feature releases. Warnings will be issued when the deprecated method is 
>> called.
>>
>> But we do make changes at a rate faster than that document would make you 
>> think.
>>
>> I suggest that as a contrast to the existing text on that page, we also 
>> point out that we are continually improving Django, and have a 
>> "(eventually) one way to do it" policy regarding how we plan APIs, which 
>> means we will remove old things, while always providing better 
>> alternatives. I'm happy to write a patch for this.
>>
>
> As you imagine, I'd rather have had a change in actual django policy, 
> rather than a doc update to reflect the current status; but it'd be better 
> than nothing. However, the second sentence "*If, for some reason, an API 
> declared stable must be removed or replaced, it will be declared deprecated 
> but will remain in the API for at least two feature releases*" is itself 
> still misleading, since at least one recent major breakage violates it 
> 
>  
> ; *A pronouncement of the core dev team would be needed here**: is this 
> behaviour change a procedure error? Or is it really the new policy, to 
> allow changes which create immediate silent errors, and prevent third-party 
> compatibility shims from getting implemented?*
>
> Having "only one obvious way to day it" is a useful and common commitment 
> in Python, but please note the "obvious". You won't have "one way to do 
> it", ever. If people want to use sys.stdout.write(), or do a libc-cffi call 
> to output text to console, instead of just calling print(), they will do 
> so. And compatibility shims don't change anything on this matter: the 
> "obvious", "standard" way of doing is just the one mentioned in official 
> docs and which doesn't trigger DeprecationWarnings.
>
>
>  
>
>> *Second,* there were things I wanted to say that might be useful to you 
>> (Pascal) in understanding why you are not likely to get very far with your 
>> current approach.
>>
>> Your exaggerated tone is not likely to help you. You talk about Django's 
>> compatibility breakages as "*ruining the day of thousands of anonymous 
>> plugin/website maintainers all over the world*". When we make these kind 
>> of changes, we always do it with very clear and detailed upgrade notes, and 
>> almost always with several releases emitting deprecation warnings, as per 
>> our policy. And no-one is forced to upgrade immediately. Those who value 
>> stability above other things can use LTS, which gives them a *3 year 
>> release cadence,* not 8 months, which is far from excessively fast 
>> compared to other projects.
>>
>
>
> Imho