Re: future of QuerySet.extra()?

[Adam Johnson]

I've seen *extra()* misused in cases where developers came from a 
background of writing raw SQL and then used it rather than figuring out the 
(often relatively simple) ORM way of doing it. This is then a big 
maintenance burden, and the harsher warning against its use is a good idea.

Also thanks for documenting *RawSQL*, didn't realize it was usable until 
now so I've been able to get rid of some *extra()* usage in django-mysql.

On Wednesday, August 5, 2015 at 1:09:30 AM UTC+1, Josh Smeaton wrote:
>
> You're right about that. You can aggregate over custom expressions. For 
> aggregating over enums you should be able to use case expressions
>
> On Wed, 5 Aug 2015 at 05:05 Anssi Kääriäinen  > wrote:
>
>> On Tuesday, August 4, 2015, Shai Berger > 
>> wrote:
>>>
>>> The classic database aggregation examples involve aggregation over time: 
>>> Sum
>>> of sales per quarter (which is, itself, a function over date); average
>>> temparature per month; etc. All these require group-by clauses which name
>>> (expressions over) columns which are not FKs.
>>>
>>>
>> The following should work:
>>
>>
>>  
>> qs.annotate(quarter=Quarter('sold_date')).values('quarter').annotate(sum=Sum('amount'))
>>
>> I recall some changes to how the group by expression is generated for 
>> expressions. If I recall correctly the group by should have the expression 
>> itself now, not the base columns of the expression.
>>
>> There are many similar examples involving "enum columns" -- columns with a
>>> limited set of choices, where the choices are not instances of another 
>>> model.
>>
>>
>> I'm not sure of this one.
>>
>>  - Anssi
>>
>> -- 
>> 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/FojuU0syO8Y/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CALMtK1FqTkdmnXNYvjZ8U_QF9%2BWzrMCb1DDFQU5WB4SiKPX06g%40mail.gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/15f6552c-992f-4073-9802-0613ca498777%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Document/make public prefetch_related_objects

[Adam Johnson]

*prefetch_related* is great, but it would be nice to be able to reuse its 
capabilities with lists of model instances already retrieved by other code 
(or from cache, or newly constructed, etc.). It seems this is possible by 
using *django.db.models.query.prefetch_related_objects* which is the 
function implementing all the prefetch capability - I've just seen it used 
on my project fine. Could *prefetch_related_objects* be documented as a 
part of Django's public API, or are there arguments against 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c7634422-6d72-4f83-ada3-d2a0cce099e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Adam Johnson]

Marcin - you can "tidy up" some monkey patches, or at least make them 
robust to the code you're replacing changing, by 
using https://github.com/adamchainz/patchy .

I'm -1 - we've recently been implementing project system checks for our 
team and they are super useful. We even have one that checks if 
requirements.txt has been updated since the virtual environment was 
created. It would be bothersome if there was a way for developers to 
disable *all* checks for themselves. Also whilst many 3rd-party apps are 
adding checks recently, you don't want to miss out on the help they provide.

On Wednesday, August 12, 2015 at 6:35:34 PM UTC+1, Shai Berger wrote:
>
> Hi all, 
>
> On Tuesday 11 August 2015 19:05:26 Carl Meyer wrote: 
> > On 08/11/2015 10:44 AM, Marcin Nowak wrote: 
> > > I need to list ALL errors and warnings, which is: 
> > >   * unhandy and it would require maintain a big list (especially after 
> > > upgrading Django to newer version) 
> > 
> > That's a good reason not to include this "feature." How can you say now 
> > that a check included in a future Django version won't be relevant to 
> > you or catch a bug in your code, when you don't even know yet what that 
> > check is? 
> > 
>
> Further -- the cheks framework allows your apps or 3rd-party apps to add 
> checks of their own. So, the above argument also multiplies to all future 
> versions of all apps you use. 
>
> > 
> > All that said, [...] I think users who don't understand how 
> > SILENCED_SYSTEM_CHECKS works may be tempted to use it to "just make the 
> > errors go away", but all in all I'm still only -0.5. 
> > 
>
> FWIW, I'm -1. 
>
> I could be supportive of a --without-system-checks flag, which I can see 
> useful 
> during development ("I know there's a problem here, I want to solve 
> something 
> else first"). This would imply that a user needs to decide, every run 
> anew, 
> that they don't want the checks. I'm aware that a user like Marcin could 
> just 
> use an alias, or change their manage.py, to have the flag included 
> automatically; I'd take a "consenting adults" approach towards that sort 
> of 
> abuse. 
>
> 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fa7b4deb-b373-4363-8264-9288ba15085a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Document/make public prefetch_related_objects

[Adam Johnson]

Here we go! https://code.djangoproject.com/ticket/25279

On 14 August 2015 at 14:19, Marc Tamlyn  wrote:

> Nothing on `query` is public at the moment - I can see the merit in adding
> a public API to do this kind of work though. Can you open a ticket?
> https://code.djangoproject.com/newticket
>
> On 14 August 2015 at 13:26, Adam Johnson  wrote:
>
>> *prefetch_related* is great, but it would be nice to be able to reuse
>> its capabilities with lists of model instances already retrieved by other
>> code (or from cache, or newly constructed, etc.). It seems this is possible
>> by using *django.db.models.query.prefetch_related_objects* which is the
>> function implementing all the prefetch capability - I've just seen it used
>> on my project fine. Could *prefetch_related_objects* be documented as a
>> part of Django's public API, or are there arguments against 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 post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/c7634422-6d72-4f83-ada3-d2a0cce099e9%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/c7634422-6d72-4f83-ada3-d2a0cce099e9%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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/xjxKnhEDl7s/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1EZtMFd7%3D4LTwS-cEbrnC0Peooqbx61NZcHxidX5OZQOw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMwjO1EZtMFd7%3D4LTwS-cEbrnC0Peooqbx61NZcHxidX5OZQOw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1KEEoDHKe4C28D2N2z8bJOWE%3DLxjNbrLdG6KrJk3Xz7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

[Adam Johnson]

Actually I spoke too soon, I excitedly misunderstood what *RawSQL* does/doesn't 
do. Unfortunately it requires access to a column, which is not what I need. 
I'm inserting WHERE conditions like */*specialcomment*/1* - the special 
comment is translated into query rewriting, leaving *1* in the *WHERE* 
condition 
as a no-op. Unfortunately I can't see a way of injecting the raw SQL into 
the *QuerySet* using *filter* without referring to a column (required to 
make the ORM extension work without affecting queries too badly) - so 
*extra* remains the only solution here, unless I'm missing something... any 
suggestions welcome 
( https://github.com/adamchainz/django-mysql/pull/144/files ).

On Thursday, August 6, 2015 at 10:06:38 PM UTC+1, Adam Johnson wrote:
>
> I've seen *extra()* misused in cases where developers came from a 
> background of writing raw SQL and then used it rather than figuring out the 
> (often relatively simple) ORM way of doing it. This is then a big 
> maintenance burden, and the harsher warning against its use is a good idea.
>
> Also thanks for documenting *RawSQL*, didn't realize it was usable until 
> now so I've been able to get rid of some *extra()* usage in django-mysql.
>
> On Wednesday, August 5, 2015 at 1:09:30 AM UTC+1, Josh Smeaton wrote:
>>
>> You're right about that. You can aggregate over custom expressions. For 
>> aggregating over enums you should be able to use case expressions
>>
>> On Wed, 5 Aug 2015 at 05:05 Anssi Kääriäinen  wrote:
>>
>>> On Tuesday, August 4, 2015, Shai Berger  wrote:
>>>>
>>>> The classic database aggregation examples involve aggregation over 
>>>> time: Sum
>>>> of sales per quarter (which is, itself, a function over date); average
>>>> temparature per month; etc. All these require group-by clauses which 
>>>> name
>>>> (expressions over) columns which are not FKs.
>>>>
>>>>
>>> The following should work:
>>>
>>>
>>>  
>>> qs.annotate(quarter=Quarter('sold_date')).values('quarter').annotate(sum=Sum('amount'))
>>>
>>> I recall some changes to how the group by expression is generated for 
>>> expressions. If I recall correctly the group by should have the expression 
>>> itself now, not the base columns of the expression.
>>>
>>> There are many similar examples involving "enum columns" -- columns with 
>>>> a
>>>> limited set of choices, where the choices are not instances of another 
>>>> model.
>>>
>>>
>>> I'm not sure of this one.
>>>
>>>  - Anssi
>>>
>>> -- 
>>> 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/FojuU0syO8Y/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to 
>>> django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/CALMtK1FqTkdmnXNYvjZ8U_QF9%2BWzrMCb1DDFQU5WB4SiKPX06g%40mail.gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/CALMtK1FqTkdmnXNYvjZ8U_QF9%2BWzrMCb1DDFQU5WB4SiKPX06g%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3521e31f-48a9-4576-86aa-b13227a7c29c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django reusable app versions.

[Adam Johnson]

Hi Kevin,

I feel like this is a support question more than a question around
developing Django, so I've pasted my canned response below. But to answer
your question: yes you have to downgrade your database while on version
0.0.2. Django can't downgrade a migration without the file being there :)
It ignores all migrations named in the database that it doesn't have in the
local repository, to deal with removed apps, migration files, squashing,
etc.

If you think the documentation is lacking, perhaps a section on third party
apps could be added to:
https://docs.djangoproject.com/en/2.2/topics/migrations/ .

Thanks,

Adam

---

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for 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. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Tue, 12 Nov 2019 at 17:09, Kevin Sallée  wrote:

> Hi, I'm new to Django so excuse me if it's a noob question.
>
> I have a Django app, let's call it "project", that uses a Django reusable
> app, let's call it "app", version controlled on github, and tagged.
>
> 1. I create a first version of the app with its initial 0001_initial.py
> migration file, tag it 0.0.1, and add it to "project" requirements.txt
> 2. I then run "python manage.py migrate app". This picks 0001_initial and
> applies the migration.
> 3. I do changes to app, add a field, I have 0002_model_newfield.py file, I
> tag it 0.0.2, and change the version required in requirements.txt
> 4. I run "python manage.py migrate app". This picks 0002_model_newfield
> and applies the migration.
>
> Now, what happens if I want to go back to version "0.0.1" of the app? I
> can change the requirements, reinstall the library, but migrate won't do
> much if I go back to a state where I have less migration files available.
> The only thing I can do, I think, is stay on "0.0.2", do a "python
> manage.py migrate app 0001", and then switch back to the "0.0.1" version.
>
> I haven't found any information on how you version control alongside with
> git and downgrade django reusable apps. Maybe there is an open source
> project that can provide some pointers?
>
> I'm just starting with this and I might have more complex dependencies to
> deal with, I just want to make sure I'm not missing something obvious here.
>
> 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/e7a1404d-bb4a-401d-bdc2-9d7de1ad8e71%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3NBaEyf%2BodDxLpzHrHWrTO%3DqGMHoPA4o-82-kAQ6s%3DKg%40mail.gmail.com.

Re: Django reusable app versions.

[Adam Johnson]

No worries, glad to have you in our community.

On Tue, 12 Nov 2019 at 19:09, Kevin Sallée  wrote:

> You are totally right, my mistake. Sorry about that, noob here.
>
> On Tuesday, November 12, 2019 at 12:16:12 PM UTC-6, Adam Johnson wrote:
>>
>> Hi Kevin,
>>
>> I feel like this is a support question more than a question around
>> developing Django, so I've pasted my canned response below. But to answer
>> your question: yes you have to downgrade your database while on version
>> 0.0.2. Django can't downgrade a migration without the file being there :)
>> It ignores all migrations named in the database that it doesn't have in the
>> local repository, to deal with removed apps, migration files, squashing,
>> etc.
>>
>> If you think the documentation is lacking, perhaps a section on third
>> party apps could be added to:
>> https://docs.djangoproject.com/en/2.2/topics/migrations/ .
>>
>> Thanks,
>>
>> Adam
>>
>> ---
>>
>> Hi!
>>
>> I think you've found the wrong mailing list for this post. This mailing
>> list is for 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. People on this list are unlikely to answer your
>> support query with their limited time and energy. Read more on the mailing
>> lists at https://www.djangoproject.com/community/
>>
>> For support, please use the NEW Django forum at
>> https://forum.djangoproject.com , django-users mailing list, or IRC
>> #django on Freenode, or a site like Stack Overflow. There are people out
>> there willing to help on those channels, but they might not respond if you
>> don't ask your question well. Stack Overflow's question guide can help you
>> frame it well: https://stackoverflow.com/help/how-to-ask .
>>
>> Also if you haven't read it, please take a look at Django's Code of
>> Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
>> rules" for working well as a community, and will help you get the most out
>> of Django and our fantastic community.
>>
>> Thanks for your understanding,
>>
>> Adam
>>
>> On Tue, 12 Nov 2019 at 17:09, Kevin Sallée  wrote:
>>
>>> Hi, I'm new to Django so excuse me if it's a noob question.
>>>
>>> I have a Django app, let's call it "project", that uses a Django
>>> reusable app, let's call it "app", version controlled on github, and tagged.
>>>
>>> 1. I create a first version of the app with its initial 0001_initial.py
>>> migration file, tag it 0.0.1, and add it to "project" requirements.txt
>>> 2. I then run "python manage.py migrate app". This picks 0001_initial
>>> and applies the migration.
>>> 3. I do changes to app, add a field, I have 0002_model_newfield.py file,
>>> I tag it 0.0.2, and change the version required in requirements.txt
>>> 4. I run "python manage.py migrate app". This picks 0002_model_newfield
>>> and applies the migration.
>>>
>>> Now, what happens if I want to go back to version "0.0.1" of the app? I
>>> can change the requirements, reinstall the library, but migrate won't do
>>> much if I go back to a state where I have less migration files available.
>>> The only thing I can do, I think, is stay on "0.0.2", do a "python
>>> manage.py migrate app 0001", and then switch back to the "0.0.1" version.
>>>
>>> I haven't found any information on how you version control alongside
>>> with git and downgrade django reusable apps. Maybe there is an open source
>>> project that can provide some pointers?
>>>
>>> I'm just starting with this and I might have more complex dependencies
>>> to deal with, I just want to make sure I'm not missing something obvious
>>> here.
>>>
>>> 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-d...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/e7a1404d-bb4a-401d-bdc2-9d7de1ad8e71%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/

Re: django-admin startproject settings.py has some security holes

[Adam Johnson]

There is such a link since 2013:
https://github.com/django/django/commit/912b5d2a6bc78067d6a7e130f10514c51bd1a58f

On Thu, 24 Oct 2019 at 23:31, Olivier Dalang 
wrote:

> Hi,
>
> Just a reminder about this page in the docs:
> https://docs.djangoproject.com/en/2.2/howto/deployment/checklist/
> It basically already covers it all. Maybe a direct link to that page from
> the settings file would be good enough?
>
> Cheers,
>
> Olivier
>
> On Thu, Oct 24, 2019, 04:45 Josh Smeaton  wrote:
>
>> A quick idea from the top of my head, is to change the assignment of
>> SECRET_KEY in the generated settings to something like:
>>
>> SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY",
>> "insecure-")
>>
>> It signals that secrets in the environment are a good idea, that the
>> default generated value is insecure, and it still has a random part so that
>> default sites aren't automatically hackable when deployed. There's no
>> impact to people just getting started.
>>
>> We could go a small step forward and use `check --deploy` to check for
>> the substring `insecure` (even though I believe the KEY is technically
>> bytes?).
>>
>> Just throwing something out there.
>>
>>
>> On Monday, 21 October 2019 23:48:59 UTC+11, Taymon A. Beal wrote:
>>>
>>> Is the requirement here to avoid introduce additional barriers to
>>> getting up and running in local development, or to deploying a site so that
>>> it's accessible from the public internet?
>>>
>>> Both of these are important goals, but trading off security against the
>>> latter worries me. I don't think we're doing beginners any favors if we
>>> make it easier for them to deploy sites with security issues, especially
>>> since they won't be in a good position to appreciate the consequences.
>>> Ideally we'd make it easy for beginners to deploy sites without security
>>> issues, but that's a hard problem given the diversity of production
>>> environments; in the meantime, I think we need to accept the reality that
>>> figuring out how to store secrets *is* a prerequisite to deploying Django
>>> in production, notwithstanding how much we wish it weren't.
>>>
>>> I'd be interested in trying to contribute a solution more secure than
>>> the status quo without introducing more barriers to local development, if
>>> it would have a chance of being accepted.
>>>
>>> Taymon
>>>
>>> On Friday, October 11, 2019 at 8:00:59 AM UTC-7, Carlton Gibson wrote:

 It's just scope:

* Not clear we need to _replace_ the space for books, and blog
 posts, and so on, in the main docs.

 and bandwidth:

* These things are difficult to get right, and it needs someone to
 do them. (PRs always warmly received!)

 On balance, I have to say, I think the default project template does
 very well.
 Taking a beginner, say, and adding, "As well as the million things
 you're already dealing with, there are these things called environment
 variable and..." is a step I'd be very cautious about taking.

 Yes, granted, for professional deployment, you might want different —
 but we have to serve everyone.

>>> --
>> 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/3443dbe6-1a6a-45af-b5ec-08cf78426869%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/CAExk7p0%3DzRMJi1ObZnSuKncYgXVuNT-k%3DqMj5ONVuEN_nVTEQw%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/CAMyDDM3jxm_x41otzdsqWeKG2munqrX5eqM-SG8kK_B9Y06c_w%40mail.gmail.com.

Deprecate HttpRequest.is_ajax

[Adam Johnson]

Django's HttpRequest.is_ajax method determines whether the request was made
with the JS API XMLHttpRequest
https://docs.djangoproject.com/en/2.2/ref/request-response/#django.http.HttpRequest.is_ajax
. It does so by checking the X-Requested-With header.

The new way of making "AJAX" requests from the browser is the JavaScript
fetch() API : https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API .

I think the  is_ajax() documentation is at least a little misleading in
pretending XMLHttpRequest is the only JS API. There also aren't any special
headers set by fetch() so it's not possible to detect its requests.

I propose deprecating is_ajax() with no replacement.

Thoughts?

-- 
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/CAMyDDM0i-p0ZxBj-fSheGs-2pMXH7K7Oka%3DCjy1YXx-emBu3mw%40mail.gmail.com.

Re: Deprecate HttpRequest.is_ajax

[Adam Johnson]

Right - Flask's error message also points to something I was mistaken
about. XMLHttpRequest does not set this header. jQuery adds it (
https://api.jquery.com/jquery.ajax/#jQuery-ajax-settings ), and presumably
some other JS libraries.

In my opinion there are not many good reasons to have to change behaviour
> if a request is made via XHR. I think the most common usage is to have a
> single view that returns a JSON response or a HTML response depending on if
> XHR is used (
> https://github.com/search?l=Python&q=request.is_ajax&type=Code), which
> isn’t great and isn’t reliable.
>

Riight too. A better way would be to check the Accept header. DRF does
this: https://www.django-rest-framework.org/api-guide/content-negotiation/
. Django doesn't provide any tools at the moment for parsing Accept. We
could add an API like https://pypi.org/project/django-accept-header/ ?

On Sat, 16 Nov 2019 at 16:16, Tom Forbes  wrote:

> I would agree. Flask has done the same:
>
> DeprecationWarning: Request.is_xhr is deprecated. Given that the
> X-Requested-With header is not a part of any spec, it is not reliable
>
> In my opinion there are not many good reasons to have to change behaviour
> if a request is made via XHR. I think the most common usage is to have a
> single view that returns a JSON response or a HTML response depending on if
> XHR is used (
> https://github.com/search?l=Python&q=request.is_ajax&type=Code), which
> isn’t great and isn’t reliable.
>
>
> On 16 Nov 2019, at 16:08, Adam Johnson  wrote:
>
> Django's HttpRequest.is_ajax method determines whether the request was
> made with the JS API XMLHttpRequest
> https://docs.djangoproject.com/en/2.2/ref/request-response/#django.http.HttpRequest.is_ajax
> . It does so by checking the X-Requested-With header.
>
> The new way of making "AJAX" requests from the browser is the JavaScript
> fetch() API : https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API .
>
> I think the  is_ajax() documentation is at least a little misleading in
> pretending XMLHttpRequest is the only JS API. There also aren't any special
> headers set by fetch() so it's not possible to detect its requests.
>
> I propose deprecating is_ajax() with no replacement.
>
> Thoughts?
>
> --
> 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/CAMyDDM0i-p0ZxBj-fSheGs-2pMXH7K7Oka%3DCjy1YXx-emBu3mw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM0i-p0ZxBj-fSheGs-2pMXH7K7Oka%3DCjy1YXx-emBu3mw%40mail.gmail.com?utm_medium=email&utm_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/84DCD242-69A8-4B8D-9EB6-243312B5F77F%40tomforb.es
> <https://groups.google.com/d/msgid/django-developers/84DCD242-69A8-4B8D-9EB6-243312B5F77F%40tomforb.es?utm_medium=email&utm_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/CAMyDDM12ozNou4y6s-AktSwnMfBLDR5FJjYAw-n0kofZ3%3DYtoA%40mail.gmail.com.

Re: The Missing Piece in Indexing

[Adam Johnson]

Hi Behzad

Your database will automatically use the appropriate indexes for given
queries, thanks to its optimizer. See
https://en.m.wikipedia.org/wiki/Query_optimization and DB specific docs
such as: https://www.postgresql.org/docs/9.0/planner-optimizer.html ,
https://dev.mysql.com/doc/internals/en/optimizer.html .

USE INDEX is only for forcing usage of particular indexes if you are *sure*
that you know better than your optimizer. You don't need it in 99% of
cases, it's a bit of a sledgehammer, and prone to bitrot into bad
performance if your tables change. However if you're sure you want to do
this, for MySQL/MariaDB, my library Django-MySQL adds a QuerySet extension
for it:
https://django-mysql.readthedocs.io/en/latest/queryset_extensions.html#django_mysql.models.use_index
. I've actually never ended up needing it myself.

Thanks,

Adam

On Wed, 20 Nov 2019 at 08:31, Behzad  wrote:

> Hey all!
>
> I noticed a while ago that we can set indexes in the models Meta as
> described here
> . But
> I can't find any commands on the Queryset which helps us use the declared
> indexes, the equivalent of `USE INDEX` in the DB.
> Is this planned to be developed?
>
> Best
> Behzad
>
> --
> 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/e95a9413-1c0f-48b2-ae25-5417c3a742e2%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3n9%2ByJNyXezcDuyv1m0WX5fLbUS4ZnTDMRAW7F3tHhkQ%40mail.gmail.com.

Re: Add subdomains of localhost to ALLOWED_HOSTS in DEBUG mode

[Adam Johnson]

I’m all in favour of making development easier. Would be in favour of this
if I could see a source :) Also can you check the behaviour in more
browsers than Chrom(e|ium)? :)

On Thu, 21 Nov 2019 at 21:40, Gordon  wrote:

> Good afternoon,
>
> It seems pretty straightforward to me as a win with no downsides.  Chrome
> resolves subdomains of localhost as localhost.  I did a little searching
> (but forgot to keep the sources) and discovered that this behavior was
> intentional and spec compliant.  This is extremely handy for local
> development since it allows one to test subdomains without fooling with
> network DNS or modifying host files.
>
> I opened ticket https://code.djangoproject.com/ticket/31010 and was asked
> to canvas for opinions.
>
> I think that updating the handling of ALLOWED_HOSTS in
> HttpRequest.get_host()from:
>
> # Allow variants of localhost if ALLOWED_HOSTS is empty and 
> DEBUG=True.
> allowed_hosts = settings.ALLOWED_HOSTS
> if settings.DEBUG and not allowed_hosts:
> allowed_hosts = ['localhost', '127.0.0.1', '[::1]']
>
>
> to
>
> # Allow variants of localhost if ALLOWED_HOSTS is empty and 
> DEBUG=True.
> allowed_hosts = settings.ALLOWED_HOSTS
> if settings.DEBUG and not allowed_hosts:
> allowed_hosts = ['.localhost', '127.0.0.1', '[::1]']
>
>
> would be safe and support this pattern without requiring any changes to
> settings files which is quite nice for new projects.  Please let me know
> what you think =)
>
> Thanks,
> Gordon
>
>
>
> --
> 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/b9e276f0-76f1-4a9c-be22-cb7286c20ec5%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0ufpyu50t_tbACPrEwJ94LYTWGyfywGzooA7%3D3pVnXBw%40mail.gmail.com.

Re: Add subdomains of localhost to ALLOWED_HOSTS in DEBUG mode

[Adam Johnson]

Spec seems clear enough. Seems like it’s still an open bug in Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=1433933

Can you reopen the ticket, add the spec link to the description, and open a
PR? Thanks!

On Fri, 22 Nov 2019 at 06:31, אורי  wrote:

> 2090?
> אורי
> u...@speedy.net
>
>
> On Thu, Nov 21, 2019 at 11:58 PM gordon  wrote:
>
>> Spec:
>>
>>- https://tools.ietf.org/html/rfc6761#section-6.3
>>
>> It didn't seem to work on IE edge.  At the rate of browser updates I
>> expect all browsers to support this by 2090.  But it does make development
>> on Chrome nice now =)
>>
>> On Thu, Nov 21, 2019 at 4:49 PM Adam Johnson  wrote:
>>
>>> I’m all in favour of making development easier. Would be in favour of
>>> this if I could see a source :) Also can you check the behaviour in more
>>> browsers than Chrom(e|ium)? :)
>>>
>>> On Thu, 21 Nov 2019 at 21:40, Gordon  wrote:
>>>
>>>> Good afternoon,
>>>>
>>>> It seems pretty straightforward to me as a win with no downsides.
>>>> Chrome resolves subdomains of localhost as localhost.  I did a little
>>>> searching (but forgot to keep the sources) and discovered that this
>>>> behavior was intentional and spec compliant.  This is extremely handy for
>>>> local development since it allows one to test subdomains without fooling
>>>> with network DNS or modifying host files.
>>>>
>>>> I opened ticket https://code.djangoproject.com/ticket/31010 and was
>>>> asked to canvas for opinions.
>>>>
>>>> I think that updating the handling of ALLOWED_HOSTS in
>>>> HttpRequest.get_host()from:
>>>>
>>>> # Allow variants of localhost if ALLOWED_HOSTS is empty and 
>>>> DEBUG=True.
>>>> allowed_hosts = settings.ALLOWED_HOSTS
>>>> if settings.DEBUG and not allowed_hosts:
>>>> allowed_hosts = ['localhost', '127.0.0.1', '[::1]']
>>>>
>>>>
>>>> to
>>>>
>>>> # Allow variants of localhost if ALLOWED_HOSTS is empty and 
>>>> DEBUG=True.
>>>> allowed_hosts = settings.ALLOWED_HOSTS
>>>> if settings.DEBUG and not allowed_hosts:
>>>> allowed_hosts = ['.localhost', '127.0.0.1', '[::1]']
>>>>
>>>>
>>>> would be safe and support this pattern without requiring any changes to
>>>> settings files which is quite nice for new projects.  Please let me know
>>>> what you think =)
>>>>
>>>> Thanks,
>>>> Gordon
>>>>
>>>>
>>>>
>>>> --
>>>> 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/b9e276f0-76f1-4a9c-be22-cb7286c20ec5%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/django-developers/b9e276f0-76f1-4a9c-be22-cb7286c20ec5%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>>> 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/xcoAF9Gm_dI/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/CAMyDDM0ufpyu50t_tbACPrEwJ94LYTWGyfywGzooA7%3D3pVnXBw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/django-developers/CAMyDDM0ufpyu50t_tbACPrEwJ94LYTWGyfywGzooA7%3D3pVnXBw%40mail.gmail.com?utm_medium=email&utm_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
>&

