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

['Kye Russell' via Django developers (Contributions to Django itself)]

Hi all,

I find that the signal-to-noise ratio on this mailing list is (by my 
determination) quite bad around this time of year.

Is a move to the forum still on the cards?

Kye
On 6 Dec 2022 at 7:16 AM +0800, Andrew Godwin , wrote:
> I did some investigation of moving django-users and django-developers to the 
> Forum right after DjangoCon; I wanted to see if we could import all the old 
> posts too, which we probably could, but I'm not entirely sure of the utility 
> of that.
>
> I will say that the forum is a lot easier to moderate - the ability to 
> moderate after a post has gone out, rather than gating all posts behind 
> approval if they're untrusted, is a big step in itself, not to mention the 
> ability to remove sensitive or offensive content once it's posted.
>
> Andrew
>
> > On Monday, November 28, 2022 at 10:01:17 PM UTC-7 m...@kye.id.au wrote:
> > > IMO django-announce and django-updates serve a very different purpose and 
> > > I would be against moving them if it were suggested.
> > >
> > > I am incredibly strongly in favour of moving django-developers and 
> > > django-users to the forums. IMO being able to more easily trap people 
> > > misusing this list as a tech support channel is itself reason enough to 
> > > move. Beyond that, I’d argue that the plentiful UX issues with Google 
> > > Groups, and mailing lists in general, certainly don’t do the community 
> > > any favours in terms of getting more people on board.
> > >
> > > Kye
> > > On 28 Nov 2022 at 11:40 PM +0800, 'Tobias McNulty' via Django developers 
> > > (Contributions to Django itself) , wrote:
> > > > As someone who only just joined the forum -- I'm +1:
> > > >
> > > > • The forum has seen great adoption from what I can tell (nearly half 
> > > > the number of posts as django-developers during the same time period, 
> > > > not bad given the mailing list's head start in subscribers).
> > > > • It seems beneficial to house future conversations in a single place, 
> > > > e.g., so members don't need to subscribe to both the mailing list and 
> > > > forum to get the full picture of current active development, set up two 
> > > > different sets of mail filters to tag things appropriately, etc...
> > > >
> > > > Would the plan be to switch django-users as well? I think similar 
> > > > arguments could be made for consolidating those...
> > > >
> > > > (On the other hand, I see little value in switching django-announce and 
> > > > django-updates, but I'm not necessarily opposed to it either, 
> > > > especially if there's a way to import the subscribers to those lists...)
> > > >
> > > > Cheers,
> > > >
> > > > Tobias McNulty
> > > > Chief Executive Officer
> > > > tob...@caktusgroup.com
> > > > www.caktusgroup.com
> > > >
> > > >
> > > > > On Mon, Nov 28, 2022 at 9:05 AM Carlton Gibson  
> > > > > wrote:
> > > > > > Hey Roger,
> > > > > >
> > > > > > Indeed it does. You can set up Email Mode (that may not be the 
> > > > > > actual name) and it’ll work just like a mailing list.
> > > > > >
> > > > > > You can also subscribe to just a particular category, so the 
> > > > > > Internals one would map to the discussion on this list.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Monday, 28 November 2022, Roger Gammans 
> > > > > >  wrote:
> > > > > > > Hi
> > > > > > >
> > > > > > > I can't speak for others, but I personally STRONGLY value the 
> > > > > > > fact that this discussion happens in my inbox, not on yet another 
> > > > > > > website.
> > > > > > >
> > > > > > > But perhaps the forum still supports this reading mode?
> > > > > > >
> > > > > > > On Mon, 2022-11-28 at 05:38 -0800, Carlton Gibson wrote:
> > > > > > > > Hi all.
> > > > > > > >
> > > > > > > > Given the issues with Tom's access to the mailing list here, 
> > > > > > > > and the fact that the Forum has been active for a few years 
> > > > > > > > now, and is a great success, I'd like to revisit whether we can 
> > > > > > > > move on-mass (all few of us :) over there?
> > > > > > > >
> > > > > > > > We'd enjoy the benefits of a much nicer system. We'd not have 
> > > > > > > > issues such as the current, and we'd be one less item in the 
> > > > > > > > pocket of a mega-corp. (You can rank those as you will :)
> > > > > > > >
> > > > > > > > Initially when this can up (a long time ago) Andrew and Tom 
> > > > > > > > discussed whether we could import the history here into the 
> > > > > > > > forum. I think that's unnecessary. We can still access the 
> > > > > > > > history here (until such a day as Google takes it away) at 
> > > > > > > > worst -- but, rather, if we can get an archive we could import 
> > > > > > > > it into read-only Datasette instance[0] — and that would likely 
> > > > > > > > be good enough.
> > > > > > > >
> > > > > > > > Can we move now?
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > >
> > > > > > > > Kind Regards,
> > > > > > > >
> > > > > > > > Carlton
> > > > > > > >
> > > > > > > >
> > > > > > > > [0]: I'd happily 

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

['Kye Russell' via Django developers (Contributions to Django itself)]

IMO django-announce and django-updates serve a very different purpose and I 
would be against moving them if it were suggested.

I am incredibly strongly in favour of moving django-developers and django-users 
to the forums. IMO being able to more easily trap people misusing this list as 
a tech support channel is itself reason enough to move. Beyond that, I’d argue 
that the plentiful UX issues with Google Groups, and mailing lists in general, 
certainly don’t do the community any favours in terms of getting more people on 
board.

Kye
On 28 Nov 2022 at 11:40 PM +0800, 'Tobias McNulty' via Django developers 
(Contributions to Django itself) , wrote:
> As someone who only just joined the forum -- I'm +1:
>
> • The forum has seen great adoption from what I can tell (nearly half the 
> number of posts as django-developers during the same time period, not bad 
> given the mailing list's head start in subscribers).
> • It seems beneficial to house future conversations in a single place, e.g., 
> so members don't need to subscribe to both the mailing list and forum to get 
> the full picture of current active development, set up two different sets of 
> mail filters to tag things appropriately, etc...
>
> Would the plan be to switch django-users as well? I think similar arguments 
> could be made for consolidating those...
>
> (On the other hand, I see little value in switching django-announce and 
> django-updates, but I'm not necessarily opposed to it either, especially if 
> there's a way to import the subscribers to those lists...)
>
> Cheers,
>
> Tobias McNulty
> Chief Executive Officer
> tob...@caktusgroup.com
> www.caktusgroup.com
>
>
> > On Mon, Nov 28, 2022 at 9:05 AM Carlton Gibson  
> > wrote:
> > > Hey Roger,
> > >
> > > Indeed it does. You can set up Email Mode (that may not be the actual 
> > > name) and it’ll work just like a mailing list.
> > >
> > > You can also subscribe to just a particular category, so the Internals 
> > > one would map to the discussion on this list.
> > >
> > >
> > >
> > > On Monday, 28 November 2022, Roger Gammans  
> > > wrote:
> > > > Hi
> > > >
> > > > I can't speak for others, but I personally STRONGLY value the fact that 
> > > > this discussion happens in my inbox, not on yet another website.
> > > >
> > > > But perhaps the forum still supports this reading mode?
> > > >
> > > > On Mon, 2022-11-28 at 05:38 -0800, Carlton Gibson wrote:
> > > > > Hi all.
> > > > >
> > > > > Given the issues with Tom's access to the mailing list here, and the 
> > > > > fact that the Forum has been active for a few years now, and is a 
> > > > > great success, I'd like to revisit whether we can move on-mass (all 
> > > > > few of us :) over there?
> > > > >
> > > > > We'd enjoy the benefits of a much nicer system. We'd not have issues 
> > > > > such as the current, and we'd be one less item in the pocket of a 
> > > > > mega-corp. (You can rank those as you will :)
> > > > >
> > > > > Initially when this can up (a long time ago) Andrew and Tom discussed 
> > > > > whether we could import the history here into the forum. I think 
> > > > > that's unnecessary. We can still access the history here (until such 
> > > > > a day as Google takes it away) at worst -- but, rather, if we can get 
> > > > > an archive we could import it into read-only Datasette instance[0] — 
> > > > > and that would likely be good enough.
> > > > >
> > > > > Can we move now?
> > > > >
> > > > > Thanks.
> > > > >
> > > > > Kind Regards,
> > > > >
> > > > > Carlton
> > > > >
> > > > >
> > > > > [0]: I'd happily 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/101f4e6d-9b83-47ab-bb1b-b571402e037dn%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/4a329eadd5606c2f94aa5638e079800f1914d0d7.camel%40gammascience.co.uk.
> > > --
> > > You received this message because you are subscribed to the Google Groups 
> > > "Django developers (Contributions to Django itself)" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an 
> > > email to django-developers+unsubscr...@googlegroups.com.
> > > To view this discussion on the web visit 
> > > 

Re: Generated Field

[Kye Russell]

I’d love to see this!

Kye
On 13 Apr 2022, 7:05 PM +0800, Mariusz Felisiak , 
wrote:
> Related tickets:
>
> - https://code.djangoproject.com/ticket/31300: Add function-based virtual 
> fields on PostgreSQL and Oracle.
> - https://code.djangoproject.com/ticket/31565: Support GENERATED ALWAYS 
> columns for MySQL and PostgreSQ
>
> Related DEP:
>
> - https://github.com/django/deps/pull/39 - Refactor ORM with VirtualField and 
> CompositeField
>
> and an accepted ticket for non-database backed calculated field (see 
> discussion 
> https://groups.google.com/g/django-developers/c/ADSuUUuZp3Q/m/eZGYZv74AQAJ):
>
> - https://code.djangoproject.com/ticket/28822 - Add DBCalculatedField to 
> model to annotate models automatically
> >
> >
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/5bf85475-4d97-4249-bd68-baf9906d9fffn%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/c91dbc3a-0447-4633-b2c8-75ac287973cb%40Spark.

Re: Issue with documentation page

[Kye Russell]

Harsh, Jacob.

There was certainly a certificate expiration issue 12-24 hours ago, reported on 
this mailing list and also experienced by me, who isn’t using a proxy.

It looks to be resolved now.

Kye
On 4 Feb 2022, 12:57 AM +0800, Jacob Rief , wrote:
> The SSL certificate for docs.djangoproject.com was issued on December, 6th 
> and is valid until March 6th, so that's not the problem.
>
> You're accessing that site through a misconfigured proxy, that's the problem.
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/1d74a73e-4d4f-4bbc-b803-00081b2f9948n%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/1ff63989-b47d-4f53-bac4-7342a478e57d%40Spark.

Re: Combining multiple aggregations with annotate()

[Kye Russell]

I haven’t looked at the current warning in a while but I do remember thinking 
that it could be more prominent. 

Kye

> On 5 Jan 2022, at 10:16 pm, Niccolò Mineo  wrote:
> 
> I would be in favor of a real time information about the issue.
> Il giorno mercoledì 5 gennaio 2022 alle 15:13:17 UTC+1 Yonas ha scritto:
>> Hello,
>> 
>> There's a ticket opened 13 years ago explaining a problem with combining 
>> multiple aggregations with annotate(). And the solution appears to be 
>> documenting the problem.
>> 
>> But for people skimming through the documentation, the message might not be 
>> noticeable. Showing the problem in a warning message could help draw 
>> attention better. It's used here and in other places in the doc.
>> 
>> In addition to documenting the problem, raising an exception might prevent 
>> developers from spending hours trying to debug their code.
>> 
>> While the problem is recognized, there's an example in the documentation 
>> that shows the usage of multiple aggregations.
>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/1e17088d-dd5f-481e-94c7-2b4d2bcfa91dn%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/8FDCF601-5ECB-430C-BAB4-6BC27F4308F5%40kye.id.au.

Re: Case Sensitive Usernames

[Kye Russell]

The RFC does not specifically disallow case-insensitive email addresses, no.

This all feels like a moot point. Messing with user data (read: not rejecting 
it) before it hits the database for ‘technical’ reasons is certainly swimming 
against the tide. You hardly ever see it these days. If you need 
case-insensitive comparison of email addresses (e.g. for an auth check), then 
just do a case-insensitive comparison. This is why things like 
CI[Text/Char/Email]Field exist. If we are appealing to authority, Gmail’s new 
account sign up form preserves user case.

Kye
On 13 Dec 2021, 12:52 PM +0800, אורי , wrote:
> Hi,
>
> As far as I know, Google, which runs mail servers for about 85% of users 
> worldwide (Gmail + Workspace users), email addresses and usernames are case 
> insensitive. So if you send me for example an email to u...@speedy.net, I 
> will receive it. Although according to the RFC it should have been bounced 
> (actually I'm not sure, maybe it's up to the domain manager (speedy.net / 
> gmail.com) to decide if to bounce it or not). This is a de-facto standard - I 
> know companies that always send me mail to my email address in uppercase, and 
> I think they do it to all of their customers. I don't think they have 
> delivery problems with customers.
>
> אורי
> u...@speedy.net
>
>
> > On Mon, Dec 13, 2021 at 6:39 AM Benny  wrote:
> > > That’s a matter of perspective - RFC 5321 documents it pretty well. While 
> > > I agree that, speculatively, the majority of servers may normalize emails 
> > > to lower-case, it’s not officially recognized. I’m a fan of exhaustive 
> > > documentation, but this is a standard set by an arguably higher authority.
> > >
> > > Benny
> > >
> > > > On Dec 12, 2021, at 10:15 PM, Arthur Pemberton  
> > > > wrote:
> > > >
> > > > The current behaviour is an undocumented gotcha. It should at least be 
> > > > mentioned in the documentation. Very few major login based platforms 
> > > > are case sensitive, so it should be at least mentioned in the 
> > > > documentation that by default applications built with Django would be 
> > > > different in that regard.
> > > >
> > > > Arthur
> > > >
> > > > > On Sun, 12 Dec 2021 at 23:01, Benny  wrote:
> > > > > > IMO this treads dangerously close to what I call a “Django Gotcha” 
> > > > > > - There exist some implementations, where if you’re not paying 
> > > > > > attention, it’ll come back to bite you in the keister. One example 
> > > > > > would be the test runner coercing DEBUG=False in an effort for 
> > > > > > tests to more accurately reflect a production environment.
> > > > > >
> > > > > > Normalization is a nightmare all on its own without having to 
> > > > > > implicitly introduce it.
> > > > > >
> > > > > > Benny
> > > > > >
> > > > > > > On Dec 12, 2021, at 9:40 PM, Kye Russell  wrote:
> > > > > > >
> > > > > > > Strong -1 on overriding user intent on capitalisation, especially 
> > > > > > > for email addresses as the RFC stipulates that the local part of 
> > > > > > > an email address is case sensitive, this is just rarely 
> > > > > > > practiced. There are much better solutions out there 
> > > > > > > (CI[Text|Char]FIeld in Postgres, etc) that enforce 
> > > > > > > case-insensitivity purely for comparison operations which is 
> > > > > > > where you really want it, but without overriding user intent wrt 
> > > > > > > what case the user wants to use in their email or username.
> > > > > > >
> > > > > > > Django could maybe do with easing the process of implementation 
> > > > > > > for case-insensitive fields outside of Postgres. I’m not familiar 
> > > > > > > enough with the other RDBMSs to know how workable that is. But 
> > > > > > > the answer is certainly not discarding user intent.
> > > > > > >
> > > > > > > Kye
> > > > > > > On 13 Dec 2021, 11:32 AM +0800, Arthur Pemberton 
> > > > > > > , wrote:
> > > > > > > > A setting to convert all usernames to lowercase would be good 
> > > > > > > > too -- that's my preference overall in general. However I 
> > > > > > > > hav

Re: Case Sensitive Usernames

[Kye Russell]

Strong -1 on overriding user intent on capitalisation, especially for email 
addresses as the RFC stipulates that the local part of an email address is case 
sensitive, this is just rarely practiced. There are much better solutions out 
there (CI[Text|Char]FIeld in Postgres, etc) that enforce case-insensitivity 
purely for comparison operations which is where you really want it, but without 
overriding user intent wrt what case the user wants to use in their email or 
username.

Django could maybe do with easing the process of implementation for 
case-insensitive fields outside of Postgres. I’m not familiar enough with the 
other RDBMSs to know how workable that is. But the answer is certainly not 
discarding user intent.

Kye
On 13 Dec 2021, 11:32 AM +0800, Arthur Pemberton , wrote:
> A setting to convert all usernames to lowercase would be good too -- that's 
> my preference overall in general. However I haven't yet seen how best that 
> could/would be accomplished.
>
> For simpler uses case where I'm just sub-classing AbstractUser and not 
> customizing the auth backend, I've taken to overriding 
> UserManager.get_by_natural_key to allow for case-insensitive logins. Though 
> really, I probably should add a signal handler to force username to lowercase.
>
> Arthur
>
> > On Sunday, December 12, 2021 at 11:21:32 AM UTC-5 Uri wrote:
> > > Hi Arthur,
> > >
> > > I would recommend users of Django to use only lowercase usernames. And if 
> > > they insist that the username is an email address, also convert it to 
> > > lowercase. Otherwise you can have 3 separate users uri, Uri, and uRI, or 
> > > 3 separate users with email addresses u...@example.com, u...@example.com, 
> > > and u...@example.com (or even u...@example.com). Maybe it's better to add 
> > > an optional setting to enforce usernames to be lowercase. And by the way 
> > > also alphanumeric. You don't want "!@#" to be a username on your system 
> > > (or the user's name in Chinese or Hebrew).
> > >
> > > It's interesting that this ticket is 15 years old and still not 
> > > completely resolved.
> > >
> > > By the way, when people type their email address, some programs 
> > > (including browsers) convert the first letter to uppercase, and I have 
> > > received email addresses from people with the first letter in uppercase, 
> > > although their true address is lowercase. I don't think you want this 
> > > uppercase letter to appear on your database in the email field.
> > >
> > > אורי
> > > (Uri)
> > >
> > > u...@speedy.net
> > >
> > >
> > > > On Sun, Dec 12, 2021 at 6:02 PM Arthur Pemberton  
> > > > wrote:
> > > > > Especially with the ability to set USERNAME_FIELD to "email", it 
> > > > > would be really useful to at least have a well documented warning 
> > > > > that usernames are case-sensitive in Django.
> > > > >
> > > > > I've been using Django for years, and even I forget that fact some 
> > > > > times. Until I start Googling and come across [1].
> > > > >
> > > > > Ideally, it would be great to have a setting (or model field) that 
> > > > > would allow easy switching to case insensitive usernames.
> > > > >
> > > > > Arthur Pemberton
> > > > >
> > > > > 
> > > > >
> > > > > [1] https://code.djangoproject.com/ticket/2273
> > > > > --
> > > > > You received this message because you are subscribed to the Google 
> > > > > Groups "Django developers (Contributions to Django itself)" group.
> > > > > To unsubscribe from this group and stop receiving emails from it, 
> > > > > send an email to django-develop...@googlegroups.com.
> > > > > To view this discussion on the web visit 
> > > > > https://groups.google.com/d/msgid/django-developers/9a5e1df3-778d-4993-8c32-57870fafd8f9n%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/c2bb1b2f-e1ac-4770-8989-ebb0fdc47a2cn%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/2b02d741-e49d-486e-b92d-92d0e233b9e9%40Spark.

Re: Errors

[Kye Russell]

As Adam has stated, this is not a forum to discuss issues with your code. 
Please see the links in his reply. 

Kye

> On 11 Aug 2021, at 8:35 pm, Umar Farooq  wrote:
> 
> 
> Sorry code screenshots
> 
>> On Wed, 11 Aug 2021, 5:27 PM Rana Zain,  wrote:
>> Okay I am sending screenshot.
>> 
>> 
>> 
>>> On Tuesday, August 10, 2021 at 6:26:42 PM UTC+5 Adam Johnson wrote:
>>> 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.2/faq/help/ . This will help you find 
>>> people who are willing to support you, and to ask your question in a way 
>>> that makes it easy for them to answer.
>>> 
>>> Thanks for your understanding and all the best,
>>> 
>>> Adam
>>> 
 On Tue, 10 Aug 2021 at 13:05, Rana Zain  wrote:
 I am facing this errors :
 
 > ',' or ')' expected
 > Unexpected indent
 > Statement expected, found Py:DEDENT
 
 for the last 2,3 days. Kindly help me out.
>>> 
 -- 
>>> 
 You received this message because you are subscribed to the Google Groups 
 "Django developers (Contributions to Django itself)" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to django-develop...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/89e0b61f-25c5-4438-9a7d-20ffb0de82fen%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/fa42e3bf-a965-4c57-885f-383a75b1c86cn%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/CAPpmBN_UP1nyz-Xig_LWnVwwHJFmUJxc4N22DnYF-GXuaiLjOw%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/373D10F8-6811-4884-9D51-7F01CAC82AC5%40kye.id.au.

Re: Do people actually squash migrations?

[Kye Russell]

I’ve never successfully squashed my migrations to any material degree, but I’ve 
chalked that up to lack of doing it with any regularity. I suspect that 
squashing works a lot better if you aren’t trying to clean up a mess of 
hundreds of migrations files over 5 years, which is where I find myself!

Kye
On 12 May 2021, 9:31 AM +0800, Matthew Pava , wrote:
> I've had similar issues. I just avoid squashing anymore. It's just not with 
> the pain, and having so many little files that get looked at a minimal amount 
> of time isn't worth fretting over. Saying that, I'd love to get it fixed...
>
> Sent from my Verizon, Samsung Galaxy smartphone
> Get Outlook for Android
>
> From: 'Mike Lissner' via Django developers (Contributions to Django itself) 
> 
> Sent: Tuesday, May 11, 2021 7:50:31 PM
> To: Django developers (Contributions to Django itself) 
> 
> Subject: Do people actually squash migrations?
>
> I have a pretty big django project, and since I created the 100th migration 
> within one of its apps today, I thought I'd finally do some squashing. It 
> hasn't gone well, but I eventually got the data migrations cleaned up.
>
> Finally, I run it, and it runs smack into a CircularDependencyError, as 
> described here:
>
> https://code.djangoproject.com/ticket/23337
>
> Basically, from what I understand, after the squash you have one migration 
> that depends on various others from your other apps. Naturally, that totally 
> falls over, because can't go from this series of migrations:
>
> app1: migration 1
> app2: migration 1
> app2: migration 2
> app1: migration 2
>
> To, well...any series of migrations in which migration 1&2 from app1 or app2 
> have been squashed. The docs have something to say about this*, but it feels 
> like this must affect practically any biggish project.
>
> Stackoverflow also has a variety of dubious (and very complex) advice (read 
> it and weep):
>
> https://stackoverflow.com/questions/37711402/circular-dependency-when-squashing-django-migrations
>
> So, my question is: Do people actually use squashmigrations with success? And 
> if not, is it reasonable to consider deprecating it or fixing the bug, or 
> updating the docs to loudly say it largely doesn't work? I'm surprised the 
> issue above has so little movement since it was created seven years ago.
>
> Maybe it's just me? If not, it'd be nice to do something to help future 
> people with ambitions of a simple squash.
>
> Thanks,
>
>
> Mike
>
> * Note that model interdependencies in Django can get very complex, and 
> squashing may result in migrations that do not run; either mis-optimized (in 
> which case you can try again with --no-optimize, though you should also 
> report an issue), or with a CircularDependencyError, in which case you can 
> manually resolve it.
> To manually resolve a CircularDependencyError, break out one of the 
> ForeignKeys in the circular dependency loop into a separate migration, and 
> move the dependency on the other app with it. If you’re unsure, see how 
> makemigrations deals with the problem when asked to create brand new 
> migrations from your models. In a future release of Django, squashmigrations 
> will be updated to attempt to resolve these errors itself. [Author's note: 
> These sentences really leave me blowing in the wind...maybe I can figure out 
> what they mean, I guess? I thought squashing was supposed to be easy.]
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/87f449bc-d653-427a-ac28-879ee0701c8bn%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/SN6PR05MB3951135EF4ECFE249F51ED4BF1529%40SN6PR05MB3951.namprd05.prod.outlook.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/76351f53-d185-4dd1-9979-6a7c73015ef5%40Spark.

Re: The cotent types framework unreasonably limits model name length.

[Kye Russell]

I’ve never needed a Django model with a name that long, but I don’t think
it’s the framework’s place to make those sorts of assumptions if it doesn’t
need to, especially for what I see as little to no gain.


On 11 August 2020 at 11:18:49 am, אורי (u...@speedy.net) wrote:

How can a class name be more than 100 characters? Can you give an example?

A limit of 100 characters seems reasonable to me, maybe even 60 would be
enough.

אורי
u...@speedy.net


On Tue, Aug 11, 2020 at 6:06 AM Richard Campen 
wrote:

> Hello
>
> I have hit what I feel is an arbitrary limit on the length of a django
> model class name. I am using the PostgreSQL backend, which smartly
> truncates table names above a certain size (normally 63 characters) which
> means in theory a table name can be of indeterminate length, as PostgreSQL
> will truncate it appropriately. However, if the model class name is greater
> than 100 characters than an error is thrown when saving the model name to
> the `django_content_type` model as the `ContentType.model` field uses a
> CharField with a limit of 100. This arbitrarily restricts the size of the
> model name when the db backend can handle it fine.
>
> I tried to go back in time to figure out if there was any context in
> setting the `ContentType.model` field max_length at 100 chars, but it was
> made before the Django project was migrated to git.
>
> I feel it would be best to switch this field to a TextField, as even 255
> characters seems an unreasonable limit to impose when the db backend can
> support longer names, though perhaps having a smaller (but configurable)
> max_length on the TextField would still be desirable.
>
> What are peoples feelings on this?
>
> Cheers,
> Richard
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/26478a0a-5809-449f-b17d-d7223e2cfb3do%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/CABD5YeFdA95UhJex%2BERf1pM-groRiUjO5tyLv300wSRjcWkGSQ%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-yknfid%3DcKToiWpnLm3Ky6xoCpXz15a-jeLJobtRgxtvj%3DA%40mail.gmail.com.

Re: Welcome email

[Kye Russell]

This issue is exacerbated by similarly unaware / uncaring mailing list users 
responding to support requests.

What is the best path forward here?

> On 10 Jul 2020, at 3:09 pm, Jure Erznožnik  wrote:
> 
> 
> I too volunteer for the screening job. 
> 
> LP,
> Jure
> 
> On 09/07/2020 16:10, Peter Inglesby wrote:
>> Hi folks,
>> 
>> Is there any moderation for posts from new users?  It can be enabled, and 
>> I'd be willing to be part of a team that filters posts from new users.
>> 
>> All the best,
>> 
>> Peter.
>> 
>> On Thu, 9 Jul 2020 at 13:59, Adam Johnson  wrote:
>>> I think that's a good improvement, not bikeshedding :)
>>> 
>>> On Thu, 9 Jul 2020 at 13:17, Shai Berger  wrote:
 Sorry for the bike-shedding, but I think the text should drop the
 "using Django" language. The people who come here with these questions
 clearly think of themselves as developers, not users.
 
 IMO It should go something like,
 
 Welcome to django-developers, the mailing list for discussion
 of the development of Django itself.
 
 This mailing list is not for support developing apps and
 websites with Django. For support, please follow the "Getting
 Help" page: https://docs.djangoproject.com/en/3.0/faq/help/ .
 This page will direct you to the django-users mailing list or
 other resources, so you can find people who are willing to
 support you, and to ask your question in a way that makes it
 easy for them to answer.
 
 Thanks,
 
 The Django Community
 
 
 
 On Wed, 8 Jul 2020 11:50:16 +0100
 Adam Johnson  wrote:
 
 > Okay I'm in favour. That said, there's already a banner on the groups
 > page:
 > 
 > This group is for the discussion of the development of Django itself.
 > If
 > > you want to ask questions about using Django, please post on
 > > django-users.
 > >
 > 
 > Suggested wording, adapted from my templated reply:
 > 
 > Welcome to django-developers, the mailing list for discussion of the
 > > development of Django itself.
 > >
 > > This mailing list is not for support using Django. For support,
 > > please follow the "Getting Help" page:
 > > https://docs.djangoproject.com/en/3.0/faq/help/ . This page will
 > > direct you to the django-users mailing list or other resources, so
 > > you can find people who are willing to support you, and to ask your
 > > question in a way that makes it easy for them to answer.
 > >
 > > Thanks,
 > >
 > > The Django Community
 > >
 > 
 > Who has access to add this? Someone from the DSF board, the ops team,
 > or the fellows?
 > 
 > On Mon, 6 Jul 2020 at 00:02, Ahmad A. Hussein
 >  wrote:
 > 
 > > +1 on this. Here's the relevant feature
 > >  I found.
 > >
 > >
 > > Ahmad
 > >
 > > On Sun, Jul 5, 2020 at 7:58 PM Adam Johnson  wrote:
 > >
 > >> I can't find a google groups feature that would allow this. Do you
 > >> know of one? It might otherwise require a custom bot.
 > >>
 > >> On Sun, 5 Jul 2020 at 16:14, Arvind Nedumaran
 > >>  wrote:
 > >>
 > >>> Oh I understand. I meant we could include the distinction in the
 > >>> welcome email and possibly a link to the other list.
 > >>>
 > >>> That may reduce the number of people who may be looking for help
 > >>> but end up here mistakenly?
 > >>>
 > >>> Get Outlook for Android 
 > >>>
 > >>> --
 > >>> *From:* django-developers@googlegroups.com <
 > >>> django-developers@googlegroups.com> on behalf of אורי
 > >>>  *Sent:* Sunday, July 5, 2020 8:39:22 PM
 > >>> *To:* Django developers (Contributions to Django itself) <
 > >>> django-developers@googlegroups.com>
 > >>> *Subject:* Re: Welcome email
 > >>>
 > >>> I think because this list is called Django developers and what we
 > >>> call "Django users" are also developers who use Django. But they
 > >>> are developers.
 > >>>
 > >>> אורי
 > >>> u...@speedy.net
 > >>>
 > >>>
 > >>> On Sun, Jul 5, 2020 at 5:59 PM Arvind Nedumaran
 > >>>  wrote:
 > >>>
 > >>> Hey everyone,
 > >>>
 > >>> I notice that people who try to find support on using Django
 > >>> mistakenly post in this list and sometime usually has to write an
 > >>> explanation about how this is the wrong place.
 > >>>
 > >>> Could we possibly as a welcome email whenever someone joins the
 > >>> group?
 > >>>
 > >>> Just a suggestion.
 > >>>
 > >>> Best,
 > >>> Arvind
 > >>>
 > >>> --
 > >>> You received this message because you are subscribed to the Google
 > >>> Groups "Django developers 

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

[Kye Russell]

Lol.


On 8 July 2020 at 10:00:11 am, Divyesh Khamele (pythonmatedivy...@gmail.com)
wrote:

Hi Charles,
Divyesh here,have 4+ years of experience to work as a Django developer. I
 can help you on this.

You need to hire me.

Hourly rate: 8$/hr.

Best,
D

On Wednesday, 8 July 2020, Carles Pina i Estany  wrote:

>
> Hi,
>
> I haven't read all this thread in detail and I might go off-topic. Sorry
> about that.
>
> On Jul/07/2020, '1337 Shadow Hacker' via Django developers  (Contributions
> to Django itself) wrote:
> > Do we really need DJANGO_ prefix on env vars ? In my first years of
>
> I know when having a variable named "DEBUG" instead of "DJANGO_DEBUG"
> affected me... due to a bug in Thunderbird and how, in that machine,
> variables for the Django project were set.
>
> Thunderbird on Debian didn't run at all because the launcher has a bug
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960230 ). If DEBUG is
> set it doesn't run. If the bug wasn't there, well, it would have ran in
> DEBUG mode probably or if Django named it DJANGO_DEBUG it would have not
> affected Thunderbird. I thought of prefixing variables when possible to
> avoid these interactions.
>
> Cheers,
>
> --
> Carles Pina i Estany
> https://carles.pina.cat
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/20200707213034.GA2308%40pina.cat.
>
-- 
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAEV-ETTAG-c7UbUqUtowWRKM-kYNPZ3SzaqzL8O-h58sKiHeTQ%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-ykkM%2BRrztEmEVTBuDxuasXao%2BZMQXGLhQ_ANV6aaJSwE%2Bg%40mail.gmail.com.

Re: The blacklist / master issue

[Kye Russell]

Git’s default branch name is a bit of a misnomer, however it refers to a
master-slave relationship:
https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html

Kye


On 16 June 2020 at 4:24:32 pm, Fran Hrženjak (fran.hrzen...@gmail.com)
wrote:

Meaning "owner of slaves" is only one of many meanings of the word, and not
its primary meaning:

https://dictionary.cambridge.org/dictionary/english/master
https://www.merriam-webster.com/dictionary/master

Renaming the master branch would mean we agree that this one meaning is
somehow more important and should be elevated above all other meanings.
Even though some of those other meanings apply much more closely in the
case of git branches:

> "having chief authority, dominant"
> "an original from which copies can be made"

To me this looks like a final revenge of the slavers. They are all long
dead and gone, their social order destroyed and condemned as it should be,
and yet here we are in 2020 giving up useful words as if only the savers'
use was correct and the rest of us were wrong ever since.

Master/slave database, that is (was) a completely different argument. But
please let's keep the master branch.

Even if the change is simple for Django and for its users, somebody made a
great point recently (on another topic here) that we cannot change the
internet. There are numerous references to "master" out there which will
become obsolete and a tripping stone for newcomers.

-0 from me.

 * What about everyones' master's degrees?
 * If a dog can have a master, then surely git branches can have a master
branch.
 * Rembrandt was a master painter.
 * Related words: masterpiece, masterful, mastery, remastered (movies),
mistress...

-- 
Fran


On Tue, 16 Jun 2020 at 09:10, Sanskar Jaiswal 
wrote:

> Just my 2 cents on this discussion as a junior contributor. I am very fond
> of how inclusive and progressive the Django community is.
> With that said, I believe that we shall definitely try to stop using the
> term blacklist for “bad/unwanted” things. If this change makes even only a
> few contributors, more comfortable, I think we should move forward with the
> same.
>
> Thanks
> Sanskar
>
> On Tue, 16 Jun 2020 at 12:30, Jure Erznožnik 
> wrote:
>
>> +1 on this discussion progression. I too struggled with certain
>> expressions in my earlier English-learning days, but today the used
>> expressions don't carry any unnecessary baggage for me as my understanding
>> of them is purely technical. So, while I myself don't have a problem with
>> them, I can see that others might.
>>
>> I'd also dare to say there shouldn't be much flak to take anyway. The
>> cause seems OK, but there is heightened pressure due to recent events. I
>> would say this alone is the only thing that I see might be an issue: why
>> exactly now?
>>
>> LP,
>> Jure
>> On 15/06/2020 23:31, Aymeric Augustin wrote:
>>
>> Hello,
>>
>> In the context of access control, blacklist / whitelist makes sense only
>> if the reader has a preconceived assumption that black = bad, illegal,
>> forbidden / white = good, legal, authorized. You can probably see where I'm
>> going.
>>
>> Sure, blacklist / whitelist has nothing to do with race to start with,
>> but I find the parallel with Apartheid sufficiently obvious to make it
>> embarrassing, certainly because I'm not a native English speaker and I
>> don't have enough background on what has racial overtones and what doesn't.
>>
>> I mean, I had been living in the US for several months whet someone had
>> to tell me the difference between "to screw" and "to screw up". (I'm
>> grateful.) Do you really expect a guy like me to know that "blackface" has
>> racial overtones but "blacklist" doesn't, and thus interpret the words
>> correctly?
>>
>> Besides, the connection didn't exist in the first place, but when people
>> start making it, can we still pretend it doesn't exist? If I wanted to
>> troll a linguist, I'd say it's akin to pretending that words people
>> actually use don't exist until they're written in a dictionary ;-)
>>
>> Lastly, another argument for the statu quo is that humans are good at
>> interpreting words based on context, so "black" in "blacklist" isn't a
>> problem. However, I counter that humans are even better at making
>> connections and detecting patterns, even subconsciously and sometimes even
>> when the pattern doesn't actually exist. That's quite likely to happen here.
>>
>> I agree that this isn't as clear cut as master / slave. That must be why
>> it took us six years to go from the master / slave discussion to the
>> blacklist / whitelist discussion.
>>
>> No one's gonna get confused on the meaning regardless of whether we make
>> the change or not. This is "just" a political marker. It doesn't have one
>> correct answer. It has several answers whose correctness vary over time.
>>
>> I think we'll make the change at some point. Some progressives will hate
>> us for taking so much time. Some conservatives will hate us for being
>> 

Re: Django wizard form issue

[Kye Russell]

Hi Yeswanth,

It is not appropriate to send tech support requests to this mailing list.

Wizard views are part of ‘django-formtools’ which is a third-party package.  

Adam’s response contains suggestions for other support channels where you may 
be able to have your questions answered.

Kye

> On 31 May 2020, at 1:11 pm, Yeswanth Kumar  wrote:
> 
> 
> Hi Adam,
> 
> I have an development issue, That's why i raised an issue.
> 
>> On Fri, May 29, 2020 at 3:25 AM Adam Johnson  wrote:
>> 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/ . This will help you find 
>> people who are willing to support you, and to ask your question in a way 
>> that makes it easy for them to answer.
>> 
>> Thanks for your understanding and all the best,
>> 
>> Adam
>> 
>>> On Thu, 28 May 2020 at 15:51, Yeswanth Kumar  
>>> wrote:
>>> Hi all,
>>> 
>>> 
>>> I have an issue with the Django wizard form directs to payment gateway page,
>>> 
>>> Is it possible with wizard form?
>>> 
>>> And how to include the payment gateway code in Django wizard form views
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to django-developers+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/1c03831c-b5d1-410b-b072-02068325daee%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/CAMyDDM17Zz0Mtks9NA2qRpELCuG5M%3DwRkDOejJxcL0f8mB97BA%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/CANOa%2BtCZUm8-UT_87pR0f7uCxW96cLbutzpbQYyyTMQsfw3pDg%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/5FF48A2B-B67B-4F36-B84C-BD8D3F089FEA%40kye.id.au.

Re: Admin accessibility

[Kye Russell]

Hi all,

I am legally blind. Accessibility discussions tend to largely revolve
around contrast and screen readers (which I do not use) as it’s easy to
measure for (albeit poorly without actually trying to use a screen reader
yourself, which nobody tends to do).

I am unsure if I have any valuable / unique perspective to share, and I
probably don’t, but I am always happy to help. I have wanted an excuse to
get involved in the framework's development and this would be as good a
time as any.

The one thing I will say (and this doesn’t come from any lived experience,
rather what I’ve heard) is not to rely to heavily on automated
accessibility metrics, especially when it comes to screen reader
friendliness. An interface can tick all the automated boxes but still be
terrible to use. Just as with other user interfaces, automation can only
get us so far and additional manual checking would be worthwhile.

Kye




On 21 May 2020 at 9:33:51 pm, Tom Carrick (t...@carrick.eu) wrote:

Hi Adam,

> Which checker did you use?

I had a brief check with a few. Firefox's devtools, Lighthouse, and
WebAIM's WAVE browser extension. WAVE is quite nice in that it shows the
problems directly on the page, but they all give more or less the same
information. If Lighthouse can be integrated into the CI it seems the most
logical option. Lighthouse also gives a 0 - 100 score metric for each page,
which would be nice as part of a coverage-style CI process, i.e. the score
can remain the same or increase, but a decrease will fail the test.

> Would you be able to work on this on an ongoing basis? If you know others
who are interested, perhaps we could even form a Django a11y team, just
like we have an i18n team.

I'm happy to work on this on an ongoing basis. Thinking over the idea of an
a11y team, at first I thought it would have too narrow a scrope as it only
really concerns the admin, but I realised it also concerns the docs, the
djangoproject website, and other sites under the django org (django-people
and so on), so perhaps it's worth doing. That said, I don't have any
physical disabilities to speak of. My eyes are pretty bad, small text can
be a problem, but that's about it. It would be good to get some feedback
from people that this directly affects, but I don't know of many. It'd also
be hugely beneficial of course if any a11y team includes people with
physical disabilities or at least experience with it. I can only
immediately think of one person in the Django community that might fit, so
I will reach out to them and ask if they'd be interested in giving any
input here, but more voices would be useful.

For the low-hanging fruit, I will run Lighthouse on some more pages and
write some tickets up when I get some time, hopefully over the weekend.

Cheers,
Tom

On Thu, 21 May 2020 at 14:04, Adam Johnson  wrote:

> Hi Tom
>
> It's a laudable goal to make the admin accessible. Thank you for doing the
> research on currently laws and guidelines.
>
> I haven't audited the entire admin, but I have run a checker through some
>> pages.
>>
>
> Which checker did you use? I see Google's Lighthouse checks for many
> accessibility issues: https://web.dev/lighthouse-accessibility/
>
> I think fixing any "low hanging fruit" would be acceptable PR's right now.
>
> Setting a target and keeping to it would be harder though. Documentation
> is easy to write, but it can easily be forgotten/ignored, so I'd prefer a
> CI solution. One potential CI solution is running admin tests through the
> Lighthouse CLI.
>
> There will certainly add an ongoing maintenance cost. Would you be able to
> work on this on an ongoing basis? If you know others who are interested,
> perhaps we could even form a Django a11y team, just like we have an i18n
> team.
>
> On Tue, 19 May 2020 at 12:11, Tom Carrick  wrote:
>
>> Sorry, long post incoming.
>>
>> The admin currently has some accessibility issues. Not a huge amount,
>> actually, but they should be fixed regardless. I hope I don't need to
>> convince anyone here of the importance of accessibility, but I'll try to
>> make the case as briefly as possible for the benefit of the wider community.
>>
>> There is a trend towards stronger accessibility laws - there is a good
>> roundup of them here: https://www.w3.org/WAI/policies/ - and I'll come
>> back to this later. Most of these cover the public sector and small
>> segments of the private sector, but there's also an overview of some laws
>> used against private entities more generally here:
>> https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines#Legal_obligations
>>
>> I should make it clear that I'm not a lawyer and have no idea if any of
>> this would apply to the admin, since it's not intended for general
>> consumption, so I think I'd rather make this point: Developers and other
>> people using the admin - "staff users" of some kind - can have disabilities
>> too, and we should be catering for them, especially since the remedies are
>> not at all 

Re: Removing url() ?

[Kye Russell]

Excuse the frankness of my reply, but I really don’t see the point in any
of this.

Perhaps I am not working at a scale where this becomes a legitimate issue.
However I have upgraded more Django projects than I could possibly care to
count, usually between LTS versions. Almost all of these upgrades have
occurred in an agency / contractor setting where every hour counts…so I am
extremely sensitive to pointless API churn without benefit to the user.
Django changes like the one being discussed (which is essentially a name
change) have *never* been an area of concern when compared with actual
changes to the mechanics of Django, and I am not saying that those changes
are not warranted.

I don’t believe that url() is enough of a special case that this proposal
wouldn’t introduce a slippery slope scenario that’d result in a lot of
deprecation shim cruft in Django. The mental overhead of dealing with a
codebase filled with deprecation shims is taxing, and not something that
I’d wish on volunteer open source developers.

I am extremely thankful for Django’s deprecation process and its relatively
long LTS periods. My experience has been that the current deprecation
process is sufficient, and my feeling from my perspective as a Django
‘user’ is that it is sufficient in this case.

Django should not be built with the premise that project code should never
need to be updated. Practical (volunteer time) reasons aside, these sorts
of policy decisions can leave a framework in the dust as it hinders
evolution. Moving my projects from Django to something else because of an
inevitable deterioration in Django’s comparative value proposition will
take up way more of my time than replacing url() with re_path(), or even
path()…

I am sure that there are more 'enterprise-focused' web frameworks that
offer the sort of support you are after. Perhaps something written in Java
with a EULA? ;-).


On 6 May 2020 at 5:43:01 am, James Bennett (ubernost...@gmail.com) wrote:

On Tue, May 5, 2020 at 2:24 PM Collin Anderson 
wrote:
> If exception/special treadment is an issue, then I'd suggest making this
an official policy change going forward. I would be much happier if all of
the examples you gave were still around with warnings. All of those
upgrades were annoying. I think an ultra-ultra-extended deprecation cycle
would be a good precedent. I think it makes Django more attractive as a
potential platform for people to build their website on. I don't see it
getting in the way of future evolution. Could you say more?

If you'd like Django to commit to never removing anything, and instead
to preserve every piece of documented API forever, I'm sure the DSF
will be happy to accept the generous monetary donation you no doubt
intend to make in order to assist with that task, which I assume
you'll be willing to provide on an ongoing basis for... well, forever.
An initial contribution of a few million would help to get this
rolling, and we could set up recurring billing for the future
payments.

And I'm not joking about that. Every piece of deprecated code is a
maintenance burden; it requires keeping full regression tests around
and responding to bug reports and considering the possible interaction
of every new feature that ever gets introduced. All of which comes at
a cost of time and effort and -- if it's done by the Django Fellows,
which a lot of that work is -- a cost of literal cash money out of the
DSF's pocket.

Or we could allow Django to continue shedding deprecated APIs on a
predictable and documented cycle. I really do understand that it's
annoying to put in the effort to keep up to date. I lived through
magic-removal. I've done multi-version upgrades of massive codebases
basically by myself in the past. I remember them vividly, and I know
they're not fun. And there are platforms out there which have the
kinds of "nothing is ever removed" compatibility policies you're
advocating for. But Django isn't one of them, and I don't think it
should be or, at this point in its history, can be: to work at all,
that kind of policy has to be introduced early on and has to be
allowed to influence a lot of fundamental design decisions that, in
Django's case, were already made many years ago. If we introduce such
a policy now, the very first thing i'll do is go file a DEP asking for
the old "magic" ORM to be put back, and manipulators along with it.

Anyway. As Adam mentioned, there's a good reason to put the DEP 201
URL routing in front of people's eyes in a way they'll actually
notice. Our only truly reliable tool for doing that is deprecation
backed up by the knowledge that when we deprecate something, it will
end up removed. DEP 201 set out a deprecation schedule for url(); in
hindsight I wish it were shorter and just followed the normal post-2.0
policy of one LTS-to-LTS cycle, but at this point it's too late to
change that. I'll still argue quite strongly that the deprecation
period should not be made any longer, and I'll argue with every breath

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

[Kye Russell]

Personally I think that the current name does a fairly good job of conveying 
the effect, and this is coming from someone who doesn’t explicitly understand 
the internal process and is merely inferring it. 

However my anecdote doesn’t negate what we all see around the internet, so I 
suppose it can be improved. 

I am a strong -1 on adding words like “dangerously” to the method name. I feel 
that method names are not the place for warnings like that. I do not like the 
precedent that it sets for other potentially unsafe methods within the Django 
codebase, and i believe that it’d result in unnecessarily verbose project code. 

Kye Russell
Sent from my iPhone

> On 19 Feb 2020, at 5:11 pm, Adam Johnson  wrote:
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ECEDF3F5-2245-4FEA-850E-54FDC43A7891%40kye.id.au.

Re: PasswordResetView not validating existing emails

[Kye Russell]

As I recall, and correct me I’d I’m wrong, but Django’s auth package doesn’t 
contain user registration views. Thus while I understand your point it does not 
serve as justification to change this functionality in the core auth code.  

It is inherent in the functionality of a typical user registration flow that an 
enumeration attack be possible. If your business rules require this, there 
isn’t a 100% fix that doesn’t introduce its own usability issues. Your 
registration view should have its own rate limiting / automation detection to 
heavily mitigate enumeration attacks that aren’t targeted to a specific user. 

Furthermore not all web projects with a sign in functionality have public user 
registration. My day job project does not have registration views as access is 
granted via invitation only. I imagine that I am not alone. 

I am certain that in our regular external penetration testing, an enumeration 
attack possible on a password reset view would be flagged as an issue. This 
should serve as a good indicator that it is a bad idea. 

I appreciate the usability issues inherent in this decision (at work we deal 
with the resulting support requests almost every day) but I am still a -1 on 
changing the functionally as the security risk is too large in my use case, and 
lots of developers may not be aware of the issue at all. 

Perhaps at best it could be included as an opt-in setting. I still feel unsure 
about that. 

Kye Russell
Sent from my iPhone

> On 9 Jan 2020, at 9:32 am, Sanyam Mittal  wrote:
> 
> 
> Those enumeration attacks can be also be done on Sign-up page as Sign-up page 
> if Sign-up page uses email ID to register. Mostly Sign-up pages contains 
> Email fields in them. Secondly there are many (majority) websites which are 
> keeping these Validators on PasswordReset so why don't we keep that default.
> 
> Neither documentation has any suggestions on how to achieve email Validation 
> for beginners
> 
> 
>> On Thu, 9 Jan 2020, 06:57 Fran Hrženjak,  wrote:
>> FWIW, for me the question here is why isn't Django applying the same 
>> protection agains enumeration attacks on sign-up pages?
>> 
>> 
>> 
>>> On Thursday, 9 January 2020 02:08:16 UTC+1, SANYAM MITTAL wrote:
>>> PasswordResetView returns a success message for emails not in database also.
>>> 
>>> Problems Faced
>>> 
>>> If the user is not Registered but strongly thinks they are registered and 
>>> have forgotten the password they would keep trying to get Reset email.
>>> If they've typed a wrong email in PasswordResetForm. They would be 
>>> expecting a reset email with reset URL but wouldn't receive any mail nor 
>>> any Validation Error would be raised that wastes a lot of time of the User
>>> Reference:
>>> ​https://github.com/django/django/blob/0f843fdd5b9b2f2307148465cd60f4e1b2befbb4/django/contrib/auth/views.py#L208
>>> 
>>> As mentioned in 
>>> documentation​​https://docs.djangoproject.com/en/stable/topics/auth/default/#django.contrib.auth.views.PasswordResetView
>>> 
>>> This prevents information leaking to potential attackers
>>> 
>>> Although a potential attacker can easily get these information from 
>>> Sign-Up/Register page as Validation error is raised when a Duplicate Email 
>>> Address is entered during sign-up.
>>> 
>>> If there's not a Unique email Validation during Sign-up there are chances 
>>> that multiple users get registered with same email (if user mistakenly 
>>> types someone else's email) and Password Reset email is sent multiple times 
>>> for different Users which is more risky.
>>> 
>>> Facebook, Netflix and many more also raises a Validation Error when non 
>>> registered email is entered
>>> 
>>> Thanks for your time.
>>> 
>>> Sorry I don’t know the real necessity of not validating the email but this 
>>> really causes confusion and wastes the User’s precious 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/06dcb212-a2b9-4e9d-8bb7-a1cca36fc699%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 
&

Re: PasswordResetView not validating existing emails

[Kye Russell]

This is an intentional protection against enumeration attacks.

Kye Russell
Sent from my iPhone

> On 9 Jan 2020, at 9:08 am, SANYAM MITTAL  wrote:
> 
> 
> PasswordResetView returns a success message for emails not in database also.
> 
> Problems Faced
> 
> If the user is not Registered but strongly thinks they are registered and 
> have forgotten the password they would keep trying to get Reset email.
> If they've typed a wrong email in PasswordResetForm. They would be expecting 
> a reset email with reset URL but wouldn't receive any mail nor any Validation 
> Error would be raised that wastes a lot of time of the User
> Reference:
> ​https://github.com/django/django/blob/0f843fdd5b9b2f2307148465cd60f4e1b2befbb4/django/contrib/auth/views.py#L208
> 
> As mentioned in 
> documentation​​https://docs.djangoproject.com/en/stable/topics/auth/default/#django.contrib.auth.views.PasswordResetView
> 
> This prevents information leaking to potential attackers
> 
> Although a potential attacker can easily get these information from 
> Sign-Up/Register page as Validation error is raised when a Duplicate Email 
> Address is entered during sign-up.
> 
> If there's not a Unique email Validation during Sign-up there are chances 
> that multiple users get registered with same email (if user mistakenly types 
> someone else's email) and Password Reset email is sent multiple times for 
> different Users which is more risky.
> 
> Facebook, Netflix and many more also raises a Validation Error when non 
> registered email is entered
> 
> Thanks for your time.
> 
> Sorry I don’t know the real necessity of not validating the email but this 
> really causes confusion and wastes the User’s precious 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/5e164f97.1c69fb81.aec39.cb9b%40mx.google.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/83DA8592-0294-4149-A812-AC461DAA5A17%40kye.id.au.

Re: Forms submitted by bots

[Kye Russell]

Due to the cat-and-mouse nature inherent in this sort of request, and the 
community’s expectation of feature stability in Django, I feel that a 
third-party app is not the appropriate place for a feature like this. 

If the Django documentation doesn’t already do so, perhaps it could mention 
this issue in the Forms section, so new developers / Django users are aware of 
it. 

Kye Russell
Sent from my iPhone

> On 17 Dec 2019, at 7:36 am, אורי  wrote:
> 
> 
> Hi,
> 
>> On Sun, Dec 15, 2019 at 9:55 AM James Bennett  wrote:
>> Since this discussion seems to be exclusively about how to use Django, 
>> please take it to the django-users mailing list; the django-developers list 
>> is not an appropriate place for this topic.
> 
> This is about my feature request "Prevent bots from submitting forms.":
> https://code.djangoproject.com/ticket/31085 
> 
> אורי 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CABD5YeELxLx3MTjYaVRrYRuuaAPyzhRe9nx6qjD8dxa%2B6XN9dw%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/4C06950D-2AAE-4FAC-BFC7-A5B1A7DD355E%40kye.id.au.

Re: Forms submitted by bots

[Kye Russell]

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.

Re: Suggestions on where to contribute

[Kye Russell]

The ORM! Good luck!

> On 1 Oct 2019, at 4:20 pm, Fredrik Malmfors  wrote:
> 
> Hello everyone!
> 
> 
> 
> As part of a university course, where the goal is to contribute to a large 
> open source project, I chose django. I’m currently in the process of studying 
> the structure of the source code.
> 
> 
> 
> Anyway, if anyone has a suggestion for a django component to study more in 
> depth (perhaps where the most work is needed), let me know. I’d also love to 
> get suggestions for suitable accepted tickets to start looking into.
> 
> 
> 
> I do understand that django is a pretty mature project already, but I’d like 
> to at least attempt to contribute. It doesn’t have to be code, it could as 
> well be documentation. 
> 
> 
> 
> Kind regards,
> 
> Fredrik
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/aca46f0d-535d-4934-8ae8-ffc1175b47d5%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/4CA62A9B-3F9F-4041-A239-92356F2FA0D8%40kye.id.au.

Re: The floatformat filter sometimes returns "-0" rather than "0"

[Kye Russell]

Sounds reasonable. As you said, the template tags (well, this one) seem to be 
to prepare things for human consumption, not to expose computer science 
intricacies.

If I saw this presented on a website, as a ‘developer-user’, I’d probably 
consider it a bug. I’m unsure of other uses of this filter though.

Kye Russell
Sent from my iPhone

> On 12 Sep 2019, at 12:54 pm, Sky Christensen  wrote:
> 
> Hi,
> 
> I'd like to discuss reopening this wontfix'ed ticket: 
> https://code.djangoproject.com/ticket/30761
> 
> The issue is that for values between 0 and -0.5, the floatformat filter 
> returns "-0", whereas I think that most people would expect it to return "0".
> 
> The ticket was wontfix'ed because "this behavior is consistent with builtin 
> round() and -0 exists in floating-point arithmetic".
> 
> Can I propose that in this case the better way to decide the result that it 
> should produce is to ask what an ordinary person would expect to see, rather 
> than what's consistent with a particular Python function?
> 
> When humans round -0.3 to the nearest whole number, we express the result as 
> 0, not -0. Given that the point of template tags and filters is to make data 
> more human-readable, I think returning "0" is preferable in this case than 
> returning "-0".
> 
> If this ticket is reopened, I'll be happy to submit a patch for it.
> 
> Cheers,
> 
> Sky
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/aec9450abcb511a0bb4a020c770a0483%40skychristensen.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/1F8DEBF9-FBEB-4A1C-BE3B-CA9D4507E702%40kye.id.au.

Re: Django LTS support time

[Kye Russell]

IIRC such a service could threaten the DSF’a nonprofit / charity status. There 
are certainly third parties that offer this, including OS distributions that 
will backport security fixes as has been mentioned.  

Kye Russell
Sent from my iPhone

> On 12 Aug 2019, at 11:34 pm, Patryk Zawadzki  wrote:
> 
> W dniu sobota, 10 sierpnia 2019 18:19:07 UTC+2 użytkownik Uri napisał:
>> 
>> Thanks for your feedback. Eventually I found out that the Django Crispy 
>> Forms issue was a CSS bug in our CSS code. Anyway not related to Crispy 
>> Forms, it may take a lot of time and effort to upgrade Django for us, and I 
>> would prefer to keep using Django 1.11 as much as we can.
> 
> If upgrading looks like a lot of work today, it will be even more work in a 
> year or two. Today a single dependency may be blocking you from the upgrade. 
> Unless you have a contract with that dependency's maintainer, there's no 
> guarantee of the situation ever improving. Soon you may not be able to add a 
> dependency because it will require a newer version of Django. Anecdotal 
> evidence: we have an internal policy of not supporting Django versions older 
> than the current LTS unless we have someone paying for the effort.
> 
> As for the LTS policy: I don't think the current one cuts it. There are 
> companies who are fine with upgrading once every two years but these 
> companies could probably also do it every release or two. Then there are 
> companies who want LTS support and these are often projects that need to run 
> largely unmodified for five to ten years. I don't think the current LTS 
> support helps them in any way. I think a better option (for both sides) would 
> be if the foundation offered paid support for the releases nominated as LTS 
> and if that support became more expensive every year (to compensate for 
> having to maintain outdated software and to motivate the company to 
> eventually allocate the budget to a proper upgrade). Paid support could also 
> include features like early vulnerability disclosure and instructions for 
> determining whether an issue was exploitable in a particular project.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/c4fd117b-830e-4274-b563-902973316344%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/60E5ED20-012A-40E9-AF92-3D66C2009234%40kye.id.au.

Re: Django LTS support time

[Kye Russell]

Just to throw in my two cents here. I work in an agency environment (lots of 
projects, very few staff) and we follow the LTS cycle for almost all projects. 
In my experience, jumping between LTS versions has - all things considered - 
not been that big of an issue for us. I still sometimes wake up in a cold sweat 
thinking about migrating from South to Django migrations, but that is a thing 
of the past for most people these days.

If I were working on a product with guaranteed ongoing work I’d just jump from 
major version to major version.

This is not meant to invalidate anyone else’s experience, but in my experience, 
the current deprecation process is sufficient. 

Kye Russell
Sent from my iPhone

> On 11 Aug 2019, at 12:17 am, אורי  wrote:
> 
> Thanks for your feedback. Eventually I found out that the Django Crispy Forms 
> issue was a CSS bug in our CSS code. Anyway not related to Crispy Forms, it 
> may take a lot of time and effort to upgrade Django for us, and I would 
> prefer to keep using Django 1.11 as much as we can.
> 
> אורי
> 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/CABD5YeFihYLbjrcj%2B71_FTyJqR46fCwiPoEtk6mMyJ1CBXQ5Bw%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/A70F9CF4-79BD-4452-ABE5-4C6C159E0483%40kye.id.au.

Re: Thoughts on Django Model attribute (descriptor) inheritance.

[Kye Russell]

I don’t know enough to speak on the reasoning behind the current
implementation, but from the perspective of developer experience, I’ve run
into this a few times, and the current behaviour has felt jarring and
unpythonic.


From: Jarek Głowacki  
Reply: django-developers@googlegroups.com
 
Date: 15 May 2019 at 12:11:15 pm
To: Django developers (Contributions to Django itself)
 
Subject:  Thoughts on Django Model attribute (descriptor) inheritance.

Hi friends,

I've raised a ticket here:
https://code.djangoproject.com/ticket/30427#ticket
Has an associated PR and all.

Looking for some experts in this area to eyeball and drop some
thoughts/opinions, or even better, knowledge as to why we're doing things
this way presently.
I feel Django does class inheritance wrong at the moment -- when building a
Model, it refuses to staple on a class attribute if an ancestor/mixin has
already defined that attribute (with a non-falsey value). One could call it
reverse-MRO behaviour.

It looks like the intention in the past was to stop attributes or field
definitions from stomping on methods defined against the same class that
have the same name, but if anything, I'd rather have this raise a proper
warning if it's problematic, or silently stomp if it's not. Having it not
stomp results in some very unpythonic behaviour.
Have a read of my ticket/PR for further context.

Looking forward to getting this fixed, so I can bubble the fix up to
django-model-utils, and then to my production code. ^.^

Cheers,
Jarek
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to 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/a7da90e7-a72c-482f-b195-eb196ae46e73%40googlegroups.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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANK-ykm7Ch3f%3D%3D4qn0iaj%2BMy9P2BO-YvSdk4Ygs4gPbg5-xmtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Kye Russell]

This is something discussed af length on the black issue tracker and not
something the author wishes to change.

On Mon, 15 Apr 2019 at 4:47 pm, Dmitriy Sintsov 
wrote:

> Why can't it use mixed quotes, single quotes for all strings except the
> strings that contain single quote characters? I think mixed syntax of
> strings is made in various programming languages so both single and double
> quotes can be used inside strings not having to use ugly backslash
> escaping. Maybe you or someone can create such feature request in black
> repo? Why the people do not like mixed quotes strings and try to eliminate
> such great feature? Aesthetical issues are very much biased and enforcing
> these automatically is not always a good idea. Does the switching to double
> quote string makes the code error prone and safer? Probably not. Just some
> voluntary personal choice.
>
>
> On Monday, April 15, 2019 at 2:02:49 AM UTC+3, charettes wrote:
>>
>> I was and and I'm still bugged by how black decided to go for double
>> quotes instead of single ones. Even if it's backed some valid arguments it
>> left all the projects following PEP 8's recommendations over the years with
>> this git blaming loss trade off. From past experimentation with large'ish
>> projects following PEP8's guideline string quotes changes represented well
>> over 50% of the diff and there's no way to turn off only this form of
>> string normalization, it's all or nothing. At $WORK we even went as far as
>> forking the project to switch to use single quotes instead[0]. I understand
>> requiring the use of a fork is not a feasible solution for Django but I
>> just wished there was an option to stick to single quotes to reduce the
>> cost of adoption for such projects without loosing all the other nifty
>> string formatting goodies[1] /rant
>>
>> Even if I don't completely agree with black's formatting choices and the
>> sometimes quite unnatural code it generates my past month's usage at work
>> and the adoption of the project in the Python ecosystem that made it's way
>> in most IDE makes me mostly share the same feeling as Aymeric; it's not
>> always pretty but not having to think about it makes it worth it. I suggest
>> we stick to disabling string normalization to reduce the noise generated by
>> the migration though.
>>
>> Cheers,
>> Simon
>>
>> [0] https://github.com/zapier/black/pull/1
>> [1] https://github.com/ambv/black#strings
>>
>> Le dimanche 14 avril 2019 09:40:10 UTC-4, Aymeric Augustin a écrit :
>>>
>>> Hello,
>>>
>>> I'm strongly in favor of adopting black with the default options.
>>>
>>> In my opinion, it's the first Python code formatter that passes the bar
>>> of "on average, does better than any single programmer". Trying to enforce
>>> something else manually is a waste of energy that produces worse results.
>>>
>>> I like nicely formatted code and I hate some of what black produces,
>>> typically on Django model definitions. However, I've seen the benefits of
>>> an automated code formatter, even on projects where I write almost all of
>>> the code.
>>>
>>> I'm positive the benefits will be great on Django, where you can tell
>>> when a module was (re)written just by looking at the style. Yes, there are
>>> some downsides, but it's clearly a good tradeoff.
>>>
>>> Regarding the migration strategy, converting one package at a time
>>> sounds good, because then we can proof-read the Big Diff and perhaps tweak
>>> the code where the result really hurts the eyes.
>>>
>>> Most of Django's style guide will still applies, as it's mostly
>>> conventions about naming things, ordering declarations, etc.
>>>
>>> Best regards,
>>>
>>> --
>>> Aymeric.
>>>
>>>
>>>
>>> On 13 Apr 2019, at 13:52, Herman S  wrote:
>>>
>>> Hi.
>>>
>>> I propose that Django starts using 'black' [0] to auto-format all Python
>>> code.
>>> For those unfamiliar with 'black' I recommend reading the the projects
>>> README.
>>> The short version: it aims to reduce bike-shedding and non value-adding
>>> discussions; saving time reviewing code; and making the barrier to entry
>>> lower
>>> by taking some uncompromissing choices with regards to formatting.  This
>>> is
>>> similar to tools such as 'gofmt' for Go and 'prettier' for Javascript.
>>>
>>> Personally I first got involved contributing to Django couple of weeks
>>> back,
>>> and from anecdotal experience I can testify to how 'formatting of code'
>>> creates
>>> a huge barrier for entry. My PR at the time went multiple times back and
>>> forth
>>> tweaking formatting. Before this, I had to research the style used by
>>> exploring
>>> the docs at length and reading at least 10-20 different source – and
>>> even those
>>> were not always consistent. At the end of the day I felt like almost 50%
>>> of the
>>> time I used on the patch was not used on actually solving the issue at
>>> hand.
>>> Thinking about code formatting in 2019 is a mental energy better used
>>> for other
>>> things, and it feels unnecessary that core 

Development story for CBV FormViews using GET

[Kye Russell]

Hi,

Sometimes it is appropriate to for a HTML form to use the GET method for
submission (usually search / filter forms).

My impression has always been that in order to build a FormView-based view
that acts on GET data, you have to override a few methods on your class
(which involves understanding how FormView works). Even as someone with a
fairly good understanding of these classes, I sometimes have to reference a
previously-written example to make sure I've got it right.

I am aware of the existence of django-filter[0] which takes care of this
for you, however at times I find it hard to justify adding it to a project
just to deal with this.

I have the following questions:

* Is my understanding of the current process correct, or is there an easier
way that I've missed?
* Is this documented anywhere? I looked at the Django 'working with forms'
documentation[1], and whilst it discusses the different scenarios in which
you'd use GET vs POST, it does not seem to discuss implementations in a CBV
context.
* Is there enough of a generic use-case where FormView / FormMixin /
ProcessFormView could be altered to support this? Or are there subtleties /
nuances in each implementation that make a generic solution hard to develop?

Sorry if this is the wrong avenue to discuss this. I am approaching it from
the position of wanting to alter Django to better support this use case,
but I'm aware that I may have just missed a Blessed method in the docs.

Kye

[0]: https://github.com/carltongibson/django-filter
[1]: https://docs.djangoproject.com/en/2.1/topics/forms/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/CANK-ykkMtxezA9cHN8jQ_czLn6OYtdDn6JYbjNgASyyqHH-aAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Exposing custom views in admin index page

[Kye Russell]

I understand that overly extending the admin interface is a common anti
pattern, but this still feels within reason to me. Extending the admin
interface in this way has for me personally felt like a bit of a black box.

On Wed, 6 Mar 2019 at 7:40 pm, mrts  wrote:

> Hello!
>
> Django ModelAdmin class has a nice way to create custom admin views with
> get_urls(). What is missing however is a way to expose them in the admin
> index page.
>
> Frank Wiles created the (now abandoned) django-admin-views package [1] as
> a workaround and there are many questions regarding this in StackOverflow
> [2][3][4][5].
>
> What do you think about exposing custom views in admin index page via a
> new ModelAdmin.extra_views attribute?
> extra_views would be a list of dictionaries/objects with 'url' and 'name'
> fields.
>
> They would be visible in the index page with the following change to
> django/contrib/admin/templates/admin/index.html:
>
> ---
> ../venv/Lib/site-packages/django/contrib/admin/templates/admin/index.html
>  2019-02-28 01:22:12.767388100 +0200
> +++ templates/admin/index.html  2019-03-06 12:57:22.070586600 +0200
> @@ -43,6 +43,15 @@
>  
>  {% endif %}
>  
> +{% if model.extra_views %}
> +  {% for view in model.extra_views %}
> +
> +{{ view.name
> }}
> +
> +
> +
> +  {% endfor %}
> +{% endif %}
>  {% endfor %}
>  
>  
>
> Best regards,
> Mart
>
> ---
>
> [1] https://github.com/frankwiles/django-admin-views
> [2]
> https://stackoverflow.com/questions/37512818/how-to-add-custom-page-to-django-admin-with-custom-form-not-related-to-any-mode
> [3]
> https://stackoverflow.com/questions/53712723/add-a-link-to-custom-django-admin-view
> [4]
> https://stackoverflow.com/questions/5693519/django-custom-view-into-admin-page
> [5]
> https://stackoverflow.com/questions/49176113/make-new-custom-view-at-django-admin
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To 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/2f3c-7078-4bc7-b62d-7cf66acc3bec%40googlegroups.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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANK-ykmsFL0L6SNawVH1nYW0s6e81vw9PiuZjNzCajYfiiuPVw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Official Django Docker Container Deprecated

[Kye Russell]

Agreed. As someone that Dockerizes all of their Django development I can
speak to how opinionated such an image would HAVE to be.

It can certainly be done, but I don’t think it should.

There is also an implied security / maintenance burden so unfortunately
even if it were appropriate, it’s not exactly work that doesn’t come with a
clear ongoing commitment.

On Thu, 28 Feb 2019 at 9:04 pm, Tom Forbes  wrote:

> I think the point we are trying to make is that it’s fundamentally not a
> good thing to try and distribute a one-size fits all docker image for a
> specific framework.
>
> For reference here is one you can use yourself:
>
> FROM python:3
> COPY requirements.txt .
> RUN pip install -r requirements.txt
> COPY . .
> CMD [ "gunicorn", "my.app" ]
>
> If someone is unable to make an equivalent Dockerfile then they will be
> really confused when they realise that they need to customise it, because
> few projects are as simple as that.
>
> You should also likely not embed Apache inside your app container - it’s
> kind of missing the general idea of Docker.
>
> To re-iterate: The Django project had no hand in creating the ‘official’
> image. The Docker project retired the original Django image for reasons
> that are clearly explained here , and
> those reasons still hold today.
>
> Tom
>
>
>
>
> On 28 February 2019 at 12:56:33, Alexander Lyabah (a.lya...@checkio.org)
> wrote:
>
> I can make a version for production use (in a week or two), for your
> critics.
>
> For example, based on Appache wsgi.
>
> PS: maybe it is also worth to make a docker image for testing changes in
> Django source?
>
> On Wednesday, February 27, 2019 at 4:31:17 PM UTC+2, Jamesie Pic wrote:
>>
>> > most people currently lean towards a microservice architecture and
>> therefore towards flask.
>> "according to the 2018 JetBrains Developer Survey" and some people.
>> Why start a project with flask in 2019 instead of Quart which or
>> Starlette is another question that I suppose is out of the scope of
>> this mailing list.
>>
>> Anyway, the point of Docker is to build your own image that supports
>> both development and production given different runtime parameters.
>> The agile practice with docker is to build your immutable image in CI,
>> test it, deploy it to staging, have on-click deployment to production.
>>
>> The security and best practice documentation from docker are indeed a
>> lot to grasp, and beginners will most of the time start making
>> insecure (running as root) and inefficient (fat) images. Therefore for
>> their security Django might want to document making a docker file,
>> perhaps based on the alpine image that's the most lightweight.
>>
>> --
>> ∞
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to 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/f07ad32e-e74f-4cd3-945a-ed92692c2209%40googlegroups.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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFNZOJP5k%3Dsn8VkdwseuVqnMC6X40y349urNMRFZfD7FEypvbg%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANK-ykm7ub21e8Ryn37jc1O7f5sg1PNTAGjoxD_h%2BHVRMs4_1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: BitBounce Spam Replies From the Mailing List

[Kye Russell]

https://twitter.com/stewart__dennis/status/1081973497025331201?s=21

I’m sure that falsely replying to mailing list emails helps with these
numbers.

I’m just going ahead and marking them as spam, because that’s what they
are. It’s negligence at this point.

On Mon, 18 Feb 2019 at 4:35 am, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Since Twitter is the only place where BitBounce responded, I tried again:
> https://twitter.com/aymericaugustin/status/1097231848973967362
>
> I'm skeptical about their willingness to fight spam: they're using it as
> their primary marketing channel. The more we're talking about them, the
> happier they are...
>
> --
> Aymeric.
>
>
>
> On 29 Jan 2019, at 11:30, Patryk Zawadzki  wrote:
>
> Sorry for resurrecting but this is still very much a problem. Same person,
> same autoresponder.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to 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/41722075-8e89-4777-8872-ee4660f14b26%40googlegroups.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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/4C847606-C965-4C61-8851-63DA676381CF%40polytechnique.org
> 
> .
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANK-ykmivQ4MOfPnWOEHKN_Cd2CT0S39_9doWrDVh3ZfsxDEQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Kye Russell]

I’ve been hearing that there are other CDN providers that offer a very
comparable service for a fraction of the cost of CloudFront.

Anyways, at this stage let’s not get bogged down on provider decisions. I’m
curious if anyone has any general objections to a CDN of any kind.

It shouldn’t be that big a deal to automatically invalidate when the docs
are updated. But I’m sure there’s something I’m missing.

On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho 
wrote:

> Consider AWS's cloudfront then :)
>
> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner
> escribió:
>>
>> Especially cloudflare is a service we do not want to use. as for the docs
>> only, does the mirror on rtd work better for you? They are probably behind
>> a CDN.
>>
>> Cheers,
>> Florian
>>
>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
>>>
>>> Hi,
>>>
>>> Is it possible to utilize a CDN service for djangoproject.com, or at
>>> least on docs.djangoproject.com? The site is actually quite fast for me
>>> but I think there is still room for improvement. Cloudflare sponsored
>>> dozens of open source projects
>>> , probably they can
>>> provide free service for django as well.
>>>
>>> Tested from Melbourne, Australia:
>>>
>>> https://www.djangoproject.com/
>>>  Average Ping: 245ms
>>>  Browser: 21 requests, 211KB transferred, Finish: 2.52s,
>>> DOMContentLoaded: 1.16s, Load: 1.48s
>>>
>>> https://git-scm.com/
>>>  Average Ping: 5ms
>>>  Browser: 42 requests, 351KB transferred, Finish: 717ms,
>>> DOMContentLoaded: 564ms, Load: 699ms
>>>
>>> Tested on Chrome with "Disable cache" checked (but not the first time
>>> visit, so DNS query time might not be included).
>>>
>>> Best regards and thanks for all your great work.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to 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/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

[Kye Russell]

Say what you want about the arguably unnecessary proliferation of complex
JavaScript applications / build pipelines upon the Internet over the past 5
or so years, but there’s no denying it’s becoming a necessary component in
a large portion of complex web projects.

I also think that—if it hasn’t already been done so already—the Django
documentation should at least contain a passing acknowledgement of this, as
well as some guidance on how to accomplish this.

Compare this to the latest iteration of Rails (I’ve never done more than
take a passing glance at the framework’s progress and am certainly no
expert) which includes a full webpack JS / asset pipeline as standard. I’m
aware of the philosophical differences between Django and Rails, and I’m
not necessary saying that bolting on Webpack was the right decision, but
it’s certainly speaks to how ‘back end’ framework development could lend a
helping hand beginners with a project that lends itself to a JS /
API-driven approach.

Kye


On 5 February 2019 at 8:52:38 am, Maciek Olko (maciej.o...@gmail.com) wrote:

I didn't find this topic being discussed before.

It seems to me to be good idea to place "How do I get Django and my JS
framework to work together?" or similar question and answer to it in FAQ in
Django's docs.

Having very big popularity of JS frameworks now it is indeed very common
question being asked or searched on the Internet. Such question for ReactJS
has 65k views on StackOverflow [1].

The answer could briefly explain that one can make use of Django backend
and produce API to be consumed by JS clients. Probably it would be good to
link to Django REST API project as a suggestion for big projects.

What do you think about such addition to FAQ?

Regards,
Maciej

[1]
https://stackoverflow.com/questions/41867055/how-to-get-django-and-reactjs-to-work-together
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to 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/CALYYG81uHehznRBvR4obTZr8685u0nm9y7yeUykPx8j0%3DJ-GyA%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANK-yk%3DOWqmfCfSLOVKBxZJz2zxvJr74DFqUUkRac7w9yvr4%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Automatically initialise the project as git repo

[Kye Russell]

I am against this. It assumes too much about the user's system and version
management preferences.

I think there is little to gain given that `git init .` is 10 characters.

On Fri, Jan 25, 2019 at 8:35 PM mihir karbelkar 
wrote:

> Hi,
> I have made several projects with Django but every time I create a new
> project I have to initialize the repo for git. It would be better if the
> project initialized itself. Maybe we can add this feature in to help make
> development "even faster to meet goals in record time".
> I would love to work on this but it will only be my first contribution
> so If we agree on this I can open probably open an issue and work on it.
> Also I would like to work for django in GSOC 2019 so any help would be
> appreciated.
> 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 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/657a58db-8129-4490-a14a-9fe32d0b03d9%40googlegroups.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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANK-ykkay%3DYUq%3DPKVVJTWcozApdA6Y0ZDLkvuBNr-HQ4wUsgfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

[Kye Russell]

Involving email addresses in the discussion complicates things because of
the involvement of the email RFC (or RFCs?) which IIRC dictates that the
mailbox portion of an email address may be case sensitive.

Back to OPs point, I feel that you should respect the case of a username
for display purposes. I’d merely do a case insensitive / normalisation
check for operations like login and conflict checking on signup / username
change. As far as email addresses are concerned, this is even more
justifiable as you could be dealing with a case sensitive email server. No
idea how common that is these days.

On Sat, 5 Jan 2019 at 10:12 pm, אורי  wrote:

> In Speedy Net all usernames and slugs must be lowercase. If they are
> entered not lowercase they are converted to lowercase. I don't see any
> reason why usernames should not be lowercase, especially if there are 2
> different users with usernames which differ only in case.
>
> All email addresses in Speedy Net are also converted to lowercase and
> saved lowercase in the database. I think it would be absurd if
> u...@speedy.net, u...@speedy.net and u...@speedy.net would belong to 3
> different people with 3 different usernames and email addresses.
>
> From
> https://github.com/speedy-net/speedy-net/blob/uri_merge_with_master_2018-12-31_a/speedy/core/accounts/tests/test_forms.py
> :
>
> def test_slug_gets_converted_to_lowercase(self):
> data = self.data.copy()
> data['slug'] = 'THIS-IS-A-SLUG'
> form = RegistrationForm(language_code=self.language_code,
> data=data)
> form.full_clean()
> self.assertTrue(expr=form.is_valid())
> self.assertDictEqual(d1=form.errors, d2={})
> user = form.save()
> self.assertEqual(first=user.slug, second='this-is-a-slug')
> self.assertEqual(first=user.username, second='thisisaslug')
>
> def test_email_gets_converted_to_lowercase(self):
> data = self.data.copy()
> data['email'] = 'emai...@example.com'
> form = RegistrationForm(language_code=self.language_code,
> data=data)
> form.full_clean()
> self.assertTrue(expr=form.is_valid())
> self.assertDictEqual(d1=form.errors, d2={})
> user = form.save()
> email_addresses = UserEmailAddress.objects.filter(user=user)
> email_addresses_set = {e.email for e in email_addresses}
> self.assertSetEqual(set1=email_addresses_set, set2={'
> emai...@example.com'})
>
>
>
> אורי (Uri)
> u...@speedy.net
>
>
> On Sat, Jan 5, 2019 at 3:18 PM Shelagh Lewins 
> wrote:
>
>> I think case-insensitive usernames is a must-have in the mobile world.
>> Users who register on mobile don't notice that their phone has
>> automatically capitalised the first letter of their username when they
>> enter it, and are then unable to log in on laptops because they are typing
>> the lower-case version.
>>
>> And because case-sensitive usernames are so unexpected, developers are
>> likely not to notice the problem until some way into the project.
>>
>> To expect every developer to modify the auth model because it doesn't
>> provide standard functionality seems like the wrong approach to me.
>>
>> If there are concerns about backwards compatibility, why not make it an
>> optional setting?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to 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/3b6d56fd-2664-4b56-8712-e76d51c73172%40googlegroups.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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CABD5YeFm3A2k7V8zeRPBxyu8zMv7msnmU1ogS_SrCJT76H_Fzw%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  

Re: A faster paginator for django

[Kye Russell]

It might also be worth looking at the alternative pagination methods 
offered by Django REST Framework as a source of inspiration.

On Wednesday, December 5, 2018 at 8:15:22 PM UTC+8, Saleem Jaffer wrote:
>
> Hi all,
>
> The default paginator that comes with Django is inefficient when dealing 
> with large tables. This is because the final query for fetching pages uses 
> "OFFSET" which is basically a linear scan till the last index of the 
> current page. Does it make sense to have a better paginator which does not 
> use "OFFSET". 
>
> If this sounds like a good idea, I have some ideas on how to do it and 
> with some help from you guys I can implement it.
>
> Saleem
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/0f431ffc-5ebf-4703-9e01-91240007c154%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.