Re: Case Sensitive Usernames
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 <mailto:be...@twosensedesign.com>> 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 > <mailto:m...@kye.id.au>> 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 > <mailto:pemb...@gmail.com>>, 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 >>> <http://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]
Re: Case Sensitive Usernames
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 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 >> <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 >> >> <https://groups.google.com/d/msgid/django-developers/9a5e1df3-778d-4993-8c32-57870fafd8f9n%40googlegroups.com?utm_medium=email_source=footer>. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and st
Re: Why can't range function be added in templates?
FWIW The template system always seemed like an added bonus to the project.
Which is fine because, personally, I’d rather more effort go into the guts than
the lipstick anyway.
It’s easy enough to build custom filters, or even exploit some of the quirks of
the system… so much so that asking the core team to address this over just
building or forking a third-party package is superfluous.
All that said, it loos like you’re trying to build form fields based on a
predetermined, um, range of results. It looks to me this can be addressed by
having one more nested loop. So you have `for i in group` then `for j in
i.game` - you could add something like `for k in j.squad_entry_members`. This
would skip the need for a range, fall within the system specs, and gets you a
free counter without having to know the specific size.
Benny
> On Oct 9, 2021, at 5:45 AM, 'Adam Johnson' via Django developers
> (Contributions to Django itself) wrote:
>
>
> Please don't use shouty capitals or angry slang like "Bruh no" on this
> mailing list. This mailing list is for calm professional discussion.
>
>> On Sat, 9 Oct 2021 at 11:35, Dhruva Shaw wrote:
>> SINCE THE NO OF SELECT BOXES THAT I HAVE GENERATE COMES DIRECTLY FROM THE
>> DATABSE, THUS RANGE FUNCTION IS NEEDED!
>>
>>> On Saturday, October 9, 2021 at 2:40:29 PM UTC+5:30 f.apo...@gmail.com
>>> wrote:
>>>> On Friday, October 8, 2021 at 6:14:19 PM UTC+2 dhruv...@gmail.com wrote:
>>>> Ik range function can be added but I also mentioned that there are some
>>>> cases range function can't be direct generated from the view like this
>>>> https://github.com/Tanzanite-lpu/tgl-2.0.0/blob/ddce5ef87a4b5248b8cb8cd5fa3df4adb3f00b31/main/templates/groups.html#L36
>>>
>>> Why was "|range" added there? You are not using {{ j }} there at all but {{
>>> forloop.counter }}. There doesn't seem to be any reason to use "|range"
>>> there.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/3e733a40-b9a0-4bc7-ba87-943bc5aee635n%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/CAMyDDM3MsvujxsH_QtHyO4Pqo6Vgtd1bG%2BTHB4_GYx%2BpQ2xGRA%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/32AF05A5-DFD8-47A0-A671-959FAB725980%40twosensedesign.com.
Re: Idea
There are serializers and dictionaries built into the Django models system that I’ve had zero problems leveraging for building out JSON (or REST-like) objects for endpoint purposes. I personally believe integrating DRF into Django would needlessly bloat it. The two play together perfectly fine if you really need them both. I’d recommend digging around in the guts of Django. You’ll find some pretty neat things there! Just my 2 cents, Benny > On Sep 15, 2021, at 6:36 PM, Michael Urban wrote: > > > For YEARS I’ve wanted a REST solution included with Django. DRF hasn’t never > felt like a great fit for Django projects. It’s very Rails-y. > > It would be amazing to have an official Django contrib package for REST. > > Never going to happen, but needs to be said. > > Best, > Mike > >> On Wed, Sep 15, 2021 at 4:40 PM 'Adam Johnson' via Django developers >> (Contributions to Django itself) wrote: >> DRF remains an extension to Django. We don't want Django to depend on it. >> >> But you're free to set up a startproject template that includes the >> settings, and use that. >> https://docs.djangoproject.com/en/3.2/ref/django-admin/#cmdoption-startproject-template >> >>> On Tue, 14 Sept 2021 at 08:44, abdul azeez wrote: >>> Pls can we make django come with django reest framework settings when you >>> start a 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/b91e5471-23d3-41e2-b5c5-e1f860739fe0n%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/CAMyDDM39FCfnt0-qU2Z1wSaR1j0ZuJwc3xntEDZtWB6Qjz2fYQ%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/CADyXHNar2-0TqdRi%2ButYwn8qd%2Bh34ZtyoxvuwNQ%3DMSB%2B%2B82NiA%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/81908113-FAF5-4DE9-B84F-FCC3DDFF7453%40twosensedesign.com.
Re: Do people actually squash migrations?
Sorry in advance of this isn’t helpful - We’ve done it successfully a few times since 1.11… but not without a sacrifice of the virgins-in-volcano variety. Just about any kind of RunPython command seems to get in the way. And sometimes it’s easier to blow them all away and create fresh migrations. I have faith in migration squashing. It feels like more art than science, and to be sure - dealing with a database is more art than science in general… especially with all the creative minds that have access to such a logical system. I believe squashing should be used with care, and mostly on systems with ideal schema. Aside of that, I’ve worked on projects with migrations in the several-hundreds which took long enough to stand up that I could get a coffee and continue working. All that said, I think it’s a nice-to-have feature, but ultimately isn’t necessary for the vast majority of projects. Benny > On May 11, 2021, at 7:50 PM, 'Mike Lissner' via Django developers > (Contributions to Django itself) wrote: > > 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/E949F021-480A-40C3-9C98-2B1BDE95C368%40twosensedesign.com.
Re: Permission to discuss
Thanks for your quick responses. Adam, I was not even aware of the Show & Tell section. I’ll definitely look into that. Benny > On Jan 19, 2021, at 4:20 PM, Adam Johnson wrote: > > > I don't think that's appropriate to post on either mailing list. These > mailing lists have thousands of members so must be kept on topic. The "Show & > Tell" section on the forum would be a better place to post this: > https://forum.djangoproject.com/c/projects/11 > >> On Tue, 19 Jan 2021 at 21:56, Benny wrote: >> Hi developers, >> >> I have an idea for a Django related project and I’d like to get input from >> users and developers before I decide to move forward with it. This does not >> directly apply to the Django backend or development, but I do believe input >> from the developers would be just as valuable. >> >> So as to not violate any spamming/advertising policy, I’d like to ask >> permission before launching an email to either (or both) groups. And to that >> point, would permission to discuss here apply to the users group, or should >> I ask there as well? >> >> Best, >> Benny >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/A9A09FB5-C0D1-4DC0-ABFD-A5F671F700E0%40twosensedesign.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/CAMyDDM1pzxTbGsUVhnJwOoZh3%2BdFGEJwzoLEWmU65FMvGt%3DyBQ%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/497DAF77-192E-4F76-9387-E86B7ADCC936%40twosensedesign.com.
Permission to discuss
Hi developers, I have an idea for a Django related project and I’d like to get input from users and developers before I decide to move forward with it. This does not directly apply to the Django backend or development, but I do believe input from the developers would be just as valuable. So as to not violate any spamming/advertising policy, I’d like to ask permission before launching an email to either (or both) groups. And to that point, would permission to discuss here apply to the users group, or should I ask there as well? Best, Benny -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/A9A09FB5-C0D1-4DC0-ABFD-A5F671F700E0%40twosensedesign.com.
Re: GDAPS
Long time lurker first time poster; could this possibly be addressed with
something along the lines of SECRET_KEY? It seems to me that no more of a
namespace would be needed than a uniquely identifying hash per app/module. Not
so much in settings or app_config as __init__, maybe?
Hi,
Benny
> On Jun 16, 2019, at 7:18 PM, Curtis Maloney wrote:
>
> [forgive me for typing as I think... but sometimes it's the best way to think
> ;) ]
>
>> On 6/17/19 5:19 AM, Christian González wrote:
>>> Am 16.06.19 um 10:06 schrieb Adam Johnson:
>>> * What do you think are the implications for Django core? Is there anything
>>> Django could do better to support this and all the other plugin systems
>>> you’ve looked at? Also I’m totally sure you can contribute, it’s not scary
>>> and there is a lot of information on getting started! See
>>> https://docs.djangoproject.com/en/dev/internals/contributing/
>> Yes, I'll have a deeper look at the contributing guidelines.
>> The most parts where I had to struggle within Django were:
>> * The settings, to let each module provide it's own setting. There is no
>> standardized way of having settings saved. I borrowed the graphene-django
>> way - which had copied it from DRF ;-)
>
> I've given some thought to this over the years, and what I think we've
> somehow missed in settings until now is ... Namespaces!
>
> Whilst we have namespace-by-prefix (CACHE_*) and namespace-by-dict (DATABASES
> = {} ) when it comes to plugins having their own declared settings, we may
> want to move to something a little more formal.
>
> Any plugin or app ought be able to declare its own settings and their
> defaults. And ISTM the "obvious" place to do this is in their AppConfig
>
> Except, that may be too late, since we may want/need the settings before apps
> are loaded?
>
> So the alternative is for a plugin to declare in its entry points a reference
> to its settings declaration. This way, all 3rd party settings can be
> gathered, vetted, and applied before having to scan the INSTALLED_APPS list.
>
> Now what we'll need is a way to avoid namespace clashes, and a dev-friendly
> way to update these settings in settings.py
>
> --
> Curtis
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to 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/d8cc1a37-b8ae-3a0c-021b-92ec6f7e5701%40tinbrain.net.
> 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/67996E66-F881-467A-970B-24B93D7DCE83%40twosensedesign.com.
For more options, visit https://groups.google.com/d/optout.