Re: ngettext_lazy and ngettext

[Adam Johnson]

Uri,

I understand this is frustrating for you as a user. Thank you for
documenting your issues extensively so they're easy to follow. However it
seems like a complicated problem and that Claude is the only person
spending significant time working on translations these days. If you have
some resources to try help fix the bug, or document the workaround (running
makemessages after upgrade?) that would be helpful to the community.

Thanks,

Adam

‪On Sat, 23 Nov 2019 at 11:32, ‫אורי‬‎  wrote:‬

> Django developers,
>
> https://code.djangoproject.com/ticket/30439
>
> I think Django 2.2 (which is LTS) should be updated in a way that using
> these functions to translate will be backward-compatible, so that
> everything that worked with Django up to 2.1 will keep working in Django
> 2.2 and above. Currently this is not the case in Hebrew with Speedy Net
> , which starts displaying error
> messages in English in the Hebrew websites (Speedy Net & Speedy Match) when
> I upgrade Django to 2.2, which is *not* what I expect. In Django up to
> 2.1 these error messages are translated to Hebrew, which *is* what I
> expect.
>
> After encountering this problem I decided to keep Speedy Net in Django 2.1
> (which I upgraded from 1.11 about 3 weeks ago) until there is a solution,
> or at least until I can make Speedy Net work in Hebrew in Django 2.2 and
> above. However, I understand the end-of-life of Django 2.1 is coming soon,
> which means we will be using an obsolete version of Django in a production
> website.
>
> As long as this issue is not resolved, I would appreciate if you will
> extend the end-of-life date of Django 2.1 to at least one or two months
> after this issue will be resolved. Yes I know I can downgrade Django to
> 1.11 and use it until April 2020, but since I already upgraded to 2.1 I'm
> not sure it's a good idea to downgrade Django now. And also, since Django
> 2.2 was released almost 8 months ago, I'm not sure if this problem will be
> resolved before April 2020. #30439
>  was opened about 7 months
> ago and it's still not resolved.
>
> אורי
> u...@speedy.net
>
>
> ‪On Fri, Nov 1, 2019 at 10:47 AM ‫אורי‬‎  wrote:‬
>
>> Hi,
>>
>> I want to add that it was very simple to upgrade Django from 1.11 to 2.0
>> and then to 2.1, I only had to change minor changes in my code - changing
>> to class-based views and updating my tests to reflect the 403 pages
>> (instead of a 302 redirect), so thanks for maintaining Django and for not
>> breaking too many things when upgrading Django from one version to another.
>>
>> I hope you will agree to revert the changes done to ngettext_lazy and
>> ngettext in version 2.2 and then I will be able to upgrade Django to the
>> next LTS version.
>>
>> אורי
>> u...@speedy.net
>>
>>
>> ‪On Fri, Nov 1, 2019 at 10:18 AM ‫אורי‬‎  wrote:‬
>>
>>> Django developers,
>>>
>>> I opened ticket https://code.djangoproject.com/ticket/30939 and I was
>>> referred to https://code.djangoproject.com/ticket/30439 as a
>>> duplicate. I don't understand why you need such a long formula to decide if
>>> a number is singular or plural. If it's 1 it's singular, otherwise it's
>>> plural. What's wrong about that?
>>>
>>> If you want to define a function with 4 strings for 4 different numbers,
>>> you should define a new function and not edit ngettext_lazy and ngettext.
>>> My code which works with all Django versions up to 2.1, breaks with Django
>>> 2.2. This issue prevents me from upgrading Django to 2.2. Is this change
>>> documented in the release notes? I didn't find it there. I would like to
>>> keep using ngettext_lazy with 2 strings (when the number is either 1 or not
>>> 1) and not with 4 strings. Actually I always use plural but because similar
>>> validators used ngettext_lazy (MinLengthValidator and MaxLengthValidator in
>>> django.core.validators) I also used it in my validators. But the number I'm
>>> using is never equal to 1.
>>>
>>> You can see my code here (search for "ngettext_lazy"):
>>>
>>> https://github.com/speedy-net/speedy-net/blob/master/speedy/core/accounts/validators.py
>>>
>>>
>>> And the relevant Django code:
>>>
>>> https://github.com/django/django/blob/master/django/core/validators.py#L348-L377
>>>
>>>
>>> אורי
>>> 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/CABD5YeHjk183hY5bKJk1w8LoVcUXisc5G29c49VzK4y8eUy5JQ%40mail.gmail.com
> 
> .
>


-- 
Adam

-- 
You received this message because you a

Re: Django front end usage

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for 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. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Mon, 25 Nov 2019 at 12:53, DEEPAK NAILWAL 
wrote:

> Hi All,
>
> I am working on a project and my site is up and running.
>
> Now i want to make my site much presentable as currently it just having
> login, password and forgot password link.
>
> Can you please help me how i can achieve that in short span of time ?
>
>
> --
> 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/fe5227be-bf1a-4b0d-9f2b-29e782eb8ce4%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2%2BmD0my-psKbXiu32t%3D4YiYWocE4Ys7Dz1imj_4dafDw%40mail.gmail.com.

Re: django last version installation

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for 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. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Tue, 26 Nov 2019 at 12:58, Marek Zdybel  wrote:

> I'm not sure but maybe try use pip install pytz
>
> wt., 26 lis 2019, 13:42 użytkownik pip django 
> napisał:
>
>> I tried to install django last version 2.2.7 with python 3.8 but it's not
>> worked.and this error message appear on the cmd No Module named pytz
>> ,
>> I need 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/68e6a783-90ec-4399-aea6-35bd99ab8173%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/CAPsBOdNv4UgpuS%3D-dm0OeF2_ArVbcyUi3U6bN%2BtsRmC7i6a2pg%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/CAMyDDM3Bmv6v27Gf32oa%2B3dxUS5Yw59JK6-HpxY9wmi7JR_mLg%40mail.gmail.com.

Re: New to Open Source Contribution Need Help With Setting Up Environment For Channels to Reproduce Issues After Cloning From Git

[Adam Johnson]

Hi Suvodeep,

Did you see this documentation page?
https://channels.readthedocs.io/en/latest/contributing.html

If you use the command:

pip install -e .

You can install your cloned channels copy in a virtual environment and use
that as normal in a channels app.

Afraid I haven't worked on it myself but the instructions seem pretty
complete. I don't think there are many people working on Channels itself
right now though.

Thanks,

Adam

On Tue, 5 Nov 2019 at 05:49, Suvodeep Dubey  wrote:

> I have cloned channels repo in my local. I was going through the bugs but
> was unable to set-up the environment to reproduce the bugs.
>
> I have the following understanding:
>
> 1. Rather than `pip install channels` clone the channels from git
> 2. Execute the channels parallel to your application and make them talk
> and see the errors in application and logs in channels.
>
> I am unable to build and run the channels and configure it with a dummy
> Django app to reproduce the bugs.
>
> --
> 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/ddd5f084-7797-471d-889f-456c83df8b28%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2UNk3vZU2dUBmEo5C7cH%2B57fzP_PdiNfSDZUXDS%2B9UDg%40mail.gmail.com.

Re: Add an --unapplied option for showmigrations

[Adam Johnson]

I think you want "manage.py migrate --plan" - new in Django 2.2
https://docs.djangoproject.com/en/2.2/ref/django-admin/#cmdoption-migrate-plan

On Fri, 29 Nov 2019 at 10:59, Sky Christensen 
wrote:

> I'd like to be able to easily see a list of only unapplied migrations.
>
> I often find myself switching to a new branch and wanting to quickly
> find out whether it contains any migrations that are yet to be applied
> to my development database, and what they are.
>
> At the moment I use a plain `./manage.py showmigrations`, but when there
> are lots of migrations, scanning the resulting list to find out which --
> if any -- migrations are not yet applied is tedious and error-prone.
>
> I'd really like to be able to do something like `./manage.py
> showmigrations --unapplied` or `./manage.py showmigrations -u`, and have
> that produce a list of only the unapplied migrations.
>
> I'll be happy to open a ticket and submit a patch to do this if others
> think the idea has merit.
>
> --
> 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/8ebd8bdddf81b8fe8fe83f8ee2c8faa2%40skychristensen.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/CAMyDDM2Nb_AWfsx05EVydo4PV20iWbcA4GBbZCT_Rn%3De%3D%3DMFXA%40mail.gmail.com.

Re: Status of 3.0 release blockers

[Adam Johnson]

Recai, I’m afraid that’s not true. Django 3.0 adds ASGI support for
asynchronous calls to the outermost handler. However all the rest of the
stack remains synchronous. See the release notes:
https://docs.djangoproject.com/en/dev/releases/3.0/

For a single file demo app see my blog post:
https://adamj.eu/tech/2019/09/14/a-single-file-async-django-app/


On Sun, 1 Dec 2019 at 20:05, Recai Atak  wrote:

> Hi Carlton ,
>
> i saw it somewhere , django 3.0 is coming with async database transaction
> availability . is that right ?
>
> 10 Eylül 2019 Salı 11:56:51 UTC+3 tarihinde Carlton Gibson yazdı:
>>
>> Hi all.
>>
>> Time to begin the release process for 3.0! 🎉
>>
>> The feature freeze was yesterday, with some last things making it over
>> the line.
>>
>> Claude has updated the translations catalogs already.
>>
>> Mariusz and Simon have cleaned up the last release blocker this morning,
>> so we've branched
>> stable/3.0.x and we're ready to go with 3.0 alpha 1 today.
>>
>> The schedule[0] is for the alpha today, beta in a month or so, release
>> candidate a month after that.
>> Final release is due December 2nd.
>>
>> https://code.djangoproject.com/wiki/Version3.0Roadmap#schedule
>>
>> We will use this thread to update on any changes.
>> To that, please test early and often.
>>
>> Thanks all for your super efforts on this 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/beb90e11-ee20-4826-b22b-e1a8af69407a%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3LuPzEUC4wjEjXmdeCqxx%2BUtVDOM60LXogSQpRK9WL%2BQ%40mail.gmail.com.

Re: Forms submitted by bots

[Adam Johnson]

Preventing bot submissions is a bit of an arms race. Django could add some
protection but if many Django sites use it then bot scripts might be
adapted to workaround it.

I've had success using django-recaptcha in the past:
https://github.com/praekelt/django-recaptcha . django-honeypot looks good
too.

I think adding such protection would be a major project - research plus
implementation. I think it could make a good Google Summer of Code project
and will suggest it to the other DSF members.

‪On Fri, 13 Dec 2019 at 04:02, ‫אורי‬‎  wrote:‬

> Thank you. How do I use django-honeypot and how does it work? How does it
> affect our human users and how does it affect the bots? I didn't understand
> from their website.
>
> I added a new feature request https://code.djangoproject.com/ticket/31085
> אורי
> u...@speedy.net
>
>
> On Fri, Dec 13, 2019 at 5:50 AM Kye Russell  wrote:
>
>> This is more of a support question, but:
>> https://github.com/jamesturk/django-honeypot will thwart the majority of
>> (naive) automation attempts.
>>
>>
>> On 13 December 2019 at 10:42:54 am, אורי (u...@speedy.net) wrote:
>>
>> Django developers,
>>
>> After releasing Speedy Net to production I received lots of spam to our
>> contact forms [https://en.speedy.net/contact/ &
>> https://en.speedymatch.com/contact/]. I found out that all of these spam
>> messages were produced by bots. I had to add a new "no bots" field to this
>> form, where I just ask users to type a specific number and validate it in
>> the form. Since I added this field I didn't receive any more spam from the
>> contact forms. I know Django is using CSRF cookie directives, but isn't it
>> possible to prevent bots from submitting forms? I would like to remove the
>> "no bots" field from this form as it is wasting time of our users who want
>> to contact us. But I don't want to receive messages from bots. Is there
>> another way to prevent bots from submitting forms?
>>
>> אורי
>> 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/CABD5YeGj%2BFdsrmq%3D_Yai3bJHDSG_5Q1tmXSHLSQv4YexgomZxQ%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/CANK-ykkZSVhyDA4nNg0JKudbK9zdyXGVews48MN0pmAT47fb_A%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/CABD5YeFYbT-0pA%3DuMsdEtZGCvQvVVNDFt3RKH-3zAc_vNik9hA%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/CAMyDDM3MzqGw-EQ9ApyWiFUsgKx-nqPvoGYZwbAOBvZu8pyTXg%40mail.gmail.com.

Re: Add an --unapplied option for showmigrations

[Adam Johnson]

Sure, feel free to open a PR and mention me in a comment with "@adamchainz"
so I see it.

On Sat, 14 Dec 2019 at 23:09, Sky Christensen 
wrote:

> Thanks Adam - I hadn't come across that, and think it's what I'm after.
>
> Would it be worth adding a note about this to the "showmigrations"
> section of the docs? It strikes me that that's the place people would
> look for an answer to the question "How can I see a list of just the
> unapplied migrations?".
>
> It could be quite a short note. Something like "To show only the
> unapplied migrations, use `django-admin migrate --plan`."
>
>
> On 2019-11-29 04:31, Adam Johnson wrote:
> > I think you want "manage.py migrate --plan" - new in Django 2.2
> >
> https://docs.djangoproject.com/en/2.2/ref/django-admin/#cmdoption-migrate-plan
> >
> > On Fri, 29 Nov 2019 at 10:59, Sky Christensen 
> > wrote:
> >
> >> I'd like to be able to easily see a list of only unapplied
> >> migrations.
> >>
> >> I often find myself switching to a new branch and wanting to quickly
> >>
> >> find out whether it contains any migrations that are yet to be
> >> applied
> >> to my development database, and what they are.
> >>
> >> At the moment I use a plain `./manage.py showmigrations`, but when
> >> there
> >> are lots of migrations, scanning the resulting list to find out
> >> which --
> >> if any -- migrations are not yet applied is tedious and error-prone.
> >>
> >> I'd really like to be able to do something like `./manage.py
> >> showmigrations --unapplied` or `./manage.py showmigrations -u`, and
> >> have
> >> that produce a list of only the unapplied migrations.
> >>
> >> I'll be happy to open a ticket and submit a patch to do this if
> >> others
> >> think the idea has merit.
> >>
> >> --
> >> 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/8ebd8bdddf81b8fe8fe83f8ee2c8faa2%40skychristensen.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/CAMyDDM2Nb_AWfsx05EVydo4PV20iWbcA4GBbZCT_Rn%3De%3D%3DMFXA%40mail.gmail.com
> > [1].
> >
> >
> > Links:
> > --
> > [1]
> >
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2Nb_AWfsx05EVydo4PV20iWbcA4GBbZCT_Rn%3De%3D%3DMFXA%40mail.gmail.com?utm_medium=email&utm_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/43b482b485ed96dd4f09ecb655d812f2%40skychristensen.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/CAMyDDM14N2NuMUfK_Rcr%2BCxghcDHR%3DKBRNhz6THf9mcGefD5Kg%40mail.gmail.com.

Re: Adding json lines (jsonl) serializer ro django

[Adam Johnson]

Hi Ali

Thanks for coming back to this. As I wrote on the ticket I'd be in favour
of adding this.

If you've got some code already it'd be good to see it in a PR

As for your question about overly long lines I think the .replace() style
is fine, or a consrtuction like this:

''.join([
"{"
'"key1": "value1",
"}",
])

Django contributions are not just about core developers giving you the
green light; you'll need to be a bit persistent to follow the coding
guides, fix test errors, respond to feedback, and push the patch through.
But given you've returned after 10 months I'm sure you can!

Thanks,

Adam


On Mon, 16 Dec 2019 at 23:05, Ali Vakilzade  wrote:

> Hey!
>
> A few month ago I opened a ticket for adding jsonl support to django
> serializers, I have added a basic patch as the starting point but my ticket
> was closed because it needed more discussion on the mailing list, I'm
> willing to work more on my patch to reach a final state (adding more tests
> and updating docs) but before working more on it just wanted to get the
> green light or some direction from you :-)
>
> Link to ticket: https://code.djangoproject.com/ticket/30190
>
> 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/17a919f1-559d-4599-85c8-236a9df5cf6e%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2RQ5x65XA%2BtiRmbhCKeasPn8a7wc_Na7LD8zLSEzLJMg%40mail.gmail.com.

Re: Suggestion to change the Logger date format to ISO 8601

[Adam Johnson]

Hi

I think the change you're referring to is in runserver:
https://github.com/django/django/blob/ff00a053478fee06bdfb4206c6d4e079e98640ff/django/core/servers/basehttp.py#L132
. Django uses a function from the standard library wsgiref simple server
here to generate server_time which is then shown in the log format. Indeed
it doesn't seem to allow configuring it at current.

I imagine there's a way to stop using the log_date_time_string() function
there if you want, however I am not sure about changing the default. Many
sites end up using runserver in production (despite it being insecure) and
it's likely there are scripts out there to parse the logs as they are.

Thanks,

Adam

On Mon, 16 Dec 2019 at 17:25, Leon Albrecht  wrote:

> At the moment Django is using "DD/MMM/ hh:mm:ss", but since 1988 there
> exists an ISO to format dates like this: "YYY-DD-MM hh:mm:ss"
>
> this is not a majot change and i've searched for to do it myself but
> according to the python logger libary this format is already in use, but
> Django apperantly changes it, somewhere I could not find it, to the
> beforementioned format.
>
> --
> 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/9536ce2f-e864-4231-99b5-66a7fde9f77c%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM22%3DU%2Bq4gOPGSSXer1wk5NjYx8Konkw7AAWVx2KVC9LHw%40mail.gmail.com.

Re: Suggestion: Add validators to Model Meta options

[Adam Johnson]

Hi Mathias

I feel like this has been suggested on the mailing list or ticket tracker
before, a few years ago. However after a quick check I can't find the
discussion/ticket in mind. Perhaps if you hunt a bit better than me you can
find it.

I think it's definitely a whole in the validation API. I think it'd be
better to see a composable Form.clean before another model option. Although
Django makes things fast I do always feel a bit comfortable how closely
coupled models and forms are.

Have you seen the database constraints added to Django and improved over
the recent versions?
https://docs.djangoproject.com/en/3.0/ref/models/constraints/ . I've been
using them on a few projects with some success. I prefer this kind of
validation since it's done in the database and thus it's impossible to
insert or update rows that are bad. There's definitely a (substantial)
project there to escalate check constraints into form validation errors too.

As for your composability approach - it's possible with today's Django if
you use a bit of Python magic. clean() should work as a callable class
rather than a function. For example (a sketch, untested):

class MultiCleaner:
def __init__(self, model_validators):
self.model_validators = model_validators

def __call__(self, instance):
for model_validator in model_validators:
model_validator(instance)


class Model:
...

clean = MultiCleaner([
ComparisonModelValidator('start_date', 'end_date'),
])

If you want to expand this idea and test it I'd be interested to see the
results.

Thanks,

Adam

On Mon, 16 Dec 2019 at 15:21, Mathias Weirsøe Klitgaard <
mathias.weir...@gmail.com> wrote:

> Hi Django Developers,
>
> I'm new to contributing and from what I gathered, I should ask here before
> opening a ticket.
>
> Right now the way to validate a model as a whole is to override
> Model.clean(). I have 2 problems with this:
>
> 1) If you do multiple checks that raise ValidationErrors, it is tedious to
> accumulate them.
> 2) Having different models that checks almost the same, e.g. start_date
> should come before end_date, it should be easy to reuse validators.
>
> I suggest to add a 'validators' option to Model Meta options.
> This should be very similar to the 'validators' option a Field has, a list
> of callables that raises ValidationErrors, except these should take an
> object 'instance' instead of a 'value'.
> It should then be Model.full_clean() responsibility to call these model
> validators in addition to what it already does.
>
> A concern I have is the confusion that may rise between these new 'model
> validators' and regular 'field validators'. Maybe clever naming could help
> distinguish them from eachother, and maybe it's not a huge deal since they
> are so closely related.
>
> It would be nice if some common model validators got built-in as well. For
> example a ComparisonModelValidator could take the names of two fields and
> validate if they are in the right order, it could look like
>
> class ComparisonModelValidator(low, high, message=None, code=None)
> * low - field name of the lesser field
> * high - field name of the greater field
> * message - if not None, overrides message
> * code - if not None, overrides code
>
> Then it could be used in the model as
>
> class Event(models.Model):
> start_date = models.DateField()
> end_date = models.DateField()
> ...
>
> class Meta:
> validators = [ComparisonModelValidator('start_date', 'end_date')]
>
>
> All feedback is appreciated.
>
> Mathias
>
> --
> 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/57166b63-56e6-485a-ba99-23369e7c6b1b%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1LQFrVTVFiCUJteycedpJS4y312P7DquqNfVR8PcBZdw%40mail.gmail.com.

Re: Static files configuration

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for 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. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Tue, 17 Dec 2019 at 18:08, Yash Garg  wrote:

> I have to display a HTML page with its supporting css, js and images. So i
> create a template folder to put HTML in it then i create a static folder in
> which i create css, js and img folder and put related files into these
> folders.
> then I configure the
> *Settings.py*
>
> BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
>
> STATIC_URL = '/static/'
> MEDIA_ROOT = os.path.join(BASE_DIR, 'media')
>
> MEDIA_URL = '/media/'
>
> STATIC_ROOT = os.path.join(BASE_DIR, 'static')
>
> #STATIC_URL = '/static/'
>
> STATIC_DIRS = (
> os.path.join(BASE_DIR, 'static'),
> )
>
>
> *.html file *
>
> {% load staticfiles %}
> 
>
> *views.py*
>
> def Index(request):
> return render(request,'Teenager Startup.html')
>
> please help me where i'm not getting the point.
>
> --
> 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/d3087903-f25d-45ad-8100-5f786d820708%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1C4tc-NDexpchfxFkwLJbvVsXbHNYxOP1%3Dnan2_o9ftA%40mail.gmail.com.

Re: Automatic admins registration

[Adam Johnson]

Hi Vladimir

Posting code to this mailing list is the wrong way to try make
contributions. Thanks for offering though.

Please read the guides at
https://docs.djangoproject.com/en/dev/internals/contributing/ for how to
post tickets and code.

However from a quick skim I'm not sure your code is valuable to add to
Django core at this time.

Thanks,

Adam

On Wed, 18 Dec 2019 at 14:31, Vladimir Godovalov  wrote:

> Hello to everyone,
>
>
> # This non-trivial patch improve Django functionality
> # by providing automatic registration in main admin.py
> # of all admin files of the project
>
>
>
>   admin.py module code  
>
> # admin.py
> import importlib
> from django.contrib import admin
> from django.apps import apps
>
>
> # automatic registration module
> models = apps.get_models()
> for model in models:
> model_name = str(model.__name__)
>
> # import and registration
> app_list = model.__module__.split(".")
> idx = app_list.index('models')
> app1 = app_list[idx-1]
> del app_list[idx:]
>
> try:
> module =
> importlib.import_module('.'.join(app_list)+'.'+app1.title()+'Admin')
> except ImportError:
> continue
> class_admin = module.str_to_class(model_name+'Admin')
> if class_admin is None:
> continue
> try:
> admin.site.register(model, class_admin)
> except admin.sites.AlreadyRegistered:
> pass
>
>
> ###  an application admin module code  ###
> # make sure the module name looks like 'BaseAdmin.py',
> # where the module name begins with the application
> # name in uppercase as well as the word 'Admin'
>
> # BaseAdmin.py
> import sys
>
> 
>
> insert your code here
>
> 
>
>
> def str_to_class(str):
> try:
> obj = getattr(sys.modules[__name__], str)
> except AttributeError:
> return None
> return obj
>
> --
> 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/1fddfa20-339f-463a-a168-e86d8bb3f739%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3KM9dP0s4G9Ti_fz%2B%3DMoDhdX1viHcULvOHoXhKmVDSCA%40mail.gmail.com.

Re: Sounding out for GSoC 2020.

[Adam Johnson]

>
> This year was interesting. Sage in particular did well putting together a
> cross-db JSONField, but he was probably under-mentored,
> since Mariusz has spent quite a bit of time reworking the PR, and still
> has a bit to go, before we can pull it in, hopefully for 3.1
>
> So, one consideration we need to think about seriously is our capacity for
> mentoring. (This isn't just about the candidate's ability — Sage was able
> to implement all suggestions — we just didn't have as much capacity as we
> might have liked to think about the requirement implementation — and there
> were four of us actively giving some time each... — Anyhow, to think
> about.)
>

I think your analysis is pretty accurate Carlton. Sage was a pretty
self-motivated candidate, writing some great blog posts about his code, and
we still didn't manage to merge his PR. Perhaps the project was larger than
we can reasonably expect?

Nice work on the descriptions there Andrew.

Django Service Hooks
>

I think a key use case of this is background task processing. Nearly all
the Django integrated libraries need to remember to "connection.close()" /
"close_old_connections" at the end of requests. I've seen a couple in-house
ones that needed this.

That said I can't think of much else to go inside the "service hook"?
There's not much else to "the end of a Django context" at the moment is
there?

Evented Datastores
>

I'm not sure if other databases have it but MariaDB recently implemented
"temporal tables" which are an SQL standard way of doing historical views
on data:  https://mariadb.com/kb/en/library/temporal-data-tables/

Admittedly not quite the same as event sourcing but perhaps easier to
implement given it would be limited to the ORM layer.

Django Benchmarking
>

I love djangobench, and do wish it was maintained and expanded. Running on
CI would be amazing.


2FA also sounds like a great idea.

Other ideas:

   - Support MySQL/MariaDB storage engines. I think other databases tend to
   support some table-level customizations to.
   - Official CORS middleware/view decorator. I took over maintenance of
   https://github.com/adamchainz/django-cors-headers and its design is a
   bit pants.


On Sat, 14 Dec 2019 at 17:30, Andrew Godwin  wrote:

> Here's my take on each of these, leaving out async as that'd be more
> dependent on where we were:
>
> Secrets Manager
> Many environments Django is deployed in use a separate secrets manager to
> store and provide secrets per environment - either as environment
> variables, files, or via a direct HTTP API. The project would be to design
> and add an abstraction interface over secrets managers that allows users to
> easily map to an external secret in a settings file. There's also room for
> giving Django a better, built-in per-environments settings option too,
> pulling from popular third-party patterns.
>
> Django Service Hooks
> Django has a lot tied to the HTTP lifecycle, and if you run it outside of
> this, you miss out on some key things - like database connections being
> closed properly, or logging, or some middleware. The project would be to
> design and implement a separate way of calling Django from a service
> framework - even if that framework was itself HTTP based (basically, don't
> rely on Django having to run through WSGI/ASGI). Initial idea is to provide
> a context manager that replaces the wrapping of a request, but the project
> would have to include requirements-gathering and interviewing people who
> use Django to power microservices to work out what they want.
>
> Evented Datastores
> Evented, or event-sourcing, database schemas are growing in popularity -
> essentially, a way to implement an append-only pattern on top of a
> relational database, where every single event that has happened is stored,
> but you can still efficiently retrieve the current state of an item. Given
> the way the pattern works, this would be possible to implement on top of
> Django models - likely as a whole new Model subclass - and implement with a
> matching QuerySet/Model API. It would require someone very skilled in
> database design, and it's also arguable if it should be in Django itself,
> or comprise of developing a third-party app alongside adding hooks/fixes to
> the Django ORM where needed to make it work well.
>
> GraphQL
> Basically, work on an "official" graphql-to-ORM mapper for Django,
> probably re-using a considerable amount of third-party work. This one could
> really vary in its application, based on how much other "API-ish" work the
> project includes (given that Django REST Framework is still separate, we
> should follow that rough pattern).
>
> Plus, some bonus ones that aren't Django code itself:
>
> Django Case Studies
> Our long-talked-about website which brings together case studies and white
> papers about why people choose Django, aimed at companies working out what
> they want to choose. This is likely only some coding and a lot of
> writing/legwork, so may not be a good

Re: what is the efficient way for Testing and making changes to the code

[Adam Johnson]

If you're looking to develop *Django itself* I think you're looking for
this guide: https://docs.djangoproject.com/en/3.0/intro/contributing/

Otherwise - I've pasted my common "wrong mailing list" post below.

Thanks for your understanding,

Adam

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for 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. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Fri, 20 Dec 2019 at 17:08, Pratik kumar 
wrote:

> I am just trying to figure how how the different things works in Djnago
> source, so that i can get on with contributing to the code
>
> On Friday, December 20, 2019 at 10:27:38 PM UTC+5:30, Dipankar wrote:
>>
>> Is it related to Django development?
>>
>> On Fri, Dec 20, 2019, 9:25 PM Pratik kumar 
>> wrote:
>>
>>> I used my local copy to create a new project and added some models to it
>>> after now i have made some changes to the local copy, Now how do i test
>>> those changes , do i need to create a new project each time from the local
>>> copy or is there a way around?
>>>
>>> --
>>> 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/f1c17efa-a1dc-4e07-b0c7-d3b7c7a33284%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/29acfda7-d5ca-48cb-8839-12c8dd48bb7c%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3-MoxoZX-5nmocTxybKf2u7uxzKtfDHdyTMoJi_MOykQ%40mail.gmail.com.

Re: [new contributor] Where to find resources to make changes to djangoproject.com ?

[Adam Johnson]

This guide may also be useful:
https://docs.djangoproject.com/en/3.0/intro/contributing/

On Fri, 20 Dec 2019 at 14:11, Abhijeet Viswa 
wrote:

> Hey,
>
> You can find the tutorial for Writing documentation here:
>
> https://docs.djangoproject.com/en/dev/internals/contributing/writing-documentation/
>
> The raw document files are basically text files written using
> reStructuredText syntax. You can find the inside the docs folder. Just
> edit the text files and then build the docs and see preview your
> changes. Commit the changes to the text files and make a PR.
>
> Cheers.
>
> On Fri, 20 Dec 2019 at 18:03, Gabriel Augendre 
> wrote:
> >
> > Hello there !
> >
> > I'm not a beginner in software development but I'm a new contributor to
> Django and I took this ticket from Trac :
> https://code.djangoproject.com/ticket/30780
> >
> > I made some progress creating a floating button to link to the FAQ but
> I'm having trouble finding where to edit the documentation pages themselves.
> > After running ./manage.py update_docs, I had some content that looked
> like documentation pages.
> > In data/djangodocs/sources/dev/docs/index.txt, I found some text that
> looked nearly exactly like the index page of the documentation, with the
> exception that in this file there is already a section about where to get
> help and it doesn't appear on the website served by ./manage.py runserver.
> >
> > Could someone show me around, explaining the build process, where to
> edit the pages and what to do in order to see the results ?
> >
> > Thanks in advance for any help :)
> >
> > Cheers,
> > Gabriel
> >
> > --
> > 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/60bf0ace-48aa-42aa-be31-208b200d7d4e%40googlegroups.com
> .
>
>
>
> --
> Abhijeet
>
> --
> 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/CAP1-Yrp%2BW-HZZKLhCYGJvXBR_zX%3DnNWsAAXM%3DBNmVVn_R7hm2w%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/CAMyDDM2Ct_L_XTJ-5LvVgJV_a1GM5LUhbKP9D%3DBMBqZMA%2BMQcA%40mail.gmail.com.

Google Patch Rewards program

[Adam Johnson]

I just saw Google is expanding their Patch Rewards program for open source
security improvements:
https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html

They are offering two tiers of rewards - $5,000 or $30,000 - for  open
source projects making security improvements. I think Django would find it
hard to fit in the "small" tier - we generally fix known vulnerabilities
quickly - but we could use the "large" tier to fund a bigger GSoC style
project. I suspect it would need active involvement from a DSF member to
push it through. Not sure how the funding would work in terms of DSF and
paying for development time on the project.

Some projects that could fit:

   - 2FA built-in to django.contrib.auth (as suggested for GSoC as well in
   this thread:
   
https://groups.google.com/forum/#!msg/django-developers/ifYT6lX8nmg/1nVO3As1AwAJ
   )
   - Adding CSP to SecurityMiddleware and shipping some default (django-csp
   is a good start but requires users to actively seek it:
   https://django-csp.readthedocs.io/en/latest/ )
   - Adding CORS to Django itself (I'm maintaining django-cors-headers, but
   its design is a bit pants
   https://github.com/adamchainz/django-cors-headers )
   - Other things in James Bennett's list of suggestions from this thread
   in May 2018:
   
https://groups.google.com/forum/#!msg/django-developers/DDpkrvFdnvk/J46ZbakxAgAJ

Thoughts?
-- 
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/CAMyDDM0MV-XLf8VV7ux%3DgY6J3pDhGAGrosG9gATNyRXZoRcZfw%40mail.gmail.com.

Re: declarative settings

[Adam Johnson]

When using settings for my third party packages I use:

* A class to read django.conf.settings and add defaults/other logic through
properties - for example
https://github.com/adamchainz/django-cors-headers/blob/31b9c2ef8a333a40f18081ffc1f1cba9fb34574d/src/corsheaders/conf.py
. This has the benefit of easily providing defaults, complex logic such as
deriving one value from multiple settings, and being read from settings at
runtime rather than import time.
* A bunch of system checks to validate them - for example
https://github.com/adamchainz/django-cors-headers/blob/31b9c2ef8a333a40f18081ffc1f1cba9fb34574d/src/corsheaders/checks.py
. For example, if a setting is *required*, you can add a check error; or if
a setting defaults to something unsuitable for production, you can add a
deploy check. System checks make it easy for users to upgrade your package
too, since many users don't read changelogs even for breaking version
changes.

I am in favour of most libraries adding a single setting that controls
them, like DRF has REST_FRAMEWORK. I know django-cors-headers doesn't
implement the pattern but this is for legacy reasons since I took it over.

I think this pattern solves your first concern Christian. As for your
second concern, I think checks make manual installation of apps easier. If
a user adds your app to INSTALLED_APPS, the system checks will run and can
highlight any missing/misconfigured settings from following the
installation docs. Most libraries take 3 minutes to do the initial install
so I'm not sure of the value of automating that step compared to adding
system checks.

Jacob you're right it's a bit of an inconvenience to write a class to wrap
django.conf.settings but I'm not sure there's any general purpose wrapper
that could be provided. There are too many cases for evolution - a setting
changes name, one value combines multiple settings, etc.


On Tue, 31 Dec 2019 at 00:09, Tom Forbes  wrote:

> My two cents: JSON isn’t great as a configuration language - It’s
> annoyingly picky about some things. YAML or TOML are “better” (for some
> definition of better) choices for this domain, in my option. However,
> Django is historically quite hesitant about including third party packages
> and I think including a TOML or YAML parser even as an optional dependency
> might not be the way forward.
>
> So rather than just “allowing people to use JSON files for settings” it
> would be very interesting to explore what a pluggable settings backend
> would look like. It seems that work in this area would be best spent on a
> general abstraction rather than a specific one. There was some discussion
> around this idea in the GSOC thread and I’m sure it’s come up before.
> Personally I think configuration management is an area of Django that is
> quite underdeveloped compared to other frameworks.
>
> On 30 Dec 2019, at 22:46, Christian González <
> christian.gonza...@nerdocs.at> wrote:
>
> Hello,
>
> I recently "finished" my first really working version of GDAPS, my
> Generic Django Application Plugin System. It's noway perfect, but does
> what it should: providing pluggable apps for an app framework, including
> a more or less flexible frontend with each django app.
>
> I had much struggle with it, and one of the lessons I learned was
> Django's setup system, and how it deals with loading apps. Unfortunately
> Django can't load/unload apps on the fly, so it is necessary to restart
> Django whenever a new GDAPS app is installed via pip.
>
> But: I want to resurrect an old theme again which would, in a way,
> improve some of the loading problems I encountered. Django's settings
> are code. Which is, in fact, a very good thing, as it makes it extremely
> flexible and adaptable to different setups. But, as discussed with the
> SECRET_KEY here, some of the settings _have_ to be coded very
> complicated, and it makes some things like per-app-settings extremely
> uncomfortable.
>
> What if - and please don't kill me instantly - yes, I am a newcomer, and
> not a good programmer maybe - but some things are viewed better from
> "outside" - what if Django settings could be "declarative"?
>
> So instead of Python code like
>
> INSTALLED_APPS = [
> 'django.contrib.admin',
> 'django.contrib.auth',
> 'django.contrib.contenttypes'
> ]
>
> This would be in an e.g. JSON file
>
> {
>
> "INSTALLED_APPS": [
> "django.contrib.admin",
> "django.contrib.auth",
> "django.contrib.contenttypes"
> ] ,
> ROOT_URLCONF: "fooproject.urls"
> }
>
> Django's settings.py would look different: It would load that
> settings.json file and set the appropriate values into local code - so
> this wouldn't make much difference.
>
> Except 2 things:
>
> 1. Apps could have (default) settings, and they could be merged MUCH
> easier. Things like namespaced classes that are overwriting values like
> DRF/graphene does, would be completely unnecessary. The main
> settings.json file could be the "last word" in the

Re: remove_stale_contenttypes doesn't remove entries for renamed apps.

[Adam Johnson]

Hi Gowtham

My Django ticket was closed
>

Please link to the ticket here.

May be we can add an optional kwarg to remove_stale_contenttypes command to
> remove all contenttypes that do not have a corresponding model in existing
> appsv
>

That sounds somewhat reasonable to me. I think there are more implications
for renaming an app pthough. Wouldn't it be better when renaming an app to
add a migration to update the existing ContentType rows to point to the new
names? Then existing rows with Generic Foreign Key should continue to work?

On Tue, 31 Dec 2019 at 07:11, gowtham kommineni 
wrote:

> Currently, it only removes content types in scenarios where you either
> rename a model or delete a model. If I rename an App from "app_label1" to
> "app_label2", it doesn't delete content types for "app_label1" and this is
> causing issues where I use ContentType as a GenericForeignKey.
>
> After I renamed an App and ran remove_stale_contenttypes, I had content
> types like the following:
> app_label1_Post
> app_label2_Post
> app_label1_Comment
> app_label2_Comment
>
>
> My Django ticket was closed saying "I don't think that
> `remove_stale_contenttypes` should remove content types for nonexistent
> apps. We don't automatically remove models for nonexistent apps and I
> don't think we should do this with content types. This can also cause a
> data loss for custom content types (not related to real apps)."
>
>
> May be we can add an optional kwarg to remove_stale_contenttypes command
> to remove all contenttypes that do not have a corresponding model in
> existing apps. That would allow us to use the standard command with that
> optional kwarg while allowing others to keep custom contenttypes. Can you
> please let me how we can add this functionality while respecting others
> using custom contenttypes.
>
> --
> 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/c306cc5d-4eeb-4324-b210-7017f9269293%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1NCQaf%3D0EP12DW9xn7h%3Dd%3DB-UBQ%2BzYeHucjH-5zk0vXQ%40mail.gmail.com.

Re: remove_stale_contenttypes doesn't remove entries for renamed apps.

[Adam Johnson]

Mariusz makes the point on the ticket that this can cause data loss for
custom content types, which is true.

This seems to be a fairly thorny problem to me since there are several
different data loss risks. Perhaps a documentation change would be the
easiest first step - one can always remove particular stale content types
in a data migration.

On Tue, 31 Dec 2019 at 14:20, gowtham kommineni 
wrote:

> Hi Adam
>
> Please link to the ticket here.
>>
>
> ticket: https://code.djangoproject.com/ticket/31123
> PR: https://github.com/django/django/pull/12257
>
> --
> 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/e27e1fd5-9ba9-4b9d-b9a0-f477fb353769%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0OVRURkJtq9-mXyUgzHWMdK2JxAVxrOJdsQmipuYkVyQ%40mail.gmail.com.

Re: declarative settings

[Adam Johnson]

>
> This seems a weird suggest, but when apps depend on another app it should
> be able to override settings for that dependency too (because it "uses"
> that app anyway).


It does seem weird to suggest. I haven't seen such a use case myself. Can
you describe in more detail?

For me, I can only imagine it would violate the "principle of least
astonishment" that if I had app A installed for some time, then installed
app B on top, app B would change the default or manually configured
settings of app A. I would prefer if app B complained (via system check)
that I had an incompatible app A configuration.

On Tue, 31 Dec 2019 at 18:10, Christian González <
christian.gonza...@nerdocs.at> wrote:

> Hi all,
>
> thanks for your fast response - it seems that this is not a "ah, forget
> it, boooring." theme.
> I'll try to answer all (for me) relevant things at once here - sorry to
> write such a huge mail.
> *@Adam Johnson:*
>
> * A class to read django.conf.settings and add defaults/other logic
> through properties - for example
> https://github.com/adamchainz/django-cors-headers/blob/31b9c2ef8a333a40f18081ffc1f1cba9fb34574d/src/corsheaders/conf.py
> . This has the benefit of easily providing defaults, complex logic such as
> deriving one value from multiple settings, and being read from settings at
> runtime rather than import time.
>
> This is a good approach too, but it's not namespaced automatically. And
> app settings can't provide and override settings from other apps. This
> seems a weird suggest, but when apps depend on another app it should be
> able to override settings for that dependency too (because it "uses" that
> app anyway).
>
>
> I am in favour of most libraries adding a single setting that controls
> them, like DRF has REST_FRAMEWORK. I know django-cors-headers doesn't
> implement the pattern but this is for legacy reasons since I took it over.
>
> Yes, this basically means namespacing. Depending on the size of the
> library, this could be one big bunch of a setting.
>
> I think this pattern solves your first concern Christian.
>
> No it doesn't completely. I used this pattern myself in GDAPS, copied from
> graphene (which copied from DRF). But this does _not_ solve the problem:
> This pattern  creates a per-app settings object which checks at the time of
> using (which is anywhere after main settings.py) if there is a global
> override of the local app's variable - and takes the right one. In this way
> it works. but this is not very convenient - you always have to ask the
> right settings object - it maybe would be more convenient, simpler and
> easier to code to just ask for a namespaced setting, e.g. in a dotted path
> style.
>
> like settings("django.ROOT_URLCONF") or settings("foo_app.SETTINGA")
>
> This is not a really good approach as it implements strings.
>
> As for your second concern, I think checks make manual installation of
> apps easier. If a user adds your app to INSTALLED_APPS, the system checks
> will run and can highlight any missing/misconfigured settings from
> following the installation docs. Most libraries take 3 minutes to do the
> initial install so I'm not sure of the value of automating that step
> compared to adding system checks.
>
> Perfect.
>
> *@Matthew Pava*
>
> I have worked with Drupal for a long time before Django, and am
> maintaining a few sites with Drupal, one of it rather big, with many
> domains & shared content, 40+ modules, API to ther web services, some
> modules custom coded. I learned a lot of it, but PHP is really ugly. Django
> does much better, but, compared with Drupal, it has a few drawbacks. I
> know, Drupal is a CMS, Django is a framework (which you can build a CMS
> with) - BUT: Drupal is able (like Wordpress) to add modules/plugins per web
> download and on-the-fly - it installs modules into place, has a very good
> hooks system and a plugin manager. It also was a help when I designed GDAPS
> and was one of my blueprints. Drupal however keeps ALL of it's settings in
> the database which creates many problems on it's own
> (development/deployment problems how to sync settings from disk to database
> and vice versa). I wouldn't do that. Settings in code/conf files is a good
> thing IMHO.
>
> The package manager in Drupal is composer, yes, and together with GDAPS,
> you could use GDAPS Django packages exactly the sameway. Just install it
> using pip/pipenv, and Dajngo/GDAPS finds them automatically.
>
> But this can only be achieved by adding a line to settings.py (call the
> plugin manager), like I did:
> https://gdaps.readthedocs.io/en/latest/Installation.html#install

Re: Potential performance related bug in django`s Queryset.get().

[Adam Johnson]

Hi Anudeep

Your change makes get() perform an extra query for count() before it . This
would be a regression for most uses of get().

get() is not intended for use "when multiple objects exists in very big
numbers". You may want to perform a single query, something like
Model.objects.filter(id__in=[1, 2, 3, 4, ...]) , and sort out your
duplicates in a loop in Python.

Hope that helps,

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/CAMyDDM0M%3DSXbrQVOWh2QDy%3DGLtuEYk_tQeMA4PXT%2BVKdEtAvMQ%40mail.gmail.com.

Re: remove_stale_contenttypes doesn't remove entries for renamed apps.

[Adam Johnson]

I guess an optional kwarg would be okay then.

On Thu, 2 Jan 2020 at 03:08, Javier Buzzi  wrote:

> @adam I agree with your points, about data loss, but this can still see
> this as being beneficial, perhaps the approach was just too harsh. Perhaps
> adding a flag in the management command would get everyone on board? The
> flag being off by default and only turns on if you know what you’re doing
> and enable it. At any rate i believe from what i can i see in the code it
> will still prompt you to delete the items it finds unless you added the
> ——no—input which prevents helps with data loss.
>
> --
> 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/5c55fdaa-8d89-4baa-a08d-68b0e84c610c%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3Hu_ZKWUj46%3D0BYN8XECG0OT_kMLNUgaopKXhJOEfJ5Q%40mail.gmail.com.

Re: Integrate Django with React

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for 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. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Fri, 3 Jan 2020 at 15:53, Santhosh sridhar 
wrote:

> Is there a way to integrate React JS framework with Django? How to do that?
> What is the advantage of using such frontend frameworks over normal ajax?
> Any help or explanation would be helpful. 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/f22996dc-be03-4c04-b10b-277579e37bbb%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3z1gMky9Wf8rdCF1u9ykYGVxDRWctsdcH%3DYi-hHfD-5w%40mail.gmail.com.

Re: Extent of async integration into 3.0

[Adam Johnson]

Hi Jure

Andrew laid out the general plan in DEP 0009:
https://github.com/django/deps/blob/master/accepted/0009-async.rst

I think this answers all your questions, for example:

WebSocket support will not be in Django itself; instead, we will make sure
> that Channels has all the hooks it needs to integrate cleanly and take over
> the ASGI root app location so it can handle WebSockets itself.
>

Thanks,
Adam


On Tue, 7 Jan 2020 at 12:54, Jure Erznožnik 
wrote:

> I've been monitoring this list for a bit, enough to see that 3.x is now
> moving in the async direction.
>
> Is there a roadmap as to where we want to get with this direction?
>
>
> Or, to ask more directly:
>
> I have been looking into django-channels for a while in order to start
> catering for ever-increasing demands for more and more responsiveness in
> my apps. Basically I see django-channels as a good approach at getting
> the server to actually PUSH information to the clients. I sure hope I'm
> not just wishful here, but that's how I understood this particular facet
> of the project. There are some other things I also see quite appealing
> in there.
>
> Anyway, I understood that django-channels was a project just a tad too
> big to simply be integrated into Django, but was heavily supported by
> django core team?
>
> OTOH I fear that with core django moving towards async will make
> django-channels either hard to maintain or outright obsolete.
>
> So, to finally arrive at the question: is the async action I have been
> seeing going anywhere near where django-channels is today or is it a
> completely separate effort? If the latter, what's the future outlook for
> django-channels?
>
>
> I sure hope I'm asking this in the right mailing list.
>
>
> Thanks,
> Jure
>
> --
> 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/ceac365f-70a0-2b1f-de6a-9cb171df4a79%40gmail.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/CAMyDDM3hRsYYtjqweTROr5vTFy591inrA1%2BbF-a_VM_d0_5ziQ%40mail.gmail.com.

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

[Adam Johnson]

Hi Santiago

There are any kinds of queries that can be slow in Django. ORDER BY
RANDOM() will be just as slow on large tables as ORDER BY
some_unindexed_column, or many other SQL constructs.

Django can't predict well how expensive a query will be - that's the job of
the database's optimizer. It varies on many factors that only the database
server knows - table size, index size, column histograms, etc.

I therefore don't think such a warning would be very accurate or useful.

(Also, just as documentation can be missed, so too can warnings.)

Thanks,

Adam

On Fri, 10 Jan 2020 at 15:14, 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/fe948733-7767-4688-b89a-43fa57153905%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3bpFfk48HBMy%2BvjZJ_6v-jKB2xhtvtoe%3DjMh_SttjyqQ%40mail.gmail.com.

Re: Django3.0 / async - use cases

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for 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. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Mon, 13 Jan 2020 at 17:22, Vitaliy Kucherivaiy 
wrote:

> Hi Everyone,
>
>
> In Django 3.0  we have Asynchronous support
> But where and how to have any benefit from it at this point ?
> (as according to docs views/middlewares/ORM does not support it)
>
> do you have any practical/useful example where async can benefit now ?
>
> ~Vitaliy
>
> --
> 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/103a07ef-3d2c-4220-8bed-d97eb4438c72%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0DR_6WiLpaJefZcunmZamZovJ9gU%2By1UJJuoX%2BHBrzOQ%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

[Adam Johnson]

Agree with Tom here.

Is there anything we can do to control the way python displays them?

And how would we ensure the format is kept going forwards? Is there a
flake8 rule/plugin we could activate to enforce it?

On Sat, 18 Jan 2020 at 10:23, Tom Forbes  wrote:

> I agree with this change from a correctness standpoint but I would like to
> make the point that chained exceptions might be slightly annoying when
> displayed via console output, as you see the inner exception first and have
> to scroll up to see the exception you actually have to handle.
>
> Tom
>
> On 18 Jan 2020, at 09:55, Ram Rachum  wrote:
>
> 
>
> Hi guys,
>
> I recently made a big ticket/PR to Django, and Shai Berger told me I
> should first talk about it in this mailing list.
>
> This is the ticket: https://code.djangoproject.com/ticket/31177 and its
> PR: https://github.com/django/django/pull/12339
>
> It's a generalization of this ticket that I opened and wrote a patch for a
> few days ago: https://code.djangoproject.com/ticket/31166 It was
> discussed and merged.
>
> Basically, I think that in any place where we catch an exception, and then
> wrap it with our own exception for whatever reason, we should use the
> "raise new_exception from old_exception" syntax rather than just "raise
> new_exception".
>
> This means that when Python displays the stacktrace (and when we display
> it in the debug page,) this will make it have a text of "this exception is
> the direct result of" instead of "During handling of the above exception,
> another exception occurred". This is more accurate, because the latter
> basically means "there was an error in the process of error-handling,"
> which is absolutely not the case for us, and could mislead a user.
>
> Note that we already started transitioning to "raise from", slowly:
>  - Commit by Mariusz Felisiak:
> https://github.com/django/django/commit/84dcd1624784c2239f96a97b3151145a85dfbbe3
>  - Commit by Diederik van der Boor:
> https://github.com/django/django/commit/25f21bd2376603c8e233a0a0e5a726a0fdfdd33e
>  - Commit by Thomas Allison:
> https://github.com/django/django/commit/3e8b7333904f1ab6aa18eeb508659256f3644816
>
> What do you think?
>
>
> Thanks,
> Ram.
>
> --
> 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/25086cdc-24ab-4f0a-bdb9-9756551ac170%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/74BA6A05-D971-47EF-A0B6-4EF1149E83E6%40tomforb.es
> 
> .
>
-- 
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/CAMyDDM0x0L%2Ba_r_gGL80qL3eqwMS4OV3%3Du-Hc0Wj3N1ruyQfuA%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

[Adam Johnson]

>
> I would like to make the point that chained exceptions might be slightly
> annoying when displayed via console output, as you see the inner exception
> first and have to scroll up to see the exception you actually have to
> handle.


Just coming back to this, Tom it's not quite true. Yes you see the "inner"
exception first - meaning the one raised inside the 'except' block. But
that is the one you, as a user, have to handle. This is not a concern for
me.

I checked with a simple program that Python prints them in the same order
and format whether or not "raise ... from" is used on the inner. The only
change is the message reads "The above exception was the direct cause of
the following exception:" which is pretty clear I think.

On Sat, 18 Jan 2020 at 15:18, Ram Rachum  wrote:

>
>
> On Sat, Jan 18, 2020 at 5:05 PM Shai Berger  wrote:
>
>> [snip]
>
> But as it turns out, `from` puts the
>> original exception on the `__cause__` in *addition* to `__context__`:
>>
>> [snip]
>> So that is not a concern.
>>
>
> Awesome! I did not know that.
>
>
>
>> > Regarding automatically enforcing this format going forward: I looked
>> > at the list of Flake8 rules  and
>> > couldn't find anything about it.
>> >
>>
>> Indeed, I don't think there can be -- it cannot be a style violation to
>> run into an error while handling another error...
>>
>
> I think it can be, as it's very rare to have a legitimate exception
> without a "raise from" inside an except clause. In almost any context in
> which "during handling of..." is correct, the raising is done deeper in the
> stack.
>
> I think it's rare enough that personally, I would have liked to have a
> Flake8 / PyLint rule like that enforces it, and allow ignoring it with a
> comment. (As much as I hate Lint ignore comments.)
>
> --
> 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/CANXboVYxb%2BMeOHp%3De4gzqroKWkHzLjeGXy55qJyRLQQVcUPrWg%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/CAMyDDM0%2BcpfiqFs3X9Kw9g%3D7444JahSjGBCa%2B2piSm71g_%3D12g%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

[Adam Johnson]

Nice work Jon. I don't think we can generally apply R100 though - thre are
definitely cases where "raise" inside an exception handler is not *caused*
by the other exception - but maybe that's a sign refactoring is needed.

On Sun, 19 Jan 2020 at 22:52, Jon Dufresne  wrote:

>
> > I think it's rare enough that personally, I would have liked to have a
>> > Flake8 / PyLint rule like that enforces it, and allow ignoring it
>> > with a comment. (As much as I hate Lint ignore comments.)
>>
>> That makes sense. And you know, flake8 supports plugins... a couple of
>> web searches and "pip search flake8 | grep {raise,from,chain}" didn't
>> pull anything which seems relevant, but if so, it can be written.
>>
>
> As a weekend project, I wrote a flake8 plugin to handle this at:
> https://pypi.org/project/flake8-raise/
>
> I'm not advocating this necessarily included by the Django test suite, but
> it can be used to review the PR. Either way, it was fun to write.
>
> --
> 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/CADhq2b4m40efQkorgji9-erXri9qSAb1VJBv%3DZ3HrOL6ksOJAQ%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/CAMyDDM0c3J%2BRGZZB%3D-Er3fAYnyvptkwu34CaO%2BmA%2BmKPKTEYPw%40mail.gmail.com.

Re: Keep https://code.djangoproject.com/ login

[Adam Johnson]

Please file this as an issue at
https://github.com/django/djangoproject.com/issues

‪On Fri, 24 Jan 2020 at 07:35, ‫אורי‬‎  wrote:‬

> Django developers,
>
> https://code.djangoproject.com/ logs me out after about 24 hours, and
> each time I have to login again (with GitHub). Why doesn't it keep me
> logged in as long as I'm logged in with GitHub? This is a harass and I
> think this week I already logged in a few times.
>
> אורי
> 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/CABD5YeGqEndbYc4nrt5LU9E448%3Di4s0iuPgrD0GG13w3SKa2wQ%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/CAMyDDM2RAiQYs-pXFMFZr%3D%3DPh%3DJNO5cpbM1G_4ZMg6_TB-Anbw%40mail.gmail.com.

Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[Adam Johnson]

Exactly as you see, nothing is done in secret.

On Fri, 24 Jan 2020 at 08:44, LBris  wrote:

> Hi everyone.
>
>
> What is the state of this discussion and its attached ticket ?
>
> --
> 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/47517107-c5d2-4986-8845-087cba05e340%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM26g9LG49K7S5gPzOA-vS%2B6rUnPipt6iQv0qwYLvgMM2A%40mail.gmail.com.

Re: Keep https://code.djangoproject.com/ login

[Adam Johnson]

 of dependencies but not
> getting how to solve this
>
> please respond , I'm not able to sort out this problem ...
>
> Thank You …
>
>
> On 24-Jan-2020, at 2:09 PM, Adam Johnson  wrote:
>
> Please file this as an issue at
> https://github.com/django/djangoproject.com/issues
>
> ‪On Fri, 24 Jan 2020 at 07:35, ‫אורי‬‎  wrote:‬
>
>> Django developers,
>>
>> https://code.djangoproject.com/ logs me out after about 24 hours, and
>> each time I have to login again (with GitHub). Why doesn't it keep me
>> logged in as long as I'm logged in with GitHub? This is a harass and I
>> think this week I already logged in a few times.
>>
>> אורי
>> 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/CABD5YeGqEndbYc4nrt5LU9E448%3Di4s0iuPgrD0GG13w3SKa2wQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CABD5YeGqEndbYc4nrt5LU9E448%3Di4s0iuPgrD0GG13w3SKa2wQ%40mail.gmail.com?utm_medium=email&utm_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/CAMyDDM2RAiQYs-pXFMFZr%3D%3DPh%3DJNO5cpbM1G_4ZMg6_TB-Anbw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM2RAiQYs-pXFMFZr%3D%3DPh%3DJNO5cpbM1G_4ZMg6_TB-Anbw%40mail.gmail.com?utm_medium=email&utm_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/CC763127-1DB0-48C2-BE27-256AC02BF205%40gmail.com
> <https://groups.google.com/d/msgid/django-developers/CC763127-1DB0-48C2-BE27-256AC02BF205%40gmail.com?utm_medium=email&utm_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/CAMyDDM2UvPnqkk8NLPx%3D4vwUXDsaFrU9EWgNfmvXGYNshpTHww%40mail.gmail.com.

Re: Error with running test suite while contributing to django

[Adam Johnson]

Please don’t repost on the mailing list, I responded on the other thread

On Fri, 24 Jan 2020 at 11:41, Muhammed abdul Quadir owais <
quadirowais2...@gmail.com> wrote:

> Hi ,
>
> I want help over here ,..
> I'm a newbie for django contributions so I got stuck over here...
> After cloning the django from git hub ( obviously after the action of
> fork) and running commands (like $ python -m pip install -e
> /path/to/your/local/clone/django/
> and $ python -m pip install -r requirements/py3.txt (no errors here) then
> ,..
> then after cd to tests then running this command ./runtests.py
> )
> the test here is giving as response..
>
> ss...sss..s..ss..sss..s.s..s...s.s...s.s..s..ss..s...sss...s.ssss.s..s.s.s.sss..s..s..s.s......s..s...ss...x...s.x.sss.s...s...s.s...s..ss..

Re: extension for arangodb

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for 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. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Wed, 29 Jan 2020 at 06:37, hh am  wrote:

> hello
> i want to write an extension for add arangodb as database how should i do
> 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/7ddf9a0b-2016-48e9-a5de-f446f0cba291%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2vT5sYeB4bDyK0KRe0nXLiuPPM%3Da5TbOZR2xWXvE5yDg%40mail.gmail.com.

Re: extension for arangodb

[Adam Johnson]

It would be normal to write this as a third party package first, and only
when it shows wide community interest would it be considered for inclusion
in the django project itself, via a DEP: https://github.com/django/deps

On Wed, 29 Jan 2020 at 18:35, hh am  wrote:

> i dont want to write a project i want to write a extension for django
> project itself to add arangodb support
>
> --
> 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/f989638c-ae1a-45ea-8f8b-b72709c033b7%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1MiQHZ02N_HJAzkD7BPROd2AWKCY%3Dh8rG9L7o58SkEfw%40mail.gmail.com.

Re: "s" duplicados

[Adam Johnson]

Hi

This mailing list is in English and is not the correct forum for bug
reports.

Also there is no bug - you probably have a model called "Clientes" that is
being "pluralized" by Django, adding "s". Set verbose_name_plural to
control this:
https://docs.djangoproject.com/en/3.0/ref/models/options/#verbose-name-plural

Thanks,

Adam

On Sat, 1 Feb 2020 at 17:52, Izaias de Oliveira Elias 
wrote:

> Boa tarde a todos venho aqui comunicar oque me parece um bug.
> Bom quando crio um app no django e voou a area de administrador, sempre no
> final do nome do app aparece dois "ss"
> segue screenshots;
>
> --
> 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/9310ce02-1a0d-4f05-95d5-96d434a503b2%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2jhd-OaiL5dT4Td1pAi%3DJj4XcRxU_obmrifSXBJK_2gg%40mail.gmail.com.

Re: Autoincrement primary key in mysql not working in case of django.when i insert data how to i to solve it..

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for 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. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Sun, 2 Feb 2020 at 05:36, coder kptech  wrote:

> hello Dear django develpers.
> Autoincrement  primary key in mysql not working  in case of django.when i
> insert data how to i to solve it..
> Alwayes my data are overriding to the itself, not store the data  uniq in
> data base..
> please solve my errors.
>
> --
> 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/8b999f99-f965-4011-984a-f1c6ecc21e57%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2jGGnRBc%3D4Cg4bDASMQ9_nmJHJo78w6WVGjyifOQ1KvQ%40mail.gmail.com.

Re: About contributing to django...

[Adam Johnson]

Hi Xero,

There have been a few email threads about this previously, with links to
the relevant locations:

https://groups.google.com/d/msgid/django-developers/af075d59-ece3-4044-9204-b690c746b9e0%40googlegroups.com

https://groups.google.com/d/msgid/django-developers/3d87d5a8-ab76-45a7-ab28-b8a6501fce7d%40googlegroups.com

Hope these help as a starting point,

Adam

On Sun, 2 Feb 2020 at 18:09, XERO  wrote:

> hello everybody!
> I am computer science student, studying in second year.I am novice in this
> sector.I have been going through the documentation,readme etc. from last
> few days (done some basic projects like to-do web-app,calculator etc.) but
> not actually understanding the flow properly.I am participating gsoc
> competition this year and would like to contribute here(very
> desperate..).Can someone help me with the same :|
>
> --
> 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/90574ec0-6b59-4fdd-ad8f-1f80e3a50233%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1wMthTHyVWiQRqBvD7_bAsQcNQ2drPckgLTNWT1pgCVw%40mail.gmail.com.

Re: Where to post to ask questions about solving a Django ticket

[Adam Johnson]

Post here

On Mon, 3 Feb 2020 at 16:58, Ahmad A. Hussein 
wrote:

> I'm currently stuck on solving a Django ticket I assigned to myself, and I
> don't know where to post to ask for help/feedback.
> Should I post here or ask someone on the #django IRC channel or should I
> make a post on the django project forums?
>
> --
> 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/9d3b5148-4303-4453-bbd0-eb574432968a%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2wq3xpchwMq9GB6c07vWQgcOVXhXjJ2Ncr4yfBQ8pNOg%40mail.gmail.com.

Re: recurring slot booking/reservation code

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for 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. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Mon, 3 Feb 2020 at 18:31, Siddhartha Satyakama 
wrote:

> I'm looking for a code to see models,forms,views for creating recurring
> slot booking app without any external module everything from scratch.
> Please help how should I start??
> Suppose if i want to block calender dates if booked how should I do it?
>
> P.S. I'm new to Django so please 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/CADK5jRMuMBJiXsUohAHJJ298AcvL1_WuvvzAUz6WoYOkds%3Dmhg%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/CAMyDDM197aq5G5mAx7HfVx%2B9RuQRJfrUi_V6E9KeauHyM4ZeOw%40mail.gmail.com.

Re: Enhancement to assertQuerysetEqual

[Adam Johnson]

Seems reasonable to me. I would certainly read `assertQuerysetEqual(qs1,
qs2)` as checking they contain the same items.

On Tue, 4 Feb 2020 at 16:34, Peter Inglesby 
wrote:

> Hi folks,
>
> I always find the behaviour of assertQuerysetEqual surprising,
> particularly when I pass it two querysets that I expect to be the same, or
> when the second argument is a list of model instances.
>
> Under the covers, assertQuerysetEqual(xs, ys) is roughly equivalent to
> assert [repr(x) for x in xs] == ys, and an optional transform parameter can
> be passed in to be used instead of repr().
>
> So assertQuerysetEqual(qs1, qs2) is never going to do the right thing and
> there's always ten seconds of head scratching while I look at something
> like:
>
> AssertionError: Lists differ: ['', ' 481481101108>'] != [, ]
>
> I know that I can use assertCountEqual from the standard library, and I
> think at the very minimum this should be mentioned in the docs for
> assertQuerysetEqual.
>
> However, I'd like to go further and propose a change to
> assertQuerysetEqual so that if no transform argument is passed, and the
> second argument is not a list of strings, then transform is set to the
> identity function.
>
> As far as I can tell, this would not introduce a meaningful backwards
> incompatibility.
>
> I'm willing to do the work to add code and documentation etc.
>
> All the best,
>
> Peter.
>
> --
> 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/CAENJrPkCNwH5LEG-OnhmcmkEB0mULgf_LjmFkATZ0ENcSQk_Hw%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/CAMyDDM2ibFA%3DMY-VE47B-wpxo6jqUWuv%2Bv-3qzGvi2tfiLticA%40mail.gmail.com.

Re: Beginner-friendly issue to start contributing to codebase

[Adam Johnson]

Hi Vibhu

Thank you for your documentation improvements. There are certainly many
more bigger improvements that can be made. For similar small typo fixes in
the future, you can just directly submit a PR rather than do all the
paperwork of adding an issue.

Yes, "easy pickings" tickets get resolved fairly rapidly. There are many
eyeballs looking out for such issues. As fran says, you can look for older
issues on which work seems to have frozen. But beware - the older the
issue, the harder it likely is to be!

Thanks,

Adam

On Thu, 6 Feb 2020 at 01:01, Fran Hrženjak  wrote:

> Just a quick note: issues that have an owner but weren’t updated in a
> reasonably long time are usually open for taking. It is probably polite to
> ask the owner first, because maybe they just resumed working on the issue
> yesterday :) What is “reasonably long time” is probably open to
> interpretation, but I’d say anything that is counted in years has to be
> fair game.
>
> I’m wondering if it would make sense to have such tickets automatically
> unassigned...
>
>
>
>
> On Thu, Feb 6, 2020 at 1:41 AM Vibhu Agarwal 
> wrote:
>
>> Hi! I'm Vibhu, currently an undergraduate.
>> I've been working with Django for over a year now.
>> And for a long time, I've been wanting to contribute to Django as well.
>>
>> So I followed a few links shared repeatedly in the mailing list, like:
>> -
>> https://docs.djangoproject.com/en/3.0/internals/contributing/new-contributors/
>> - https://docs.djangoproject.com/en/dev/internals/contributing/
>>
>> Through those, I followed other links and thoroughly read the guides like:
>> "Reporting bugs and requesting features", "Triaging tickets", "Submitting
>> patches" and "Writing your first patch for Django"
>>
>> I even tried to get familiar with the process through #31222
>>  and #31226
>>  and looked through some
>> closed PRs as well.
>> Then I tried to find 'easy pickings' which are directly related to the
>> codebase, but I couldn't find any which is new or un-assigned.
>>
>> I just need to get started with understanding the codebase and its
>> structure.
>> If anyone could help me look for an issue which involves writing tests or
>> changing code in any way, it would be great.
>> Any beginner-friendly issue will do.
>>
>> --
>> 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/8489e521-d8b4-44b3-9569-3068dd14256d%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/CAM2o%3DwNBkdPV89JOoCizeKzOG%3D8uarHAnU8FbH08TA_v2L2y9w%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/CAMyDDM1O8tyV3GEW5ir5h76k-g5iL7h3kRoFhPScPxNzs0kcgQ%40mail.gmail.com.

Re: CrossDB JSONField — Testing needed.

[Adam Johnson]

Thanks for your testing!

It's being passed through json.dumps to check it would be possible to store
it as JSON. Seems legitimate to me.

The other libraries default to an encoder that allows storage of Decimals,
whilst the new field doesn't. Since Decimals don't round-trip in JSON
(they're encoded as strings and then decoded back as strings), I think the
new JSONField is making the right choice here.

On Thu, 6 Feb 2020 at 06:35, Jacob Rief  wrote:

> Hi Carlton, hi Sage,
> I just tested this implementation against my JSONField form editor
> library, namely django-entangled
> , using SQLIte.
> As you can see from the testing matrix
> , everything works fine
> using the well known jsonfield  and
> jsonfield2 , which until Django-3
> are the only viable options currently available for SQLite.
>
> However, after switching to the new implementation using the built-in
> JSONField, one of my units tests does not pass
> . After
> examining this locally, I discovered, that the form
> reports product_form._errors: {'properties': ['Value must be valid
> JSON.']}
> The location where this exception is raised, is inside the JSONField's
> validate()
> 
>  method.
> And the reason it is raised
> is because json.dumps(value, cls=self.encoder) can not reparse a valid
> dictionary containing for instance a Python Decimal value.
> Why should a valid Python dictionary be json.dumps(value,
> cls=self.encoder) anyway?
>
> – 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/02f0df5e-3d9d-49c4-a81a-a1a2261a1b98%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM13toc2jrRm7eg6GSAGR2xmVgeoX8dkaoxTRytjesf0bw%40mail.gmail.com.

Re: Adding support for SQL Server

[Adam Johnson]

Microsoft posted in 2015 and there was an update last April about a working
backend that claims support for 3.0:
https://groups.google.com/d/msg/django-developers/FbBcUCzrSZo/EoFNbR2BDgAJ

Any support in core would need clear evidence of widespread demand. I don't
think there's much demand - e.g. that backend has only 38 stars on GitHub.

On Wed, 12 Feb 2020 at 20:33, Martynas Puronas  wrote:

> Hey, I've been working on adding support for SQL Server to Django, since
> the package currently being linked recommended in Django's documentation
> has been abandoned (as well as a few others seem to be either abandoned or
> do not have the test suite passing), and I have made some significant
> progress on it (all of admin tests are passing, as well as aggregates,
> inserts, deletes, updates and a few other modules). I was wondering if you
> would be open to adding support for SQL Server, provided I could make sure
> that the entire test suite passes, and documentation is written? Or does
> this go against Django's technical roadmap and you would rather keep
> support for SQL Server outside of Django in a separate package?
>
> 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/6d98459d-9616-4343-b4fe-3eabd9ef131f%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2hna%2B%3D%3DPuHKjH0xzJmEGzReDP3DFyJwX2L2bt%3DtsR97Q%40mail.gmail.com.

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

[Adam Johnson]

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-developers+unsubscr...@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 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/CAMyDDM3-F2%3DBC4bGqiMpf2cG5F47Hn217DgV3YaVGc%2BK9_VWAg%40mail.gmail.com.

Re: Improve migration conflict detection

[Adam Johnson]

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 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/31d78cfc-05bc-4bee-897b-3d9e2e502a3d%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2x4bYT1mAVmqj3HT9s8H2zZpO17JTMVMv7MEUfnXB3Mg%40mail.gmail.com.

Re: [Feature Request] Option to implicitly create tables within a database schema based on their model's app

[Adam Johnson]

Schema support is this 12 year old ticket:
https://code.djangoproject.com/ticket/6148

On Sun, 16 Feb 2020 at 20:02, Matt del Valle  wrote:

> EDIT:
>
> Actually, after some further digging it turns out it's worse than I
> thought. Unless I'm missing something it looks like there currently isn't
> any non-hacky way at all to set a table's schema in django. There are
> workarounds that involve SQL escaping hacks such as setting a model's
> db_name to 'some_schema\".\"some_table' (notice the escaped double quotes)
> that *may sometimes *work in some backends but not others and can
> probably break without warning as django updates.
>
> I suppose then this request is maybe more generically just "Support DB
> schemas in django"
>
> --
> 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/0e12e617-ce90-4541-a769-4eb2408049e4%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1tWkb5gOP22CzqOAQ2_TRwioJ55N-aE4Bj6ysFuqZqEA%40mail.gmail.com.

Re: Rename salt to mask in CSRF

[Adam Johnson]

The wikipedia page says:

In cryptography, a salt is random data that is used as an additional input
> to a one-way function that hashes data, a password or passphrase. Salts are
> used to safeguard passwords in storage.


Ram is right - this variable is not a salt in that definition. We aren't
using a one-way hash function, but a reversible rotational cipher function.
The 'salt' is really the key/mask/one-time-pad to that cipher function.

I think "mask" and "unmask" are more correct terms to use in the code and
docstrings. Not sure if it's worth the effort to change though


On Wed, 19 Feb 2020 at 06:39, Matemática A3K 
wrote:

>
>
> On Tue, Feb 18, 2020 at 3:31 AM Ram Rachum  wrote:
>
>> Hi guys,
>>
>> Recently I was working with Django's CSRF protection, customizing it to
>> my needs, and discussing with co-workers exactly how it works and how it
>> has protection against the BREACH attack being used to retrieve the CSRF
>> key.
>>
>
> https://github.com/django/django/pull/11919#issuecomment-549000592
>
>
>> Relevant code here:
>> https://github.com/django/django/blob/master/django/middleware/csrf.py#L45
>>
>> One point of confusion is the use of the term salt in Django's source
>> code. People expect salt to mean the same as salt in the database, that
>> works quite differently and doesn't mask the actual secret.
>>
>> I'm not a security expert so I may be wrong, but I think that "One-time
>> pad", "XOR mask" or just "mask" would be more accurate terms.
>>
>> I propose to change the "salt" to "mask" everywhere these terms appear in
>> the CSRF code, and similarly "unsalt" to "unmask". As far as I know this
>> wouldn't affect functionality at all, because the term "salt" doesn't
>> appear in actual tokens.
>>
>> What do you think?
>>
>
> I think the term is accurate in the domain -
> https://en.wikipedia.org/wiki/Salt_(cryptography) - no need to rename it.
>
>
>>
>> Ram.
>>
>> --
>> 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/3cf02beb-e292-4991-b75e-2f3f6e28d371%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/CA%2BFDnhKZdF2QbSy9cL643t9eugzHm6GMaeXtxFVCgHEvYHJwSQ%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/CAMyDDM1Q8zicOH_PvZcSsXGM1fjhVZ2Yq5K6%3D6JT43XG5zqu1Q%40mail.gmail.com.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Adam Johnson]

I made a ticket for this: https://code.djangoproject.com/ticket/31287

On Fri, 23 Feb 2018 at 08:53, Kamil  wrote:

> The name "mark_safe" unnecessarily exposes an implementation detail.
> People who misunderstand this API probably have no idea how this "marking"
> happens, it would make sense to name this after the *effect* it achieves:
> "don't process / escape me, I've been sanitized somewhere else".
> Any of these would work: "no_escape", "dontescape", "sanitized_elsewhere",
> etc.
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/268807b1-cfdf-4bf8-9c02-6e954bfa30e1%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
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/CAMyDDM2qRQYcxKrhN-_n5Quqy-GTRK-1AQeiYGNPMC6Lt5PTDg%40mail.gmail.com.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Adam Johnson]

Sorry I was a bit keen after a reminder of the thread by Josh Smeaton on
reddit. I skimmed again and it felt like there was consensus on some kind
of rename, and it had moved to decision on the name. I guess I'm also sick
of fixing this in client projects :)

I think your concerns are fair and well-reasoned as always Carlton. You've
convinced me this isn't worth it.

I'd love to see a bleach "battery" too. Was not aware of html5lib going
unmaintained - it does highlight that there's a lot to do elsewhere in the
ecosystem.

On Wed, 19 Feb 2020 at 14:20, Carlton Gibson 
wrote:

> I've just closed the ticket as wontfix, because I'm not seeing a consensus
> for the change here. I'm seeing a few Yeahs and a few Mehs.
> That doesn't mean we can't have it, but the procedure is generally agree
> here before a ticket.
> So can I ask, those wanting this, to make the case here, then we can
> re-open the ticket if there is a general agreement.
>
> 
> FWIW I'm not convinced. The warnings on the mark_safe() docs are pretty
> clear cut.
> I think users will just use whatever gets their content on the screen,
> probably knowing it's not safe, but telling themselves
> that they'll come back later. Change the names and that will still be the
> same.
> There'll just have been a massive load of busywork in between.
>
> Ideally we'd just ship Bleach &co. That's a battery we could include.
> But we can't really do that, because html5lib is unmaintained, and there's
> no alternative.
> Whatever effort there is to be spent on this, I'd rather see it spent
> there.
> 
>
> Kind Regards,
>
> Carlton
>
>
> On Wednesday, 19 February 2020 10:11:11 UTC+1, Adam Johnson wrote:
>>
>> I made a ticket for this: https://code.djangoproject.com/ticket/31287
>>
> --
> 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/aa60f3b6-0ace-45fc-9698-6b54e317e091%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/aa60f3b6-0ace-45fc-9698-6b54e317e091%40googlegroups.com?utm_medium=email&utm_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/CAMyDDM091w46Pt%3DkiAbU5qgTxOj-_BE5hqz7qZeNNBGkG-RX_A%40mail.gmail.com.

Re: Rename salt to mask in CSRF

[Adam Johnson]

I guess it's not a very big change so could be worth it to increase
readability.

On Wed, 19 Feb 2020 at 16:12, Ram Rachum  wrote:

> In any case, if it's decided that it's a worthwhile change, I'll be happy
> to make the patch.
>
> On Wed, Feb 19, 2020 at 10:31 AM Adam Johnson  wrote:
>
>> The wikipedia page says:
>>
>> In cryptography, a salt is random data that is used as an additional
>>> input to a one-way function that hashes data, a password or passphrase.
>>> Salts are used to safeguard passwords in storage.
>>
>>
>> Ram is right - this variable is not a salt in that definition. We aren't
>> using a one-way hash function, but a reversible rotational cipher function.
>> The 'salt' is really the key/mask/one-time-pad to that cipher function.
>>
>> I think "mask" and "unmask" are more correct terms to use in the code and
>> docstrings. Not sure if it's worth the effort to change though
>>
>>
>> On Wed, 19 Feb 2020 at 06:39, Matemática A3K 
>> wrote:
>>
>>>
>>>
>>> On Tue, Feb 18, 2020 at 3:31 AM Ram Rachum  wrote:
>>>
>>>> Hi guys,
>>>>
>>>> Recently I was working with Django's CSRF protection, customizing it to
>>>> my needs, and discussing with co-workers exactly how it works and how it
>>>> has protection against the BREACH attack being used to retrieve the CSRF
>>>> key.
>>>>
>>>
>>> https://github.com/django/django/pull/11919#issuecomment-549000592
>>>
>>>
>>>> Relevant code here:
>>>> https://github.com/django/django/blob/master/django/middleware/csrf.py#L45
>>>>
>>>> One point of confusion is the use of the term salt in Django's source
>>>> code. People expect salt to mean the same as salt in the database, that
>>>> works quite differently and doesn't mask the actual secret.
>>>>
>>>> I'm not a security expert so I may be wrong, but I think that "One-time
>>>> pad", "XOR mask" or just "mask" would be more accurate terms.
>>>>
>>>> I propose to change the "salt" to "mask" everywhere these terms appear
>>>> in the CSRF code, and similarly "unsalt" to "unmask". As far as I know this
>>>> wouldn't affect functionality at all, because the term "salt" doesn't
>>>> appear in actual tokens.
>>>>
>>>> What do you think?
>>>>
>>>
>>> I think the term is accurate in the domain -
>>> https://en.wikipedia.org/wiki/Salt_(cryptography) - no need to rename
>>> it.
>>>
>>>
>>>>
>>>> Ram.
>>>>
>>>> --
>>>> 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/3cf02beb-e292-4991-b75e-2f3f6e28d371%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/django-developers/3cf02beb-e292-4991-b75e-2f3f6e28d371%40googlegroups.com?utm_medium=email&utm_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/CA%2BFDnhKZdF2QbSy9cL643t9eugzHm6GMaeXtxFVCgHEvYHJwSQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/django-developers/CA%2BFDnhKZdF2QbSy9cL643t9eugzHm6GMaeXtxFVCgHEvYHJwSQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> --
>> 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/SokWmLcIkds/unsubscribe
>> .
>> To unsubscribe from this group

Re: Property-based "fuzzy" testing (Hypothesis) in Django

[Adam Johnson]

Hi Elena,

I like fuzz testing and how Hypothesis does it. I have used it on a couple
of projects and it always found bugs. In fact it was my first Pycon that I
sat with David and sprinted on adding it to a project :)

That said I've always found it quite a leap from straightforward tests,
being slower and non-deterministic. There is a hard balance to make writing
fuzz tests versus writing individual test cases to ensure edge cases keep
being covered. And also we generally want tests to be less complex than the
code they are testing - short functions with several parameters can easily
need many lines of hypothesis code to set up accurate testing.

Personally I tend to settle on using a little bit of fuzzing with random
data from factory boy, but adding control to the random seed used in
testing using pytest-randomly. I gave this approach a bit of a write up
when I started using it in 2014:
https://adamj.eu/tech/2014/09/03/factory-boy-fun/ .

As for Django's test sutie: I don't believe there is any fuzz testing
there. But it is being tested separately instead with Google's OSS-Fuzz
project: https://github.com/google/oss-fuzz/tree/master/projects/django .
This was set up by Guido Vranken who announced it in this mailing list
thread:
https://groups.google.com/forum/#!topic/django-developers/-WweB07YiVQ .
Apparently it has caught a few bugs since implementation, and there's scope
to expand it quite a lot:
https://groups.google.com/d/msg/django-developers/PMtvmMlsjyw/_rOj_LzvCQAJ
. I *think* if we were to increase our fuzz testing, we'd probably want to
concentrate efforts there. Google also offer $ rewards to critical projects
like Django for reaching certain levels of coverage, which is nice of them.

Thanks,

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/CAMyDDM2%2Bbz%2BwVgiZiVG7YijwO0zzxZcfVE%3Dpxmcper7D3iUJQg%40mail.gmail.com.

Re: help For GSoC Proposal (Improve Admin Filters)

[Adam Johnson]

Hi both,

Have you seen:

* The wiki page: https://code.djangoproject.com/wiki/SummerOfCode2020
* Recent responses on the mailing list on GSoc (search it) e.g.
https://groups.google.com/d/msg/django-core-mentorship/_GO8rLu881k/V6mYQKmMCAAJ

Keshav: you made a great first PR. Searching for other issues around the
admin would be a good approach. If you haven't developed your own site
using the Django admin, that would also be worth it. You could start with
the official tutorial and expand from there. Also worth investigating the
popular third party admin packages, some of which have filter extensions:
https://djangopackages.org/grids/g/admin-interface/

Thanks,

Adam

On Mon, 24 Feb 2020 at 11:53, Bryan Andia Llerena <
bryanandialler...@gmail.com> wrote:

> Hello,
> Im interested in participate too, but I don't have much experience. Can
> you tell me more about what do you want to do please?
>
> Thank you
>
> El dom., 23 feb. 2020 6:46 a. m., keshav kumar 
> escribió:
>
>> Hello,
>> I want to participate in GSoC with Django. And I want to work on 'Improve
>> Admin Filters' Project.
>> Here I am planning to work on issues related with filters which are not
>> taken by anyone . Is this good approach ?
>> Is there something more that would be helpful or needed which I can add
>> as well , please mention 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/9da51a2b-f2bf-46a3-a0c0-0849bca4026d%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/CAAW9J%2B8x54RNU%3DBub_-iDGFpeKTX1MUsxpvp2yTw7YvMZ7ajsg%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/CAMyDDM1ev-ppM7NHti7j%3DyzGA1_ckH85UjNCKqfeSAiqK89-%3Dw%40mail.gmail.com.

Re: Add a "humanized" widget for DurationField in admin interface

[Adam Johnson]

Hi Artem

I've used such a widget on a project. There's a third party package that
implements such a custom widget:
https://github.com/devangpadhiyar/django-durationwidget . However on the
project we found it's a bit immature and forked it internally (with some
customizations).

I think I'd like to see a third party package that implements this well
with good test coverage before it makes its way into Django core. Imo the
ability to select whether or not to display hours, microseconds, etc. is
really useful too.

On Sat, 22 Feb 2020 at 12:02, Artem Hruzd  wrote:

> In multiple projects I faced with issue to make a duration field easy for
> use for Admin users. I always back to custom solution and added simply 4
> fields:
>
>
> 
> I found an open ticket with the same problem
> https://code.djangoproject.com/ticket/28354
>
> Do you think this will be helper feature? Do I need go over this and
> implement 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/fc1be9f6-0f16-42b9-9183-c1b42e388221%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1uYsB9Lf95a3k3YqcxxVcrA3AsEjVyxV_zeE1i6QdGQw%40mail.gmail.com.

Re: Deprecating logout via GET

[Adam Johnson]

 > The reason this was not changed yet is backwards compatibility.

Do you have any mailing list / ticket links as reference?


It should be noted that the popular allauth already doesn’t allow logout by
GET (by default).

Personally I’m in favour.

On Thu, 27 Feb 2020 at 17:10, René Fleschenberg 
wrote:

> Hi everyone,
>
> there seems to be consensus that logging the client out on GET requests
> to the logout view is not great. Clients may try to prefetch links (this
> came up on IRC today). Attackers might annoy users by logging them out
> with embedded links to the logout URL.
>
> The reason this was not changed yet is backwards compatibility.
>
> I'd like to propose deprecating logging out via GET with the usual
> deprecation cycle, so that we have the possibility to stop supporting it
> in Django 4.0.
>
> In my opinion, this is a fairly easy change for Django users to make
> upon a Django update. Some changes to Django itself will also have to be
> made (the admin templates), but I think it should be possible to do
> those before the 4.0 release. And even if that doesn't happen, emitting
> a DeprecationWarning in 3.1+ wouldn't harm, right?
>
> What do you think?
>
> I went ahead and created a PR for this:
> https://github.com/django/django/pull/12504
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9baf0189-fc7a-80a0-6543-559c2b2b186a%40fleschenberg.net
> .
>
-- 
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/CAMyDDM2NFvrWY0C7XuCjt4g130YsnVkDdV80_mB3L-YndB3qCA%40mail.gmail.com.

Re: Deprecating logout via GET

[Adam Johnson]

Wow and first ticket referenced in one of those conversations was 12 years
ago: https://code.djangoproject.com/ticket/7989

Seems like a of a no-brainer at this point with general support from other
core devs in the past :)

On Fri, 28 Feb 2020 at 00:10, René Fleschenberg 
wrote:

> Hi,
>
> On 2/28/20 12:12 AM, Adam Johnson wrote:
> >  > The reason this was not changed yet is backwards compatibility.
> >
> > Do you have any mailing list / ticket links as reference?
>
> Sorry, I forgot to link them here. The main ticket seems to be
> https://code.djangoproject.com/ticket/15619.
>
> Mailing list dicussions are at
>
> https://groups.google.com/forum/#!topic/django-developers/MmFzCq8oB5I/discussion
> and
>
> https://groups.google.com/forum/#!topic/django-developers/ax95u_f82D4/discussion
> .
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/f6c73570-5276-d789-db00-c162457ac5bb%40fleschenberg.net
> .
>


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

Re: Deprecating logout via GET

[Adam Johnson]

Google (=Gmail): GET, but with a security token in the URL
Facebook: POST
Instagram: POST
Twitter: POST

‪On Sat, 29 Feb 2020 at 08:08, ‫אורי‬‎  wrote:‬

> I'm interested: Google, Gmail, Facebook, Instagram, Twitter: How do they
> use logout? POST or GET?
> אורי
> u...@speedy.net
>
>
> On Thu, Feb 27, 2020 at 7:10 PM René Fleschenberg 
> wrote:
>
>> Hi everyone,
>>
>> there seems to be consensus that logging the client out on GET requests
>> to the logout view is not great. Clients may try to prefetch links (this
>> came up on IRC today). Attackers might annoy users by logging them out
>> with embedded links to the logout URL.
>>
>> The reason this was not changed yet is backwards compatibility.
>>
>> I'd like to propose deprecating logging out via GET with the usual
>> deprecation cycle, so that we have the possibility to stop supporting it
>> in Django 4.0.
>>
>> In my opinion, this is a fairly easy change for Django users to make
>> upon a Django update. Some changes to Django itself will also have to be
>> made (the admin templates), but I think it should be possible to do
>> those before the 4.0 release. And even if that doesn't happen, emitting
>> a DeprecationWarning in 3.1+ wouldn't harm, right?
>>
>> What do you think?
>>
>> I went ahead and created a PR for this:
>> https://github.com/django/django/pull/12504
>>
>> --
>> 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-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/9baf0189-fc7a-80a0-6543-559c2b2b186a%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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CABD5YeHh%2BNvu4vtwaD8pC9526bAVpyA1iwo94c5bVSjRUa5eNg%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/CAMyDDM1BXBMELde0VnvkPS0dnKAoTf8qhrCZcukfspaQ9joUnA%40mail.gmail.com.

Re: Deprecating logout via GET

[Adam Johnson]

>
> Yes, but then hovering on the link doesn't show the logout URL at the
> bottom of the screen.


I don't think this is a concern.

‪On Sat, 29 Feb 2020 at 18:07, ‫אורי‬‎  wrote:‬

> Yes, but then hovering on the link doesn't show the logout URL at the
> bottom of the screen.
> אורי
> u...@speedy.net
>
>
> On Sat, Feb 29, 2020 at 6:01 PM Florian Apolloner 
> wrote:
>
>> I found an example on stackoverflow on how we could do this in the admin
>> without JS (with a bit of styling): https://stackoverflow.com/a/33880971
>> -- I personally would prefer it if we would not need javascript for a
>> fundamental functionality like this.
>>
>> On Saturday, February 29, 2020 at 9:26:23 AM UTC+1, Adam Johnson wrote:
>>>
>>> Google (=Gmail): GET, but with a security token in the URL
>>> Facebook: POST
>>> Instagram: POST
>>> Twitter: POST
>>>
>>> ‪On Sat, 29 Feb 2020 at 08:08, ‫אורי‬‎  wrote:‬
>>>
>>>> I'm interested: Google, Gmail, Facebook, Instagram, Twitter: How do
>>>> they use logout? POST or GET?
>>>> אורי
>>>> u...@speedy.net
>>>>
>>>>
>>>> On Thu, Feb 27, 2020 at 7:10 PM René Fleschenberg <
>>>> re...@fleschenberg.net> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> there seems to be consensus that logging the client out on GET requests
>>>>> to the logout view is not great. Clients may try to prefetch links
>>>>> (this
>>>>> came up on IRC today). Attackers might annoy users by logging them out
>>>>> with embedded links to the logout URL.
>>>>>
>>>>> The reason this was not changed yet is backwards compatibility.
>>>>>
>>>>> I'd like to propose deprecating logging out via GET with the usual
>>>>> deprecation cycle, so that we have the possibility to stop supporting
>>>>> it
>>>>> in Django 4.0.
>>>>>
>>>>> In my opinion, this is a fairly easy change for Django users to make
>>>>> upon a Django update. Some changes to Django itself will also have to
>>>>> be
>>>>> made (the admin templates), but I think it should be possible to do
>>>>> those before the 4.0 release. And even if that doesn't happen, emitting
>>>>> a DeprecationWarning in 3.1+ wouldn't harm, right?
>>>>>
>>>>> What do you think?
>>>>>
>>>>> I went ahead and created a PR for this:
>>>>> https://github.com/django/django/pull/12504
>>>>>
>>>>> --
>>>>> 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-d...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/django-developers/9baf0189-fc7a-80a0-6543-559c2b2b186a%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-d...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/django-developers/CABD5YeHh%2BNvu4vtwaD8pC9526bAVpyA1iwo94c5bVSjRUa5eNg%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/django-developers/CABD5YeHh%2BNvu4vtwaD8pC9526bAVpyA1iwo94c5bVSjRUa5eNg%40mail.gmail.com?utm_medium=email&utm_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/2598e4a0-1b0d-4d34-a807-2b243af72053%40googlegroups.com
>> <https://g

Re: making registration app compatible with older versions of django

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for 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. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Tue, 3 Mar 2020 at 04:26, Jay dev Jha  wrote:

> Hello everyone.
> Myself , Jay Dev Jha, from Indian Institute Of Information Technology
> Imphal, want to contribute to this organization.
> I am  currently working on designing  my own website using django.
> The registratison app is not compatible with older version of django when
> it automatically ugrades the version.can this be my first step to make the
> compatibility of registration app with older version too towards
> contributing to  Django?
> Thanking You.
> With Regards.
>
> --
> 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/3dc16023-97cc-49fa-afb5-d7c80ad7dcac%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM24RsUyzxDTUfoa4qDXYEcEf3cVD7STHqC26WZFjd95ng%40mail.gmail.com.

Re: AttributeError: 'ImageField' object has no attribute '_check_image_library_installed'

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for 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. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Tue, 3 Mar 2020 at 22:05, Unknown  wrote:

> image = models.ImageField(upload_to='web/images', null=False, blank=False)
>
> --
> 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/b640a773-97e5-48e1-9f26-828a1bd72dec%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3kCCQd6_prxNROhEGT_8f%2B5_%3DjjYNZ4mJZtfOWEZcsfw%40mail.gmail.com.

Re: Deprecating logout via GET

[Adam Johnson]

If your suggestion is limited to the admin, I think it would be fine, but
it's not necessary. But I don't think there is a compelling reason - there
aren't any difficulties with the CSS since Rene has already written it.

If your suggestion is for all logout views, there's no way to enforce it,
and anyway we don't want to require users to implement a new view in order
to upgrade Django. That can turn a "backend team" task into needing a
design and copy writing. We should document the possibility though.

On Wed, 4 Mar 2020 at 11:13, Sam Willis  wrote:

> Why not have the logout link take the user to a page asking them to
> confirm the logout, and have it as a POSTed form button from there?
>
> That adds a helpful confirmation page, removes the difficulties of styling
> a button as a link constantly (or changing the header design to a button).
>
> One downside would be the change in behaviour, people will be used to the
> logout link immediately logging them out and so may not read the next
> page...
>
> I’m sure there is literature in best practices for logout confirmation.
>
> --
> 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/0161eeed-7f9a-4312-9ed5-fc2bafde64ee%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1tcyZwZ-ix5mLDv6%3DKaF2oGJxw3h1ojMq6f3BA9Z1wNw%40mail.gmail.com.

Re: Review needed: Proposed behavior change in Field.contribute_to_class()

[Adam Johnson]

+1 from me

Afraid I don't know any of the why.

Also worth noting from the PR description:

Previously: DeferredAttributes would not get stapled onto models where the
> model (or an ancestor) already had an existing *non-falsey* attribute.
>

Non-falsey! I almost spat out my tea.

Thanks for the detailed write up with reference links.

On Wed, 4 Mar 2020 at 11:10, Carlton Gibson 
wrote:

> Hi all.
>
> Especially from those with long memories, can I request thoughts on a
> proposed
> adjustment to `Field.contribute_to_class()`, which affects the manner in
> which
> fields override attributes from parent classes?
>
> The entails a breaking change. As such... 😬 — but I think it's acceptable
> and
> worth it.
>
> I'm posting here to ensure we get sufficient review on that.
>
> Sorry for the long post. I've tried to lay it out as clearly as possible.
> Thank you for your time and effort.
>
> The pull request for all this is here:
>
> https://github.com/django/django/pull/11337
>
> Details
> ---
>
> There are a cluster of tickets pertaining to the behavior of
> `Field.contribute_to_class()`:
>
> * Descriptors not accessible for inherited models.
> https://code.djangoproject.com/ticket/30427
> * Overwriting a property with field during model inheritance.
> https://code.djangoproject.com/ticket/16176
> * Model attributes shouldn't override deferred fields
> https://code.djangoproject.com/ticket/28198
>
> The are all related. Ultimately, they're different versions of the same
> bug.
>
> The essence of it looks like this:
>
> ```
> >>> from django.contrib.auth.models import User
> >>> User.objects.create_user(username='spam', password='eggs',
> is_active=False)
> 
> >>> User.objects.get().is_active
> False
> >>> User.objects.defer('is_active').get().is_active
> True
> ```
>
> Which happens for two reasons:
>
> 1. `AbstractBaseUser` provides a scalar default for the `is_active` field:
>
> class AbstractBaseUser(models.Model):
> ...
> is_active = True
> ...
>
> 2. `Field.contribute_to_class()` will then not set the field descriptor on
> the
>subclass:
>
> if self.column:
> # Don't override classmethods with the descriptor. This means
> that
> # if you have a classmethod and a field with the same name,
> then
> # such fields can't be deferred (we don't have a check for
> this).
> if not getattr(cls, self.attname, None):
> setattr(cls, self.attname, self.descriptor_class(self))
>
> This leads to all the issues above, plus additional problems in the
> eco-system.
> e.g. https://github.com/jazzband/django-model-utils/issues/382
>
> The payoff of the proposed change is fixing all these issues.
>
> §
>
> The history didn't tell me much so, I mailed the list in June last year to
> ask
> if anybody had any recollection of the _Why?_ to that _"Don't override
> classmethods with the descriptor"_.
>
> https://groups.google.com/d/msg/django-developers/zXB0oJ8tD3E/nH8yx_FpBAAJ
>
> Nobody could remember that _Why_.
>
> * One post, saying:
>
> > I’ve run into this a few times, and the current behaviour has felt
> > jarring and unpythonic.
>
> * One post pointing to one of the related tickets above.
>
> Again then, maybe last chance, do you have a long memory? Do you know that
> _Why_? :)
>
> §
>
> Discussing #16176, Carl Meyer made a comment that was never picked up on:
>
> > [The] suggestion to set all fields as class attributes so they override
> > descriptors from a parent class is certainly worth considering, as it
> would
> > make models behave more like regular Python classes. This could result in
> > some backwards-incompatibility; would need to look into it more to get a
> > clearer sense of what cases might cause trouble, but I think it's
> probably
> > acceptable if documented in the release notes.
>
> https://code.djangoproject.com/ticket/16176#comment:6
>
> The idea is to implement that, always setting the descriptor in the `if
> self.column` block:
>
> if self.column:
> setattr(cls, self.attname, self.descriptor_class(self))
>
> §
>
> Implementing that in a PR, leads to **three** failures in the current
> tests.
>
> PR: https://github.com/django/django/pull/11337
>
> Two failures are tests for system checks, which cover edge cases arising
> from
> the existing behavior. I think the tests can be adjusted safely:
>
> * `models.E020`.
>
> Originally added for: `Fixed #23615 -- Validate that a Model
> instance's "check" attribute is a method`
>
> https://github.com/django/django/commit/a5c77417a651c93036cf963e6da518653115be7e
>
> PR Diff:
>
> https://github.com/django/django/pull/11337/files#diff-dc8c55ebf8072120b505dd8dade78efcR289-R294
>
> * `models.E025`.
>
> Originally added for: ` Fixed #28867 -- Added system check for a model
> property that clashes with a related field accessor.`
>
> https://github.com/django/django/commit/cc6bcc6ff5ca

Re: LiveServerTestCase - self.client.force_login() when called more than once returns django.db.utils.DatabaseError

[Adam Johnson]

Hi!

I'm pasting my "wrong mailing list" standard text below. This is a support
query for an old version of Django.

The ticket you linked to was committed in
https://github.com/django/django/commit/eedc88bd4a8468c2a0daa8346c9b57183dd77782
which I can see was released in Django 2.0.

You should really upgrade!

Thanks,

Adam

---

I think you've found the wrong mailing list for this post. This mailing
list is for 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. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Wed, 4 Mar 2020 at 07:04, Deep Sukhwani  wrote:

> Hello,
>
> This query is for Django version 1.9 and Python 3.5 with Django Rest
> Framework 3.5.4
> *(I know this version is outdated, but moving ahead of this version as of
> now is out of reach for the purpose of solving this query)*
>
> *Exact Error observed:*
>
> self.client.force_login(self.user)
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/test/client.py"
> , line 608, in force_login
> self._login(user)
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/test/client.py"
> , line 621, in _login
> login(request, user)
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/__init__.py"
> , line 117, in login
> user_logged_in.send(sender=user.__class__, request=request, user=user)
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/dispatch/dispatcher.py"
> , line 192, in send
> response = receiver(signal=self, sender=sender, **named)
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/models.py"
> , line 23, in update_last_login
> user.save(update_fields=['last_login'])
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/base_user.py"
> , line 74, in save
> super(AbstractBaseUser, self).save(*args, **kwargs)
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
> , line 708, in save
> force_update=force_update, update_fields=update_fields)
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
> , line 736, in save_base
> updated = self._save_table(raw, cls, force_insert, force_update, using
> , update_fields)
>   File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
> , line 805, in _save_table
> raise DatabaseError("Save with update_fields did not affect any rows."
> )
> django.db.utils.DatabaseError: Save with update_fields did not affect any
> rows.
>
>
> *Scenario:*
>
> from django.test import TestCase, LiveServerTestCase
>
> from paths.factories import UserFactory
>
>
> class ATestClass(LiveServerTestCase):
>
> @classmethod
> def setUpClass(cls):
> """
> Test Data common across all tests
> """
>
> super().setUpClass()
>
> cls.user = UserFactory(is_staff=False, is_superuser=False)
>
> def test_one(self):
> """
> Login and then do some actions
> """
> self.client.force_login(self.user)
>
> # do something
> self.assertTrue(True)
>
> def test_two(self):
> """
> Login and do some actions
> """
>
> self.client.force_login(self.user)
>
> # do something
> self.assertFalse(False)
>
>
> However, if I change the base class from LiveServerTestCase to TestCase,
> it works fine without any errors. I understand this was probably addressed
> in https://code.djangoproject.com/ticket/26823 but can someone help with
> any way in which I can patch this in my tests to avoid raising this issue?
>
> *Why LiveServerTestCase?*
>
>- My tests need access to live_server_url, hence I am forced to
>inherit the test class from LiveServerTestCase
>
> *What have I tried?*
>
>- Logging in in setUp method inst

Re: LiveServerTestCase - self.client.force_login() when called more than once returns django.db.utils.DatabaseError

[Adam Johnson]

I should have written: You can fork Django on GitHub, backport that commit
(git cherry-pick) to the stable/1.9.x branch, and install that hash:
https://adamj.eu/tech/2019/03/11/pip-install-from-a-git-repository/ .

On Wed, 4 Mar 2020 at 13:45, Deep Sukhwani  wrote:

> Thank you, Adam,
>
> Note: For future posts on this topic - Request you to use django-users
> mailing list:
> https://groups.google.com/forum/#!topic/django-users/GbU7FekodGY
>
> I realized that I posted this in the wrong mailing list after posting it
> and so I reposted this in django-users mailing list
> <https://groups.google.com/forum/#!topic/django-users/GbU7FekodGY>.
> Extremely sorry for this.
>
> Thanks for calling out that we should really upgrade to Django 2.0,
> however, for now, I would love to understand if there is a way to patch
> this in Django 1.9 until we (my organization) are stuck on this version.
>
> *For anyone else, if you have a helpful response - request you to respond
> to it in the django-users mailing list - link to this post: *
> https://groups.google.com/forum/#!topic/django-users/GbU7FekodGY
>
> Thank you
>
> On Wednesday, 4 March 2020 19:07:48 UTC+5:30, Adam Johnson wrote:
>>
>> Hi!
>>
>> I'm pasting my "wrong mailing list" standard text below. This is a
>> support query for an old version of Django.
>>
>> The ticket you linked to was committed in
>> https://github.com/django/django/commit/eedc88bd4a8468c2a0daa8346c9b57183dd77782
>> which I can see was released in Django 2.0.
>>
>> You should really upgrade!
>>
>> Thanks,
>>
>> Adam
>>
>> ---
>>
>> I think you've found the wrong mailing list for this post. This mailing
>> list is for 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. People on this list are unlikely to answer your
>> support query with their limited time and energy. Read more on the mailing
>> lists at https://www.djangoproject.com/community/
>>
>> For support, please use the NEW Django forum at
>> https://forum.djangoproject.com , django-users mailing list, or IRC
>> #django on Freenode, or a site like Stack Overflow. There are people out
>> there willing to help on those channels, but they might not respond if you
>> don't ask your question well. Stack Overflow's question guide can help you
>> frame it well: https://stackoverflow.com/help/how-to-ask .
>>
>> Also if you haven't read it, please take a look at Django's Code of
>> Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
>> rules" for working well as a community, and will help you get the most out
>> of Django and our fantastic community.
>>
>> Thanks for your understanding,
>>
>> Adam
>>
>> On Wed, 4 Mar 2020 at 07:04, Deep Sukhwani  wrote:
>>
>>> Hello,
>>>
>>> This query is for Django version 1.9 and Python 3.5 with Django Rest
>>> Framework 3.5.4
>>> *(I know this version is outdated, but moving ahead of this version as
>>> of now is out of reach for the purpose of solving this query)*
>>>
>>> *Exact Error observed:*
>>>
>>> self.client.force_login(self.user)
>>>   File
>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/test/client.py"
>>> , line 608, in force_login
>>> self._login(user)
>>>   File
>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/test/client.py"
>>> , line 621, in _login
>>> login(request, user)
>>>   File
>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/__init__.py"
>>> , line 117, in login
>>> user_logged_in.send(sender=user.__class__, request=request, user=
>>> user)
>>>   File
>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/dispatch/dispatcher.py"
>>> , line 192, in send
>>> response = receiver(signal=self, sender=sender, **named)
>>>   File
>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/models.py"
>>> , line 23, in update_last_login
>>> user.save(update_fields=['last_login'])
>>>   File
>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/base_user.py"
&g

Re: #31319 URL dispatcher does not handle multislashes

[Adam Johnson]

I'd be against this

Merging multiple slashes is a way of duplicating canonical URL's for
things, something Django actively tries to avoid with APPEND_SLASHES.

If you want this functionality you should be able to create it yourself
with a custom URL converter or URLPattern subclass.

On Wed, 4 Mar 2020 at 14:41, Bjoern Boschman 
wrote:

> Hi,
>
> I'd like to start a discussion about how django handles multiple slashes.
> see: https://code.djangoproject.com/ticket/31319#comment:1
>
> So far I can confirm that nginx, apache and unix folders handle multiple
> slashes the same way (-> they get merged)
> What's your (dev) opinion on this?
>
> Cheers
> B
>
> TV Squared Limited is a company registered in Scotland.  Registered
> number: SC421072.  Registered office: CodeBase, Argyle House, 3 Lady Lawson
> Street, Edinburgh, EH3 9DR.
>
> TV Squared Inc (File No. 5600204) is an Incorporated company registered in
> Delaware. Principal office: 1412 Broadway, 22 Fl, New York, New York, 10018
>
> TV Squared GmbH is a company registered in Munich. Registered number: HRB
> 236077. Registered office: Oskar-von-Miller-Ring 20, c/o wework, 80333
> Munchen
>
> This message is private and confidential.  If you have received this
> message in error, please notify us and remove it from your system.
>
> --
> 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/0afe6cd9-952e-46a7-b756-10bb04eb70e9%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3%2BtW1GduBKpZT1V3udRK-kqFFc%3DcrPgQZxnTTV5AgaGQ%40mail.gmail.com.

Re: #31319 URL dispatcher does not handle multislashes

[Adam Johnson]

The nginx documentation points to a reason:
https://nginx.org/en/docs/http/ngx_http_core_module.html#merge_slashes

 Note that compression is essential for the correct matching of prefix
> string and regular expression locations. Without it, the
> “//scripts/one.php” request would not match
>
> location /scripts/ { ...
>

I think this much more of a concern with classic web servers that serve up
files from your filesystem directly from the URL..

It also points to a reason why it would be backwards incompatible of Django
to start doing this:

 Turning the compression off can become necessary if a URI contains
> base64-encoded names, since base64 uses the “/” character internally.
> However, for security considerations, it is better to avoid turning the
> compression off
>

On Wed, 4 Mar 2020 at 19:31, Bjoern Boschman 
wrote:

> Hi Adam,
>
> APPEND_SLASH only adds a slash at the end of the path
> I'm more concerned about having multiple slashes in the middle of the path
> I get your point about canonical URLs - I'm just confused why other major
> HTTP servers are handling this different
>
> On Wednesday, 4 March 2020 14:27:19 UTC-5, Adam Johnson wrote:
>>
>> I'd be against this
>>
>> Merging multiple slashes is a way of duplicating canonical URL's for
>> things, something Django actively tries to avoid with APPEND_SLASHES.
>>
>> If you want this functionality you should be able to create it yourself
>> with a custom URL converter or URLPattern subclass.
>>
>> On Wed, 4 Mar 2020 at 14:41, Bjoern Boschman 
>> wrote:
>>
>>> Hi,
>>>
>>> I'd like to start a discussion about how django handles multiple slashes.
>>> see: https://code.djangoproject.com/ticket/31319#comment:1
>>>
>>> So far I can confirm that nginx, apache and unix folders handle multiple
>>> slashes the same way (-> they get merged)
>>> What's your (dev) opinion on this?
>>>
>>> Cheers
>>> B
>>>
>>> TV Squared Limited is a company registered in Scotland.  Registered
>>> number: SC421072.  Registered office: CodeBase, Argyle House, 3 Lady Lawson
>>> Street, Edinburgh, EH3 9DR.
>>>
>>> TV Squared Inc (File No. 5600204) is an Incorporated company registered
>>> in Delaware. Principal office: 1412 Broadway, 22 Fl, New York, New York,
>>> 10018
>>>
>>> TV Squared GmbH is a company registered in Munich. Registered number:
>>> HRB 236077. Registered office: Oskar-von-Miller-Ring 20, c/o wework, 80333
>>> Munchen
>>>
>>> This message is private and confidential.  If you have received this
>>> message in error, please notify us and remove it from your system.
>>>
>>> --
>>> 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/0afe6cd9-952e-46a7-b756-10bb04eb70e9%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/0afe6cd9-952e-46a7-b756-10bb04eb70e9%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> --
>> Adam
>>
>
> TV Squared Limited is a company registered in Scotland.  Registered
> number: SC421072.  Registered office: CodeBase, Argyle House, 3 Lady Lawson
> Street, Edinburgh, EH3 9DR.
>
> TV Squared Inc (File No. 5600204) is an Incorporated company registered in
> Delaware. Principal office: 1412 Broadway, 22 Fl, New York, New York, 10018
>
> TV Squared GmbH is a company registered in Munich. Registered number: HRB
> 236077. Registered office: Oskar-von-Miller-Ring 20, c/o wework, 80333
> Munchen
>
> This message is private and confidential.  If you have received this
> message in error, please notify us and remove it from your system.
>
> --
> 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/fce90055-ce46-4704-b81e-afc64bcde358%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/fce90055-ce46-4704-b81e-afc64bcde358%40googlegroups.com?utm_medium=email&utm_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/CAMyDDM1sZ4TMxGFdaxYTUcPas%3DiifZk_%3DUCNeX_GNfd4LH5MMw%40mail.gmail.com.

Re: IRC Chat

[Adam Johnson]

Hi José

irc.freenode.net is up but is not accessible with a web browser, only with
an IRC client.

You can use webchat.freenode.net to connect.

Since it can be a bit confusing I've opened a Django documentation ticket
to update our links to go via the freenode "how to connect" article that
mentions both webchat and using an IRC client:
https://code.djangoproject.com/ticket/31356 . This should make it easier
for others in the future.

Thanks,

Adam

On Tue, 10 Mar 2020 at 14:49, Abhijeet Viswa 
wrote:

> Hello,
>
> The IRC channel is still there. You can try using Riot.im with Matrix to
> bridge free node.
>
> On Tue, 10 Mar, 2020, 20:18 José Manuel Valdivia Romero, <
> josevaldiviarom...@gmail.com> wrote:
>
>> Hi Guys,
>>
>> I'm completely new trying to contribute to the Django project (But was
>> working on applications with Django for many years).
>>
>> I was checking the README.rst and saw that there is the Django IRC
>> channel... is this used? because accessing to irc.freenode.net is not
>> available anymore, should this be changed to
>> https://webchat.freenode.net/? or there is no more support of Django in
>> an IRC channel?
>>
>> Best regards,
>>
>> José Manuel Valdivia
>>
>> --
>> 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/CABSqBgHDzXnnzAYzGThnE3WaANTZega%2B_ahZZeQzX6p%2BMGTCFg%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/CAP1-Yrr0QKO3rVj%2B5dN9PTSRAoDzdvu%2BYTmnZv7T8onci-9KSQ%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/CAMyDDM3rE0BPfaKLVkjyFA%2BPBCdR72%2B992Bak09K%3DxoPnB3VXA%40mail.gmail.com.

Re: Proposal for better managed raw SQL migrations

[Adam Johnson]

Hi Petr

I too often end up managing some database objects like triggers, normally
in order to support database migrations. I have always been happy using
RawSQL migration operations though.

What types of database objects are you mostly using? And how?

I think django-migrate-sql is a neat idea, but since it requires full
authorship of the SQL it doesn't provide the most ORM-like experience. It's
also not backend agnostic, which is something preferable for anything we
add to Django. I'd be more interested in implementing classes that
represent the underlying object type, like Models represent tables, and
translating changes to them into migration operations.

Thanks,

Adam

On Wed, 11 Mar 2020 at 09:04, Petr Přikryl  wrote:

> In our apps we have a lot of database objects which are hard to manage in
> classic Django migrations. Next, we clean our migrations time to time to
> speed up deployment process. And it would be awesome if Django would have
> system for raw SQL "models" and handle migrations and dependencies
> automatically in makemigrations and migrate commands like
> django-migrate-sql-deux https://pypi.org/project/django-migrate-sql-deux/.
> What do you think?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c078a0ae-9643-4d5c-b1de-f82cec2a7f33%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM02yEMRP5tvwWEY9mwK4Xn6z%3Dr%3Dw05_D1RxWRKUQ4gjpA%40mail.gmail.com.

Re: [Probably BUG] set_password and check_password accept values other than string as parameters

[Adam Johnson]

Hi Dawid,

Welcome to the django-developers mailing list!

This is pretty normal Pythonic behaviour. Inside these methods, Django
casts the given object to a string with str() (specifically, in
force_bytes). Most objects can be cast to a string, although I agree many
of them won't necessarily make sense as passwords.

This is because Python normally leans on "duck typing". Runtime type
checking is normally used sparingly since it removes flexibility. Static
type checkers are gaining some popularity but it remains to be seen how far
they will affect Django and its ecosystem. Even then, I'm not sure we'd be
able to enforce strings-only as the type signature here, as it wouldn't be
backward compatible.

Thanks,

Adam

On Wed, 11 Mar 2020 at 22:40, Dawid Czeluśniak 
wrote:

> Hi all,
>
> I've noticed that both set_password and check_password methods accept
> values other than str as parameters. For example I'm able to set password
> to boolean values:
>
> In [1]: u.set_password(True)
>
> In [2]: u.save()
>
> In [3]: u.refresh_from_db()
>
> In [4]: u.check_password(True)
> Out[4]: True
>
> In [5]: u.check_password('True')
> Out[5]: True
>
> What is even weirder, I'm able to set password as Exception class:
>
> In [1]: u.set_password(Exception)
>
> In [2]: u.save()
>
> In [3]: u.refresh_from_db()
>
> In [4]: u.check_password(repr(Exception))
> Out[4]: True
>
> and the User instance itself:
>
> In [1]: u.set_password(u)
>
> In [2]: u.save()
>
> In [3]: u.refresh_from_db()
>
> In [4]: u.check_password(u)
> Out[4]: True
>
> In [5]: u.check_password(str(u))
> Out[5]: True
>
> IMHO this is not correct behaviour especially because Django documentation
> implies that these methods accept strings.
>
> set_password(raw_password)
>> Sets the user’s password to the given *raw string*, taking care of the
>> password hashing. Doesn’t save the User object.
>>
>> check_password(raw_password)
>> Returns True if the given *raw string* is the correct password for the
>> user. (This takes care of the password hashing in making the comparison.)
>
>
> Please let me know if this is reproducible on your side.
>
> Dawid
>
> --
> 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/0429a2cd-a16c-429f-98b5-938629073ca5%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3VHBjeQBbbbWXcu5_h%3DAjOFvMefz%3DoJ-iKHSAZKrrKLQ%40mail.gmail.com.

Re: [Probably BUG] set_password and check_password accept values other than string as parameters

[Adam Johnson]

User provided passwords are validated already:
https://docs.djangoproject.com/en/3.0/topics/auth/passwords/#module-django.contrib.auth.password_validation

When using set_password directly, you as the programmer are responsible for
ensuring the value you use for password is valid. Normally this means
calling the functions detailed in "Integrating validation" beforehand.

On Thu, 12 Mar 2020 at 15:55, '1337 Shadow Hacker' via Django developers
(Contributions to Django itself)  wrote:

> I agree with Adam, but in this case it seems to pose a security risk in
> case of user mistake, as such, raising a ValueError would have protect
> against the mistake of passing empty passwords, unless you consider empty
> passwords a feature of course in which case please dismiss my email.
>
> --
> 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/9Xx6DvMQMWVWMRYMhbK-8nXfyPrNU_5ljWd-YuXeXRmz3_pnYXT6axEYrDBfW4K1v5OGEshIR2SDAeZxpnDBSk6SMLe4oeiwcrDMnz7xah4%3D%40protonmail.com
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1dOh5wvYha%3D7vY%2Bub8ZvTScqdG-qxEbtntTBx8OALMgg%40mail.gmail.com.

Re: New Merger nomination.

[Adam Johnson]

Big +1 from me, Claudes contributions are solid.

On Fri, 13 Mar 2020 at 19:33, charettes  wrote:

> I second this nomination.
>
> Le vendredi 13 mars 2020 15:30:19 UTC-4, Mariusz Felisiak a écrit :
>>
>> I nominate Claude Paroz to a new MERGER for 8 years of contributions to
>> Django, including triaging tickets, reviewing PRs, and serving as the
>> Django translations manager. Claude is one of the most  active contributor
>> with outstanding impact on Django. He was also awarded the 2017 Malcolm
>> Tredinnick Memorial Prize (
>> https://www.djangoproject.com/weblog/2018/jan/22/2017-malcolm-tredinnick-prize-claude-paroz/
>> ).
>>
>> Best,
>> Mariusz Felisiak
>>
> --
> 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/607e208d-2307-4f5e-8e94-029ebbcac612%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM12s6AM5MR3nBHMZu3Rdo9%2B7LaJ9qeawrWk%3DyarD%3DorHg%40mail.gmail.com.

Re: [Feature Request] Having an middleware to be able to force authentication on views by default

[Adam Johnson]

Hi Mehmet,

I like your move to fail-closed here. I've certainly seen missing auth
decorators as a recurring issue in my career, and I do think as an OWASP
top ten we should try tackle it better in the framework.

Your implementation is very few lines of code. It could be made more
robust, using the attribute approach that the CSRF middleware uses:
https://github.com/django/django/blob/7075d27b0c75f1431f29497f4353cd742906b357/django/middleware/csrf.py#L209
. And it could easily be added to django.contrib.auth, and the default
project template. AuthenticationMiddleware doesn't in fact have a
process_view method at current, so we could even add it there with a
setting to control it.

I doubt many would be against it as an optional extra.

Thanks,

Adam

On Sun, 15 Mar 2020 at 06:36, Václav Řehák  wrote:

> Hi Tobias,
>
> Dne sobota 14. března 2020 9:44:16 UTC+1 Tobias Bengfort napsal(a):
>>
>>
>> Another option could be to add system checks for this: Instead of
>> silently "fixing" missing code it would inform developers about missing
>> decorators/mixins. (If I have time I might try to come up with a
>> prototype of this.)
>
>
> my thinking about this is exactly the same as yours. I have seen issues
> with developers forgetting to add LoginRequiredMixin almost on all projects
> I worked on and I think all of this issues would have been prevented if the
> developers were force to explicitly specify the desired authentication
> requirements for each view (probably using the checks system).
>
> In my current project we added a testcase to go through all urls in
> urlconf and compare then to whitelist of public urls. But it is ugly as it
> hardcodes urls as strings (similar to the django-utils repo) defeating the
> flexibility of url patterns.
>
> --
> 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/4c13eb8d-eb6a-4973-be4d-5abe0fc55bb9%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3Ui3shxaspquwhbvT0%2BrbhJXfkC4Sd8bw-zcS_2u0Q5A%40mail.gmail.com.

Re: [Probably BUG] set_password and check_password accept values other than string as parameters

[Adam Johnson]

Dawid, thank you for checking these other implementations. I agree it's
somewhat surprising and clearly something the developers of the other
password libraries decided to guard against.

One question I have is - did you experience any real world issue with this?
Reading back over the thread, you haven't mentioned this. As Tom says, this
is the first mention he can remember.

We could add type guards to many of the thousands of functions in Django to
prevent potential bugs. I'm sure some would. I'm sure many would just be
"academic". And they come with both the implementation and maintenance
costs, plus making duck-typing harder for users.

To add one here, it would go through the normal deprecation process:
https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy
. This means PR's for 3.1, 3.2, and 4.0, changing the code, documentation,
and release notes.

I'd say at this point I'm convinced this *could* be a (slightly) useful
change. But you have to be aware - I don't think you'll find anyone who's
willing to do this work other than yourself. There are many more
interesting changes to be made to Django if you check Trac!

Thanks,

Adam



On Sat, 14 Mar 2020 at 14:53, Dawid Czeluśniak 
wrote:

> Tom,
>
> The behavior of the make_password method is quite surprising to be honest
>>
>
> I'd go even further and say that currently the behaviour of the
> make_password function is *wrong* and *unsafe*. Again, let's look at
> hashing functions from other libraries. None of them fails silently and
> casts object to bytes using __str__().  Werkzeug and passlib are the most
> notable examples how to handle things correctly:
>
>
> *1. Werkzeug*
> In [1]: from werkzeug.security import generate_password_hash
>
> In [2]: generate_password_hash(dict())
> TypeError: Expected bytes
>
>
> *2. Passlib*
> In [1]: from passlib.hash import pbkdf2_sha256
>
> In [2]: pbkdf2_sha256.hash(dict())
> TypeError: secret must be unicode or bytes, not dict
>
>
> *3. Django*
> In [1]: from django.contrib.auth.hashers import make_password
>
> In [2]: make_password(dict())
> Out[2]:
> 'pbkdf2_sha256$18$dimMkJ5wvrpn$eHh6CNAY+hTagaDmsofHMlJEbVOXEeIEfcT059Me2ho='
> (seriously???)
>
> This is especially *wrong* because programmers who are *not* aware of
> this strange behaviour can accidentally do things that they *really *don't
> want to do. I can imagine scenarios in which this can have some serious
> unintended consequences.
>
> maybe the advantages of being able to pass any object into the method is
>> entirely academic because nobody passes anything but strings on purpose
>
>
> Exactly. I'd even say that there are *no* advantages of being able to
> pass any object into this function and it can have bad consequences.
>
> Dawid
>
> --
> 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/CAHzshFuQnEUrAdk53apDWw3wnPBNq%2BYQE9bxyfOpbFfyQS04dw%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/CAMyDDM0h8aD4-vutrZ3m2kZ_CuTXoY3sYN5N83Vr_9HtEWLuYw%40mail.gmail.com.

Re: Proposal to deprecate NullBooleanField (and remove in Django 4.0)

[Adam Johnson]

+1 from me.

On Tue, 17 Mar 2020 at 07:59, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> I'm inclined to Accept as well.
>
> --
> Aymeric.
>
>
>
> On 17 Mar 2020, at 08:49, Carlton Gibson  wrote:
>
> Hi all.
>
>
> https://code.djangoproject.com/ticket/31369
> Proposes to deprecate NullBooleanField.
>
>
> https://code.djangoproject.com/ticket/29227
> Allowed BooleanField to be null=True.
> Introduced in Django 2.1.
>
>
> I'm inclined to Accept.
> Wonder if folks consider it a little too fast?
> (We could defer for 5.0.)
>
>
> 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/02a4b01d-e47f-4092-826e-c0cfa074901f%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/6353F843-B61D-4C50-8A45-98DAD860301A%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/CAMyDDM3bCYzz3JMCVgXP1%2BmB56CCmTiHmw1ij%3Dbj_5aQSGWaZQ%40mail.gmail.com.

Re: Django dynamic form creation

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for 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. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Thu, 19 Mar 2020 at 08:10, Rahul Roshan  wrote:

> I am trying to create a splitwise  clone
> application for my weekend project. I have arrived at a stage where I have
> to create a new Bill. Please find below screenshot.
>
> In this form I have three queries:
>
>1. A dynamic form where a model with fields (amount, user) can be
>added or removed dynamically. I am using modelformset_factory to perform
>this operation. From the UI's perspective I am using javascript to add two
>fields based onClick operation and similarly remove onClick, please check
>code. My question is, is this correct approach from UI's perspective to
>create dynamic fields using javascript or is there any other right way ?
>2. I am passing users list from views.py to my bill.html template.
>Again, is this a correct approach ? Or is there any other right way ?
>3. After creating multiple split forms and clicking on create Bill. At
>the view.py I am receiving only one split form rather than multiple ?? I am
>thinking something is wrong because of might be above two approaches are
>not correct !!! Need help over this.
>
>
> [image: Screenshot 2020-03-19 at 1.31.33 PM.png]
>
> This is the javascript I am using to create split model having two fields
> (amount and user). Providing the existing users list from the users args I
> passed from the views.py
> bill.html
>
>> 
>> var room = 1;
>> function education_fields() {
>> room++;
>> var objTo = document.getElementById('education_fields')
>> var divtest = document.createElement("div");
>>divtest.setAttribute("class", "form-group removeclass"+room);
>>var rdiv = 'removeclass'+room;
>> divtest.innerHTML = '
> class="form-group"> > class="form-control" id="amount" placeholder="Amount">
> class="col-sm-5 nopadding">
>> 
 
>> {% for user in users %}{{user}}{% endfor 
>> %}
>> 
> class="input-group">
>> 
 > type="button" onclick="remove_education_fields('+ room +');">
>>  
>> 
';
>> objTo.appendChild(divtest)
>> }
>>function remove_education_fields(rid) {
>>   $('.removeclass'+rid).remove();
>>}
>> 
>>
>>
> models.py
>
>> class Bill(models.Model):
>> bill_id = models.AutoField(primary_key=True, null=False)
>> bill_name = models.CharField(max_length=100)
>> total_amount = models.IntegerField()
>>
>> def __str__(self):
>> return "%s-%s"%(str(self.bill_id), self.bill_name)
>>
>> class Split(models.Model):
>> amount = models.IntegerField()
>> split_user = models.ForeignKey(User, on_delete=models.CASCADE, null=True)
>> bill = models.ForeignKey(Bill, on_delete=models.CASCADE, null=False, 
>> default='')
>>
>> def __str__(self):
>> return "%s-%s" % (str(self.bill_id), self.amount)
>>
>>
> forms.py
>
>> class BillModelForm(forms.ModelForm):
>> class Meta:
>> model = Bill
>> fields = ('bill_name', 'total_amount')
>> labels = {
>> 'bill_name': 'Enter the Expenditure',
>> 'total_amount': 'Enter the total amount',
>> }
>>
>> SplitFormSet = modelformset_factory(
>> Split,
>> fields=('amount','split_user'),
>> extra=1,
>> labels = {
>> 'amount': 'Enter the split amount',
>> 'split': "Share Friend",
>> },
>> widgets={
>> 'amount': forms.TextInput(
>> attrs={
>>   

Re: [Feature Request] Having an middleware to be able to force authentication on views by default

[Adam Johnson]

I personally am in favour of including this in Django at this point.

It seems like a desirable feature, it has circulated the community since
2008 (!), and there are at least two community packages implementing the
pattern. No one on this thread is explicitly against it ever happening.

I'm in favour of the approach of a second middleware rather than a setting
for AuthenticationMiddleware. We do try to avoid settings and I think this
is a more sensible approach.

It would be relatively little code and documentation overhead - a
middleware (maybe LoginRequiredAuthenticationMiddleware ?), a decorator
(maybe @login_not_required ? - the opposite of @login_required), and a view
mixin (LoginNotRequired ?).

On Fri, 20 Mar 2020 at 18:25, Tobias Bengfort 
wrote:

> Hi Mehmet,
>
> On 19/03/2020 09.49, Mehmet Ince wrote:
> > To be honest, I’m kind a confused about how to proceed. Should I
> > continue with settings to control it or subclass of Auth middleware ?
>
> Remember that many people on this mailing list (me included) are people
> just like you, so we can only give you feedback and maybe some
> additional ideas.
>
> The best course of action is probably to write a mail in which you sum
> up the discussion so far, highlight some controversial points, and
> describe why you decided the way you did in your implementation. At
> least that is what I would do.
>
> The critical part in my experience is to convince people that this
> should be included in django itself rather than a third party library. I
> usually fail with that so I cannot say anything useful about that.
>
> tobias
>
> --
> 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/469846ef-6d3a-c0c5-73d0-21b694185e81%40posteo.de
> .
>


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

Re: TestCase.setUpTestData in-memory data isolation.

[Adam Johnson]

+1 from me - I was thinking of this the other day.

On Sun, 22 Mar 2020 at 22:38, charettes  wrote:

> For anyone interested I finally submitted a ticket[0] to add this feature
> to core since the third-party app[1]
> was proven to be quite functional in all the projects I've used it so far
> and no issues were opened
> against the package in the two years it has been around.
>
> Looking forwards to see this feature included in the next versions of
> Django.
>
> Cheers,
> Simon
>
> [0] https://code.djangoproject.com/ticket/31395#ticket
> [1] https://github.com/charettes/django-testdata
>
> Le vendredi 23 novembre 2018 22:29:33 UTC-5, charettes a écrit :
>>
>> Dear developers,
>>
>> Django 1.8 introduced the `TestCase.setUpTestData()` class method as a
>> mean to
>> speed up test fixtures initialization as compared to using `setUp()`[0].
>>
>> As I've come to use this feature and review changes from peers using it in
>> different projects the fact that test data assigned during its execution
>> couldn't be safely altered by test methods without compromising test
>> isolation
>> has often be the source of confusion and frustration.
>>
>> While the `setUpTestData` documentation mentions this limitation[1] and
>> ways to
>> work around it by using `refresh_from_db()` in `setUp()` I believe it
>> defeats
>> the whole purpose of the feature; avoiding unnecessary roundtrips to the
>> database to speed up execution. Given `TestCase` goes through great
>> lengths to
>> ensure database level data isolation I believe it should do the same with
>> class
>> level in-memory data assigned during `setUpTestData`.
>>
>> In order to get rid of this caveat of the feature I'd like to propose an
>> adjustment to ensure such in-memory test data isolation.
>>
>> What I suggest doing is wrapping all attributes assigned during
>> `setUpTestData`
>> in descriptors that lazily return `copy.deepcopy()`ed values on instance
>> attribute accesses. By attaching the `deepcopy()`'s memo on test
>> instances we
>> can ensure that the reference graph between objects is preserved and thus
>> backward compatible.
>>
>> In other words, the following test would pass even if `self.book` is a
>> deep
>> copy of `cls.book`.
>>
>> class BookTests(TestCase):
>> @classmethod
>> def setUpTestData(cls):
>> cls.author = Author.objects.create()
>> cls.book = cls.author.books.create()
>>
>> def test_relationship_preserved(self):
>> self.assertIs(self.book.author, self.author)
>>
>> Lazily returning `deepcopy'ies and caching returned values in `__dict__`
>> à la
>> `cached_property` should also make sure the slight performance overhead
>> this
>> incurs is minimized.
>>
>> From a check against a few projects and Django's test suite[2] I have only
>> identified a single issue which is that attributes assigned during
>> `setUpTestData` would now have to be `deepcopy()`able but it shouldn't be
>> a blocker given `Model` instance are.
>>
>> In order to allow other possible issues from being identified against
>> existing
>> projects I packaged the proposed feature[3] and made it available on
>> pypi[4]. It
>> requires decorating `setUpTestData` methods but it shouldn't be too hard
>> to
>> apply to your projects if you want to give it a try.
>>
>> Given this reaches consensus that this could be a great addition I'd file
>> a ticket and finalize what I have so far[2].
>>
>> Thank your for your time,
>> Simon
>>
>> [0]
>> https://docs.djangoproject.com/en/1.8/releases/1.8/#testcase-data-setup
>> [1]
>> https://docs.djangoproject.com/en/2.1/topics/testing/tools/#django.test.TestCase.setUpTestData
>> [2]
>> https://github.com/charettes/django/compare/setuptestdata...charettes:testdata
>> [3] https://github.com/charettes/django-testdata
>> [4] https://pypi.org/project/django-testdata/
>>
> --
> 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/08c3a11f-49d2-461b-b6c6-d27c5ba758f8%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2nn5O4ukxo1ismA6nvLNy%2BKH2jOe-7WqvKvYjRKjE7QA%40mail.gmail.com.

Re: Discuss ticket 20264: URLValidator should allow underscores in local hostname

[Adam Johnson]

Hi Pavel

The ticket ( https://code.djangoproject.com/ticket/20264 ) doesn't mention
any specific use cases, and nor have you. What has this behaviour blocked
for you?

Thanks,

Adam

On Tue, 24 Mar 2020 at 12:46, Pavel Savchenko  wrote:

> Hi Folks,
>
> I've just encountered this issue, and it seems Django's URLValidator regex
> for host is trying to abide to RFC 1034 recommendation
>  , when there are many
> sites in the wild that use underscore in their domain name.
>
> Can we please discuss this issue here, so we can eventually decide to
> reopen the ticket (or not) and perhaps allow for a pull-request to fix it?
>
> I found this stackoverflow question helpful, with many answers/comments
> with additional references:
> https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it
>
> Best regards,
> Pavel
>
> --
> 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/6982245f-2b5a-4a32-8fe5-a063c7459b7c%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3PgXz3g%3Dk8BbV%3DaXtgT41PZgv5zmPCYaPHFr2i2%2BQ9%3Dw%40mail.gmail.com.

Re: Discuss ticket 20264: URLValidator should allow underscores in local hostname

[Adam Johnson]

You're right there are two use cases here. It does sound like the pragmatic
approach is to allow underscores in URL's normally, but to preserve the
existing behaviour for those with stricter use cases, like you say.

I can also propose a solution that would still work for both: (deprecate
> and) rename the current class to StrictURLValidator (or
> URLValidatorRFC1034), to still be easily used for the less common scenarios.


This sounds reasonable to me. I'm not sure we'd need the deprecation
period, given we'd only be adding one character to URLValidator. A release
note is typically enough in this situation, but I normally defer to the
fellows for this.

I think that would make Florian happy, although it *has* been seven years
since his closing comment on the ticket.

On Tue, 24 Mar 2020 at 16:41, Pavel Savchenko  wrote:

> Hey folks,
>
> Sorry for not providing a more specific scenario before, was short on time
> and just wanted to kick this off.
>
> The most common scenario that I can think of (and the one that most
> similar to our usage) would be a *form field* on a Django site, that
> allows users to input a URL which is saved and later displayed *as a link
> to* other users (e.g in blogs, comments, CMS systems, etc).
>
> Here's an example of a site, though clearly not a very reputable one:
> http://online_casino_news.hundredpercentgambling.com/ . Note that google
> groups automatically converted this one to a URL for me, and I was able to
> click and follow it both on Chrome and Firefox.
>
> In the above use case, by validating the correctness of the URL, we
> protect a user from making a mistake, but we don't really care about
> adhering to standards beyond that, the usability wins.
>
> There are other use cases, that might care about RFC 952
> <https://tools.ietf.org/html/rfc952>/1034
> <https://tools.ietf.org/html/rfc1034#section-3.5> guidelines about
> hostname. For example, if we're building a hosting or a name server
> management system, or maybe SSL certificates vendor.
> In such cases, it might actually benefit the user if the platform alerts
> on the validity of the hostname chosen by the user (at the very least to
> advise the users).
>
> However, I would guess that the first use case, of taking a URL to store
> and render it as a link, would be more common and thus more frequently
> needing to override the class.
>
> I can also propose a solution that would still work for both: (deprecate
> and) rename the current class to StrictURLValidator (or
> URLValidatorRFC1034), to still be easily used for the less common scenarios.
>
> What do you think?
>
> Best Regards,
> Pavel
>
>
> On Tuesday, March 24, 2020 at 2:36:33 PM UTC+1, Adam Johnson wrote:
>>
>> Hi Pavel
>>
>> The ticket ( https://code.djangoproject.com/ticket/20264 ) doesn't
>> mention any specific use cases, and nor have you. What has this behaviour
>> blocked for you?
>>
>> Thanks,
>>
>> Adam
>>
>> On Tue, 24 Mar 2020 at 12:46, Pavel Savchenko  wrote:
>>
>>> Hi Folks,
>>>
>>> I've just encountered this issue, and it seems Django's URLValidator
>>> regex for host is trying to abide to RFC 1034 recommendation
>>> <https://tools.ietf.org/html/rfc1034#section-3.5> , when there are many
>>> sites in the wild that use underscore in their domain name.
>>>
>>> Can we please discuss this issue here, so we can eventually decide to
>>> reopen the ticket (or not) and perhaps allow for a pull-request to fix it?
>>>
>>> I found this stackoverflow question helpful, with many answers/comments
>>> with additional references:
>>> https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it
>>>
>>> Best regards,
>>> Pavel
>>>
>>> --
>>> 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/6982245f-2b5a-4a32-8fe5-a063c7459b7c%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/6982245f-2b5a-4a32-8fe5-a063c7459b7c%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> --
>> Adam
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developer

Re: AUTH_USER_MODEL refers to model 'restro_app.CustomUser' that has not been installed

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for 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. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Thu, 26 Mar 2020 at 18:12, Dhruv Agarwal  wrote:

> I suppose your problem is that you haven't configured your retro_app
>
> So,You first need to add "retro_app" in list of installed_apps in
> settings.py.
>
> Correct me if I understand the issue wrongly.
>
> --
> 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/8c13a393-cd14-4489-afff-2d7277760683%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2scU_JrzLiqfWDBcZNsN%3D8N4euikBxBLRTwR-tABMzzQ%40mail.gmail.com.

Re: GSoC Mentors

[Adam Johnson]

Happy to help mentor in both realms! 🤗

On Thu, 26 Mar 2020 at 15:59, Carlton Gibson 
wrote:

> Hi David. Thanks.
>
> That makes a few folks that have put their hands up so 👍
>
> On Thu, 26 Mar 2020 at 13:47, David Smith  wrote:
>
>> Hi Carlton,
>>
>> I'm happy to help out with 1), if you think I would be helpful.
>>
>> I will not be of much help with 2) :-)
>>
>> 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/da593286-005f-4a1a-8359-cf8210a1a975%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/CAJwKpyT2EXJ39Y-mdn7OscPwcACnvh_wt33GX08jsRpLFXBSdw%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/CAMyDDM2fh1vZT6PNgQ0mOjGVb875jA4NrS4NVdK9JpCHNst5sw%40mail.gmail.com.

Re: GSOC Student

[Adam Johnson]

Hi Edidiong

The page Asif refers to is this one:
https://code.djangoproject.com/wiki/SummerOfCode2020

I'm not sure if you've contributed much to Django or the ecosystem
(including GraphQL libraries) before. If you don't have much of a track
record of contributions, your application is less likely to be accepted -
see the section "How can I improve my chances of being accepted?". It's
also very late in the day to start on a proposal, given that submissions
close in 2 days :(

Thanks,

Adam

On Sun, 29 Mar 2020 at 05:45, Asif Saif Uddin  wrote:

> you should check the idea page for gsoc 2020 first. then pick a component
> of django internals and find out relevant ticets to create a good proposal
> to solve the problem of any part of django.
>
> On Friday, March 27, 2020 at 4:02:23 PM UTC+6, Edidiong Etuk wrote:
>>
>> Hi, I'm Edidiong, I'd like to be engaged with the GraphQL ORM wrapper,
>> either as a student or just freelancing. How do I begin?
>>
> --
> 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/e7912ad0-bc2b-4faf-9b00-a5c2a4557fb6%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM34p-tfSA5zgdsfDpQScEBLFD5_hB8XvKz7nY9bmPQNLA%40mail.gmail.com.

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

[Adam Johnson]

>
> Currently what I'm figuring out is getting a SQL dump to change SQLite's
> cloning method and implementing an Oracle cloning method. I'm searching
> through Django's documentation and internal code to see if there is a
> ready-made SQL dump method for SQLite and if not I'll search for it in a
> third-party library, and if I still don't find it, I'll start thinking
> about a ground-up implementation using the ORM.
>

SQLite has an online backup API and the "VACUUM INTO" command both of which
can efficiently clone databases: https://sqlite.org/backup.html . I think
they can even copy memory-to-memory with the right arguments.

On Sat, 28 Mar 2020 at 06:59, Ahmad A. Hussein 
wrote:

> Apologies for the late response. I've had to attend to personal matters
> concerning the current crisis we're all facing. All is well though
>
> I should have posted a more detailed post from the get-go. I apologize for
> the lack of clarity as well.
>
> Last week, I initially did exactly what you suggested. I called
> django.setup() in each child process during worker initialization. This
> fixed app registry issues but like you said it isn't enough for testing.
> Test apps and test models were missing and caused tons of errors. Later, I
> read through runtests.py and saw the setup method there; it was exactly
> what I needed since it searched for setup the correct template backend,
> searched for test apps and added them to installed apps, and called
> django.setup(). I passed that method along with its initial arguments into
> the runner so I could call it during worker initialization. That fixed all
> errors related to state initialization. I do wonder though if any
> meaningful time could be saved if we use a cache for setup instead of
> having to call the setup for each process.
>
> The last glaring hole was correct database connections. I had a naming
> mismatch with Postgres and I ended up fixing that through prepending
> "test_" in each cloned database's name during worker initialization. In
> case of the start method being fork, we can safely ignore that step and
> it'll work fine.
>
> Currently what I'm figuring out is getting a SQL dump to change SQLite's
> cloning method and implementing an Oracle cloning method. I'm searching
> through Django's documentation and internal code to see if there is a
> ready-made SQL dump method for SQLite and if not I'll search for it in a
> third-party library, and if I still don't find it, I'll start thinking
> about a ground-up implementation using the ORM.
>
> As for progress on the Oracle cloning method, I'm consulting Oracle
> documentation right now to see if anything has changed in the last 5 years.
> If I don't find anything interesting, I'll start toying around with Shai
> Berger's ideas to see what works and what's performance-costly.
>
> Lastly, testing does seem to be an enigma to think about right now. I've
> thought about tests for both SQLite's and Oracle's cloning method, but I
> can't imagine anything else.
>
> If you have any pointers, suggestions or feedback, I'd love to hear it!
> And thank you for your help so far.
>
>
> Regards,
> Ahmad
>
>
> On Thursday, March 26, 2020 at 10:39:28 AM UTC+2, Aymeric Augustin wrote:
>>
>> Hello Ahmad,
>>
>> I believe there's interest for supporting parallel test runs on Oracle,
>> if only to make Django's own test suite faster.
>>
>> I'm not very familiar with spawn vs. fork. As far as I understand, spawn
>> starts a new process, so you'll have to redo some initialization in the
>> child processes. In a regular application, this would mean calling
>> `django.setup()`. In Django's own test suite, it might be different; I
>> don't know. Try it and see what breaks, maybe?
>>
>> Hope this helps :-)
>>
>> --
>> Aymeric.
>>
>>
>>
>> On 23 Mar 2020, at 20:22, Ahmad A. Hussein  wrote:
>>
>> Django's parallel test runner works through forking processes, making it
>> incompatible on Windows by default and incompatible in macOS due to a
>> recent update. Windows and macOS both support spawn and have it enabled by
>> default. Databases are cloned for each worker.
>>
>> To switch from fork to spawn, state setup will be handled by spawned
>> processes instead of through inheritance via fork. Worker’s connections to
>> databases can still be done through get_test_db_clone_settings which
>> changes the names of databases assigned to a specific worker_id; however,
>> SQLite's cloning method is incompatible with spawn.
>>
>>
>> SQLite’s cloning method relies on it both being in-memory and fork as
>> when we fork the main process, we retain SQLite's in-memory database in the
>> child process. The solution is to get a SQL dump of the database and throw
>> it into the target cloned databases. This is also the established standard
>> in handling MySQL’s cloning process. Both Postgresql's and MySQL's cloning
>> methods are independent of fork or spawn and won't require any modification.
>>
>> Oracle has not been implemented in the parallel test run

Re: Suggestions for Django restframework project

[Adam Johnson]

Hi!

I think 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. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/3.0/faq/help/

Thanks for your understanding,

Adam

On Sun, 29 Mar 2020 at 17:08, sanka nanaji 
wrote:

> Hi everyone,
>
> Could someone suggest me some good project to practice on django
> restframework. I read document and saw two YouTube channels o. Django
> restframework.
>
> Regards,
> Nanaji.
>
> --
> 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/CAHKe4p5V7Za8KNnybUZOj72jCuof78qpby%2B7W0v5fgd9FmWwYg%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/CAMyDDM3ZKdDKQD3c_KwdrFYeafDiejHvbQD%3D-WcThYju2KUM1A%40mail.gmail.com.

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

[Adam Johnson]

ory and retain the resultant databases into
>>> our spawned workers since spawned child processes don't share an
>>> environment with parent processes.
>>>
>>> There are two possible workarounds:
>>>  1. To copy our in-memory database
>>> into an on disk database using VACUUM INTO and subsequently restore it into
>>> in-memory during worker initialization
>>>  2. Pass a string query resulting
>>> from calling Connection.iterdump() into worker initialization and call that
>>> to restore copies of the database into in-memory for every child process.
>>>
>>> I'm testing out both now to see if there are any major differences.
>>> There might be a performance difference between them. I'm also checking if
>>> there are any unexpected errors that might arise.
>>>
>>> Regards,
>>> Ahmad
>>>
>>> On Sun, Mar 29, 2020 at 5:56 PM Adam Johnson  wrote:
>>>
>>>> Currently what I'm figuring out is getting a SQL dump to change
>>>>> SQLite's cloning method and implementing an Oracle cloning method. I'm
>>>>> searching through Django's documentation and internal code to see if there
>>>>> is a ready-made SQL dump method for SQLite and if not I'll search for it 
>>>>> in
>>>>> a third-party library, and if I still don't find it, I'll start thinking
>>>>> about a ground-up implementation using the ORM.
>>>>>
>>>>
>>>> SQLite has an online backup API and the "VACUUM INTO" command both of
>>>> which can efficiently clone databases: https://sqlite.org/backup.html
>>>> . I think they can even copy memory-to-memory with the right arguments.
>>>>
>>>> On Sat, 28 Mar 2020 at 06:59, Ahmad A. Hussein <
>>>> ahmadahusse...@gmail.com> wrote:
>>>>
>>>>> Apologies for the late response. I've had to attend to personal
>>>>> matters concerning the current crisis we're all facing. All is well though
>>>>>
>>>>> I should have posted a more detailed post from the get-go. I apologize
>>>>> for the lack of clarity as well.
>>>>>
>>>>> Last week, I initially did exactly what you suggested. I called
>>>>> django.setup() in each child process during worker initialization. This
>>>>> fixed app registry issues but like you said it isn't enough for testing.
>>>>> Test apps and test models were missing and caused tons of errors. Later, I
>>>>> read through runtests.py and saw the setup method there; it was exactly
>>>>> what I needed since it searched for setup the correct template backend,
>>>>> searched for test apps and added them to installed apps, and called
>>>>> django.setup(). I passed that method along with its initial arguments into
>>>>> the runner so I could call it during worker initialization. That fixed all
>>>>> errors related to state initialization. I do wonder though if any
>>>>> meaningful time could be saved if we use a cache for setup instead of
>>>>> having to call the setup for each process.
>>>>>
>>>>> The last glaring hole was correct database connections. I had a naming
>>>>> mismatch with Postgres and I ended up fixing that through prepending
>>>>> "test_" in each cloned database's name during worker initialization. In
>>>>> case of the start method being fork, we can safely ignore that step and
>>>>> it'll work fine.
>>>>>
>>>>> Currently what I'm figuring out is getting a SQL dump to change
>>>>> SQLite's cloning method and implementing an Oracle cloning method. I'm
>>>>> searching through Django's documentation and internal code to see if there
>>>>> is a ready-made SQL dump method for SQLite and if not I'll search for it 
>>>>> in
>>>>> a third-party library, and if I still don't find it, I'll start thinking
>>>>> about a ground-up implementation using the ORM.
>>>>>
>>>>> As for progress on the Oracle cloning method, I'm consulting Oracle
>>>>> documentation right now to see if anything has changed in the last 5 
>>>>> years.
>>>>> If I don't find anything interesting, I'l

Re: End of extended support for Django 1.11

[Adam Johnson]

I agree with James, the cutoff date has been more than reasonable.

Also, if there aren't any show-stopping bugs you know about, asking for the
extension of the EOL "by a few weeks" doesn't really mean much. If we were
past the cutoff date, and a high impact, wide reaching bug was found - yes,
maybe I'd be in favour of a temporary extension and a bug fix release. But
there isn't any.

For smaller bug fixes, you can always backport them yourselves to your
fork. You can use the script on
https://code.djangoproject.com/wiki/CommitterTips#AutomatingBackports and
pip install the tarball from github:
https://adamj.eu/tech/2019/03/11/pip-install-from-a-git-repository/ .

On Tue, 31 Mar 2020 at 15:06, James Bennett  wrote:

> The end of support simply means there will be no further releases, and
> any showstopping bugs reported will not be fixed. It doesn't mean
> Django itself will stop working. Also, the decision is in the hands of
> the Technical Board, not the Django Fellows, so the correct process
> would be to request that the Technical Board schedule additional
> support/releases of Django 1.11.
>
> That said, my personal opinion is that both the Python 2 EOL (2020-01)
> and the Django 1.11 EOL (2020-04) were set years in advance;
> organizations which waited until the last minute to do their upgrades
> would simply wait until the last minute again if given an extension,
> and be right back in the same problem. There has to be a cutoff date
> at some point where we just say "sorry, but if you haven't prioritized
> upgrading for years and years, we cannot tie up our open-source
> project's resources because of that". And the announced cutoff, which
> is in line with previous LTS releases of Django, seems as reasonable
> as any other.
>
>
> On Tue, Mar 31, 2020 at 6:57 AM Daniela Kim  wrote:
> >
> > Mariusz,
> > Thank you for your response.
> >
> > Would it be possible for the Django Fellows to vote to extend Django
> 1.11's EOL by a few weeks? For those of us with a large Django codebase, we
> were bitten by the onerous Python 2->3 upgrade and so the start of our
> Django upgrade was delayed by several weeks.
> >
> > Also, given the current global situation with Covid-19, including (1)
> work-life difficulties/transitions for organizations and our developers and
> (2) an evermore global online presence with further exposure to online
> security threats, a graceful extension would be very much appreciated.
> >
> > Thank you for your consideration.
> > Daniela
> >
> >
> > On Thursday, March 26, 2020 at 1:15:18 AM UTC-4, Mariusz Felisiak wrote:
> >>
> >> No, support of Django 1.11 ends on 1st April.
> >>
> >> 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/f5718ec3-6041-40db-93fd-b7b8b354e64a%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/CAL13Cg_WBtBU%3D_ZrSPfgWfzP0U2PGsFXvcCMCY8GCcDRybS5tQ%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/CAMyDDM2ooXoGuJ3GuFSg%2B3hBra8GQPiUSmJek0EmEEQOYMuuFw%40mail.gmail.com.