Re: Set a reasonable default for EMAIL_TIMEOUT

[Arthur Pemberton]

> (Why is "Just give it a value in your settings" not OK? 🤔)

I'm guessing the issue here is that it's currently an unknown-unknown to
most/all newbies.

At the very least, it should probably be addressed in the documentation on
deployment.

Regards,
Arthur Pemberton

On Thu, 17 Nov 2022 at 11:16, Carlton Gibson 
wrote:

> Hi Federico.
>
> Maybe if we were starting from scratch having a default would be the right
> course — "maybe", I didn't think it through yet, or look at why the
> original decision went the way it did — but I don't think changing it is
> worth the disruption, or the difficulty of going through the deprecation
> process.
>
> (Why is "Just give it a value in your settings" not OK? 🤔)
>
> Around core.mail, there's a cluster of tickets that I'm hoping to pull
> into a project idea for this year's GSoC — see...
>
> - [Add Settings EMAIL_FQDN by Jrief · Pull Request #13728 · Django/Django](
> https://github.com/django/django/pull/13728)
>
> - [Ui/Django-post_office: A Django App That Allows You to Send Email
> Asynchronously in Django. Supports HTML Email, Database Backed Templates
> and Logging.](https://github.com/ui/django-post_office)
>
> - [Proposal on How Add Configuration Options to Email Backends](
> https://groups.google.com/g/django-developers/c/R8ebGynQjK0)
>
>
> ... and linked threads.
>
>
> ... and linked threads.
>
> One result of that (if all comes to pass) should hopefully be better
> customizability of your email backends, so you'd be free to set a default
> in your own backend, without the BC concerns for others.
>
> So that's not a, yes, let's change it, but hopefully it doesn't leave you
> without optimism 🙂
>
> Kind Regards,
>
> Carlton
>
> On Thu, 17 Nov 2022 at 16:33, Federico Capoano 
> wrote:
>
>> Hi all,
>>
>> Why is there no default for EMAIL_TIMEOUT?
>>
>> Applications built in Django can potentially stall indefinitely if email
>> sending starts to hang (eg: if the SMTP server is overloaded), when this
>> happens, since there's no timeout, there's also no error being logged, so
>> it's very hard and time consuming to debug.
>>
>> Wouldn't it be better to set a timeout? Some high value like 2 minutes
>> which wouldn't really make sense to wait any longer, so at least if and
>> when this happens, developers will find error traces in the logs and
>> quickly understand where the problem is coming from, instead of spending
>> hours to debug it like I did in the past week.
>>
>> Alternatively, we could set a default timeout only if
>> "socket.getdefaulttimeout()" returns None, just to avoid applications
>> stalling indefinitely, which is something that has been happening to me
>> lately.
>>
>> Best regards
>> Federico Capoano
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAERYH6Vs6%2BWnJMsw95Uc_b006PZ2N_Pr%3DNgx4ztPDkgjVbkivA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAERYH6Vs6%2BWnJMsw95Uc_b006PZ2N_Pr%3DNgx4ztPDkgjVbkivA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJwKpyRt%3D3AfDF3ygyn2XY9X7OtqzbWJ8U0VwH0KhwW-KJwzQg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAJwKpyRt%3D3AfDF3ygyn2XY9X7OtqzbWJ8U0VwH0KhwW-KJwzQg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

Re: Model icons

[Arthur Pemberton]

I too find the idea of hard coded HTML in a Python file to be inelegant,
for what it's worth.

Arthur Pemberton

On Sat, 18 Feb 2023 at 08:12, 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> Putting HTML for the admin in model definitions is a bit too coupled.
>
> I think you may be able to add icons already by overriding the admin
> template - can you try playing around with that?
>
> On Mon, Feb 6, 2023 at 12:07 AM Yeonggwang Yang 
> wrote:
>
>> that sounds good with me
>>
>> 2023년 2월 5일 일요일 오전 9시 36분 17초 UTC+9에 Marty님이 작성:
>>
>>> Hi all,
>>>
>>> Recently, it's trend to use icons or emoji before menu items and I like
>>> this idea because  IMHO people orient better and more quickly when they see
>>> picture.
>>>
>>> What about to add this feature to native django? I thought the easiest
>>> way would be to add new Meta option to Model. The default Meta icon would
>>> be empty string so everything would work like now. If I want to make menu
>>> more readable, I just add emoji (🔨) or html (Awesome font - *>> class="fa-solid fa-hammer">* , Bootstrap icon - **, etc.) to Meta icon.
>>>
>>> Code example:
>>>
>>> *Model:*
>>> class Hammer(models.Model):
>>> ...
>>>
>>> Meta:
>>> icon = ''
>>>
>>> *app_list.html template:*
>>> ...
>>> {{model.icon}} {{model.name}}
>>> ...
>>>
>>> Final result:
>>> [image: admin navbar.png]
>>>
>>> Maybe own icon could have even the parent app (AppConfig). And the model
>>> icon could be in breadcrumbs.
>>>
>>> What do you think about this idea? 🙂
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/6c859cc5-ea41-4695-9fcf-5cd435310364n%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/6c859cc5-ea41-4695-9fcf-5cd435310364n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM1L4rmQ3qomxOqD%2BmugXcsmx7NrOPAh8a53wR9G5q%3D3Gw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM1L4rmQ3qomxOqD%2BmugXcsmx7NrOPAh8a53wR9G5q%3D3Gw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

Re: Add a minimal Gitignore

[Arthur Pemberton]

I like the idea as I've seen novices commit all their .pyc files, but maybe
this should only triggered by a flag to startproject, --git perhaps.

Arthur Pemberton

On Thu, Mar 9, 2023, 14:13 Daniel Azubuine 
wrote:

> Yeah
>
> What I meant is for the default ‘startproject’ template to include a
> minimal .gitignore file.
>
> I've added the template.
> Just wanted to ask before I push
>
> On Thu, Mar 9, 2023, 20:00 James Bennett  wrote:
>
>> On Thu, Mar 9, 2023 at 10:27 AM 'Adam Johnson' via Django developers
>> (Contributions to Django itself) 
>> wrote:
>>
>>> The Django project has a .gitignore file:
>>> https://github.com/django/django/blob/main/.gitignore
>>>
>> I think this person was asking for the default ‘startproject’ template to
>> include a minimal .gitignore file.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAL13Cg9ySuiTEcyUQQiPKzP_Q6qCu2JBV6jZeE-0QdEFoimYAg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAL13Cg9ySuiTEcyUQQiPKzP_Q6qCu2JBV6jZeE-0QdEFoimYAg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAHRz_NZ-6rNNN53f6VGVJ4vv827G165yksFK%2BkMXz_vztz5Q8A%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAHRz_NZ-6rNNN53f6VGVJ4vv827G165yksFK%2BkMXz_vztz5Q8A%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

Re: Add a minimal Gitignore

[Arthur Pemberton]

What exactly would be considered the burden in maintaining a .gitignore?

Arthur

On Fri, Mar 10, 2023 at 11:37 AM Tega Ukavwe  wrote:

> I strongly agree with Adam and Tom, the extra and unnecessary burden of
> maintaining the .gitignore file outweighs its advantages.
>
> Cheers,
> Tega.
>
> On Fri, Mar 10, 2023 at 5:12 PM 'Adam Johnson' via Django developers
> (Contributions to Django itself) 
> wrote:
>
>> I'm also against the idea, unless done in a very minimal fashion.
>>
>> Many tools in the ecosystem put "ignore everything here" .gitignore files
>> into their not-normally-committed directories: at least Coverage.py, Mypy,
>> pytest, and virtualenv. So the trend is that less and less .gitignore
>> patterns are needed for a Python project. I am not sure there are general
>> Django patterns we could add except *.pyc , and maybe Python will start
>> dropped .gitignore files in __pycache__ dirs at some point.
>>
>> I don't think we could even add a pattern for ignoring .mo files from
>> translations, since according to a poll I did last year, about 50% of devs
>> commit them: https://twitter.com/AdamChainz/status/1557058307592015878 .
>>
>>  we could easily just use github's Python default, declare that the
>>> policay, and call it day
>>>
>>
>> GitHub’s Python default file is seriously bloated:
>> https://github.com/github/gitignore/blob/main/Python.gitignore . Their
>> maintenance policy seems to be “accept any suggestion, append-only”. We
>> generally set a higher bar for Django.
>>
>> The GitHub file includes patterns to ignore files generated by tools that
>> have fallen out of favour (e.g. nosetests.xml for nose test runner). And it
>> also includes low-specificity patterns that could confuse new Git users,
>> such as target/ ignoring *all* directories named "target". Also the "Django
>> stuff" patterns in there are related to non-universal ways of using Django.
>>
>> I wouldn't want to burden all Django projects with so many irrelevant
>> patterns. It takes work to understand and remove them.
>>
>> Enough people are using GitHub that they create the repo first with one
>>> of GH's provided gitignores, or copy it in after.
>>>
>>
>> Agree here that people can set up or use Git templates if they wish. Git
>> itself has a repository template mechanism.
>>
>> On Fri, Mar 10, 2023 at 4:07 PM Tom Carrick  wrote:
>>
>>> I don't really like the idea of this for a number of reasons.
>>>
>>> A lot of people create the project in a subdirectory. For them, the
>>> gitignore is in the wrong place.
>>>
>>> Enough people are using GitHub that they create the repo first with one
>>> of GH's provided gitignores, or copy it in after.
>>>
>>> As Python changes, as new tools come out, the gitignore needs to be
>>> constantly updated. There will be a lot of bikeshedding about what should
>>> and shouldn't go in. For example, the .vscode directory sometimes has
>>> project specific code that should be included. Sometimes it should be
>>> excluded because devs are expected to set their own up or use whatever
>>> editor they prefer. Many users (such as myself) have .vscode in a global
>>> gitignore expressly so it doesn't need to be added to every project.
>>>
>>> A lot of people are using a frontend framework, that won't be covered by
>>> our gitignore, and this framework might itself want to set up a gitignore.
>>>
>>> The biggest problem for me is that it would just be a maintenance burden.
>>>
>>> Cheers,
>>> Tom
>>>
>>>
>>> On Fri, 10 Mar 2023 at 16:01, Bogdan Barna  wrote:
>>>
 Just want to say that I agree with Cory. Being a non-core
 feature/issue, I don't see a reason of why not to re-evaluate the "denied"
 decisions.

 On Friday, March 10, 2023 at 9:11:03 AM UTC+2 Cory Zue wrote:

> Is there a more nuanced discussion of this issue anywhere? The reasons
> stated in the linked PR that it's "not for the project template to provide
> configuration for source code management tools" feels more like an opinion
> than a fact.
>
>  I know one of the goals that emerged from recent discussions was how
> to get more wide adoption of the Django project. This strikes me as one of
> those simple little things that helps 95% of beginners and doesn't hurt 
> the
> remaining 5%. If you don't want a .gitignore file, then you're also
> probably advanced enough to figure out how to build without it, or just
> delete it.
>
> I just checked a few other frameworks:
>
> Rails new automatically
>  generates a
> .gitignore by default, has an option to exclude it
> .
> Drupal / composer added it in 2020
> .
> create-react-app 
> generates one.
> create-vue  generates one
>
> Perhaps 

Production Django use and "real ip"

[Arthur Pemberton]

I have read previous discussions (most recent I could find was Dec 2013 
 [1] ) on the inclusion of `HTTP_X_FORWARDED_FOR` based logic to get the 
"real" IP address of an HttpRequest. From what I can see, currently there 
is currently no automatic handling of `HTTP_X_FORWARDED_FOR` in Django.

However, I do notice that Django acknowledges `X_FORWARDED_HOST`, 
`X_FORWARDED_PORT` and (indirectly) `X_FORWARDED_PROTO`  
(though SECURE_PROXY_SSL_HEADER).

If there is still opposition to having some built-in handling for 
`HTTP_X_FORWARDED_FOR`, I think that the deployment guide [1] should at 
least mention the need for the developer to handle this explicitly.

Regards,
Arthur P.



[1] https://groups.google.com/g/django-developers/c/J5O28jB5D3Q/m/KLLgllFS7v0J
[2] https://docs.djangoproject.com/en/4.1/howto/deployment/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%40googlegroups.com.

Re: Production Django use and "real ip"

[Arthur Pemberton]

At this point, I'm not even suggesting that Django handle this internally.
I'm suggesting that the behaviour/expectation be documented, at least in
the deployment guide.

Are there any deployment scenarios where META.REMOTE_ADDR is ever even
correct?

Arthur Pemberton

On Wed, Apr 19, 2023 at 3:37 AM 'st...@jigsawtech.co.uk' via Django
developers (Contributions to Django itself) <
django-developers@googlegroups.com> wrote:

> As someone whose worked on various projects in different languages over
> the last 15 years that heavily involved deciphering IP sent in headers to
> try to determine the "real" IP address of a connection, I would urge
> caution with anything around determining a "real IP". There is no standard
> in terms of where to look and what to trust. The X-FORWARDED-FOR is not
> always right, can easily be spoofed, it can include multiple IPs of which
> the order is not consistent. Sometimes the left most element is the first
> and "true IP", sometimes it's the right, sometimes its a value in the
> middle. It all depends what's included, what appended to the request, what
> the values are and what you want to trust/ignore. I've seen requests that
> include internal network IPs, then router/gateway IPs, proxy IPs and load
> balancers all within that head all in different orders.   It's especially
> messy when dealing with requests on mobile network where the carrier uses
> proxies, sometimes 3rd parties, and where your website is hosted behind
> both load balancers and webserver as each may manipulate the header in
> different ways.
>
> One of the best packages within the Django eco-system for trying to
> identify a users actual external IP that I've come across is django-ipware
> <https://github.com/un33k/django-ipware>. It allows you to choose the
> precedence order that matches your use case, yo have private IP prefixes,
> to configure how many proxies you wish to ignore etc. They also have a
> handy notice/disclaimer
> <https://github.com/un33k/django-ipware/blob/master/README.md#Notice> on
> the subject.
>
> IMO Django core should leave this 3rd party packages and individual
> deployments to decide and determine what they deem as being the source of
> the "real IP" for their individual project.
>
>
>
> On Friday, 14 April 2023 at 10:13:22 UTC+1 Adam Johnson wrote:
>
>> It's surprisingly complex to interpret x-forwarded-for:
>> https://www.brainonfire.net/blog/2022/03/04/understanding-using-xff/ .
>> We will never be able to safely add automated handling.
>>
>> I *guess* we could add a note to the deployment guide like "check your
>> HTTP_X_FORWARDED_FOR setting". I'm concerned it would be a step towards
>> making the guide too long, and filled with irrelevant details. Most sites
>> don't care about recording the user's IP. On those that do, it should be
>> easy enough to discover the setting.
>>
>> On Sat, Apr 1, 2023 at 4:39 AM Arthur Pemberton  wrote:
>>
>>> I have read previous discussions (most recent I could find was Dec 2013
>>>  [1] ) on the inclusion of `HTTP_X_FORWARDED_FOR` based logic to get the
>>> "real" IP address of an HttpRequest. From what I can see, currently there
>>> is currently no automatic handling of `HTTP_X_FORWARDED_FOR` in Django.
>>>
>>> However, I do notice that Django acknowledges `X_FORWARDED_HOST`,
>>> `X_FORWARDED_PORT` and (indirectly) `X_FORWARDED_PROTO`
>>> (though SECURE_PROXY_SSL_HEADER).
>>>
>>> If there is still opposition to having some built-in handling for
>>> `HTTP_X_FORWARDED_FOR`, I think that the deployment guide [1] should at
>>> least mention the need for the developer to handle this explicitly.
>>>
>>> Regards,
>>> Arthur P.
>>>
>>> 
>>>
>>> [1]
>>> https://groups.google.com/g/django-developers/c/J5O28jB5D3Q/m/KLLgllFS7v0J
>>> [2] https://docs.djangoproject.com/en/4.1/howto/deployment/
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> 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/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%40googlegroups.com?utm_medium=email&a

Deploying Django under a sub-path

[Arthur Pemberton]

The docs reference `FORCE_SCRIPT_NAME` but say very little of how to use it.

Reading through the code, I see very little use of `SCRIPT_NAME` itself,
however as far as I can tell, use of `SCRIPT_NAME` is supposed to be how
one deploys Django at a sub-path.

I had to modify wsgi.py per
https://ruddra.com/deploy-django-subpath-openshift/ to get things to work.

Shouldn't this be a complete feature?

I've re-checked https://docs.djangoproject.com/en/4.2/howto/deployment/ and
there's no information on the topic (that I could find).

Arthur Pemberton

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

Re: Deploying Django under a sub-path

[Arthur Pemberton]

Even with  `FORCE_SCRIPT_NAME` `MEDIA_URL` is being prefixed properly, but
not `STATIC_URL` .

Was `FORCE_SCRIPT_NAME` just not meant to be used with the `runserver` ?

Arthur Pemberton

On Fri, Jun 16, 2023 at 5:01 PM Arthur Pemberton  wrote:

> The docs reference `FORCE_SCRIPT_NAME` but say very little of how to use
> it.
>
> Reading through the code, I see very little use of `SCRIPT_NAME` itself,
> however as far as I can tell, use of `SCRIPT_NAME` is supposed to be how
> one deploys Django at a sub-path.
>
> I had to modify wsgi.py per
> https://ruddra.com/deploy-django-subpath-openshift/ to get things to work.
>
> Shouldn't this be a complete feature?
>
> I've re-checked https://docs.djangoproject.com/en/4.2/howto/deployment/
> and there's no information on the topic (that I could find).
>
> Arthur Pemberton
>

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

Re: Deploying Django under a sub-path

[Arthur Pemberton]

I found https://code.djangoproject.com/ticket/7930 seems like
`FORCE_SCRIPT_NAME` just isn't meant to work.

Maybe the docs should reflect that.

Arthur Pemberton

On Fri, Jun 16, 2023 at 5:18 PM Arthur Pemberton  wrote:

> Even with  `FORCE_SCRIPT_NAME` `MEDIA_URL` is being prefixed properly, but
> not `STATIC_URL` .
>
> Was `FORCE_SCRIPT_NAME` just not meant to be used with the `runserver` ?
>
> Arthur Pemberton
>
> On Fri, Jun 16, 2023 at 5:01 PM Arthur Pemberton 
> wrote:
>
>> The docs reference `FORCE_SCRIPT_NAME` but say very little of how to use
>> it.
>>
>> Reading through the code, I see very little use of `SCRIPT_NAME` itself,
>> however as far as I can tell, use of `SCRIPT_NAME` is supposed to be how
>> one deploys Django at a sub-path.
>>
>> I had to modify wsgi.py per
>> https://ruddra.com/deploy-django-subpath-openshift/ to get things to
>> work.
>>
>> Shouldn't this be a complete feature?
>>
>> I've re-checked https://docs.djangoproject.com/en/4.2/howto/deployment/
>> and there's no information on the topic (that I could find).
>>
>> Arthur Pemberton
>>
>

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

Re: Deploying Django under a sub-path

[Arthur Pemberton]

I actually meant this as a developer question: as, at least in my review of
the code, and testing with `manage.py runserver`. use of `SCRIPT_NAME` has
no observable effect.

If that can be confirmed, then yes, the documentation should be updated,
and I can do a PR accordingly. Use of `SCRIPT_NAME` itself is not
documented anywhere; seems like it should at least be mentioned in the
Deployment section.

Arthur Pemberton

On Fri, Jun 23, 2023 at 3:07 PM 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> Hi Arthur,
>
> You've found the wrong mailing list for this thread. This mailing list is
> for discussing the development of Django itself, not for support using
> Django. I guess that's why no one replied.
>
> If you would like to suggest a documentation change please do open a PR
> with reference to the information you found.
>
> Thanks,
>
> Adam
>
> On Fri, Jun 16, 2023 at 10:23 PM Arthur Pemberton 
> wrote:
>
>> I found https://code.djangoproject.com/ticket/7930 seems like
>> `FORCE_SCRIPT_NAME` just isn't meant to work.
>>
>> Maybe the docs should reflect that.
>>
>> Arthur Pemberton
>>
>> On Fri, Jun 16, 2023 at 5:18 PM Arthur Pemberton 
>> wrote:
>>
>>> Even with  `FORCE_SCRIPT_NAME` `MEDIA_URL` is being prefixed properly,
>>> but not `STATIC_URL` .
>>>
>>> Was `FORCE_SCRIPT_NAME` just not meant to be used with the `runserver` ?
>>>
>>> Arthur Pemberton
>>>
>>> On Fri, Jun 16, 2023 at 5:01 PM Arthur Pemberton 
>>> wrote:
>>>
>>>> The docs reference `FORCE_SCRIPT_NAME` but say very little of how to
>>>> use it.
>>>>
>>>> Reading through the code, I see very little use of `SCRIPT_NAME`
>>>> itself, however as far as I can tell, use of `SCRIPT_NAME` is supposed to
>>>> be how one deploys Django at a sub-path.
>>>>
>>>> I had to modify wsgi.py per
>>>> https://ruddra.com/deploy-django-subpath-openshift/ to get things to
>>>> work.
>>>>
>>>> Shouldn't this be a complete feature?
>>>>
>>>> I've re-checked https://docs.djangoproject.com/en/4.2/howto/deployment/
>>>> and there's no information on the topic (that I could find).
>>>>
>>>> Arthur Pemberton
>>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CA%2BX4dQSQDcaApgWFmEE8MRERKbdHBBPh4KXa12pTi9FHO7zx1g%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQSQDcaApgWFmEE8MRERKbdHBBPh4KXa12pTi9FHO7zx1g%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM016eww3f5GBB1sPHJncf%2BWUHk7nLdQsf9ezUhJY0d9XQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM016eww3f5GBB1sPHJncf%2BWUHk7nLdQsf9ezUhJY0d9XQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

Use of TIME_INPUT_FORMATS in TimeField

[Arthur Pemberton]

The documentation (
https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says
that " the default input formats are taken from the active locale format
TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS
<https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-TIME_INPUT_FORMATS>
if localization is disabled". However, neither my reading of the code, or
my actual experience shows settings.TIME_INPUT_FORMATS ever being used,
even with "USE_I18N = False"

TimeField gets the formats from `input_formats =
formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of
`formats.get_format` -- the documentation of which says "If use_l10n is
provided and is not None, it forces the value to be localized (or not),
otherwise it's always localized."

so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be
ignored.

How does one use settings.TIME_INPUT_FORMATS ?

Arthur Pemberton

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

Re: Use of TIME_INPUT_FORMATS in TimeField

[Arthur Pemberton]

Thanks, I'll look into that. But does that mean that
settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic
flows that lead to it being used.

On Tue, Mar 5, 2024 at 3:00 AM David Sanders 
wrote:

> Define TIME_INPUT_FORMATS in your local formats.py setup as per:
> https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files
>
> On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton  wrote:
>
>> The documentation (
>> https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says
>> that " the default input formats are taken from the active locale format
>> TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS
>> <https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-TIME_INPUT_FORMATS>
>> if localization is disabled". However, neither my reading of the code, or
>> my actual experience shows settings.TIME_INPUT_FORMATS ever being used,
>> even with "USE_I18N = False"
>>
>> TimeField gets the formats from `input_formats =
>> formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of
>> `formats.get_format` -- the documentation of which says "If use_l10n is
>> provided and is not None, it forces the value to be localized (or not),
>> otherwise it's always localized."
>>
>> so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be
>> ignored.
>>
>> How does one use settings.TIME_INPUT_FORMATS ?
>>
>> Arthur Pemberton
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

Re: Use of TIME_INPUT_FORMATS in TimeField

[Arthur Pemberton]

I haven't yet checked the tests thoroughly enough to determine why things
didn't work for me in practice. I do know they didn't work. And I do see
that the tests pass. But I suspect that the tests may not be fully
mimicking the read-world use case in this scenario.

I'll return here once I have some evidence either way,

Arthur Pemberton

On Tue, Mar 5, 2024 at 3:40 PM Adam Johnson  wrote:

> USE_I18N does not disable localization, but internationalization. USE_L10N
> was the setting to enable/disable localization, but it was deprecated in
> Django 4.0:
> https://docs.djangoproject.com/en/4.0/releases/4.0/#localization . It was
> removed completely in Django 5.0, in this commit:
> https://github.com/django/django/commit/8d98f99a4ab5de6f2c730399f53eba8bf6bea470
> .
>
> So I think the phrase “if localization is disabled” is at least a little
> bit wrong. But I don’t think the setting is ignored, as there are tests
> confirming that it works:
> https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/tests/forms_tests/tests/test_input_formats.py#L123-L125
> . The line that reads the setting should be this one:
> https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/django/utils/formats.py#L132
> .
>
> If you can provide a failing minimal project, that would be useful to keep
> debugging. I have some minimal django project templates at
> https://github.com/adamchainz/django-startproject-templates .
>
> On Tue, Mar 5, 2024, at 8:48 AM, Arthur Pemberton wrote:
>
> Thanks, I'll look into that. But does that mean that
> settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic
> flows that lead to it being used.
>
> On Tue, Mar 5, 2024 at 3:00 AM David Sanders 
> wrote:
>
> Define TIME_INPUT_FORMATS in your local formats.py setup as per:
> https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files
>
> On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton  wrote:
>
> The documentation (
> https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says
> that " the default input formats are taken from the active locale format
> TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS
> <https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-TIME_INPUT_FORMATS>
> if localization is disabled". However, neither my reading of the code, or
> my actual experience shows settings.TIME_INPUT_FORMATS ever being used,
> even with "USE_I18N = False"
>
> TimeField gets the formats from `input_formats =
> formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of
> `formats.get_format` -- the documentation of which says "If use_l10n is
> provided and is not None, it forces the value to be localized (or not),
> otherwise it's always localized."
>
> so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be
> ignored.
>
> How does one use settings.TIME_INPUT_FORMATS ?
>
> Arthur Pemberton
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CA%2BX4dQTQwnqe%3DpJf3bmiZH5LHJ8

Re: Proposal to upgrade django.core.mail to Python's modern email API

[Arthur Pemberton]

Would this be designed to be compatible with "Proposal 14: Background
Workers"?



On Sun, Jun 23, 2024 at 10:46 PM Mike Edmunds  wrote:

> I want to propose updating django.core.mail to replace use of Python's
> legacy email.message.Message (and other legacy email APIs) with
> email.message.EmailMessage (and other modern APIs).
>
> If there's interest, I can put together a more detailed proposal and/or
> ticket, but was hoping to get some initial feedback first. (I searched for
> relevant discussions in django-developers and the issue tracker, and didn't
> find any. Apologies if this has come up before.)
>
> [Note: I maintain django-anymail
> , which implements Django
> integration with several transactional email service providers.]
>
>
> *Background*
>
> Since Python ~3.6, Python's email package has included two largely
> separate implementations:
>
>- a "modern (unicode friendly) API" based on
>email.message.EmailMessage and email.policy.default
>- a "legacy API" providing compatibility with older Python versions,
>based on email.message.Message and email.policy.compat32
>
> (See https://docs.python.org/3/library/email.html, especially toward the
> end.)
>
> django.core.mail currently uses the legacy API.
>
>
> *Why switch?*
>
> There are no plans to deprecate Python's legacy email API, and it's
> working, so why change Django?
>
>-
>
>*Fewer bugs:* The modern API fixes a *lot* of bugs in the legacy API.
>My understanding is legacy bugs will generally not be fixed. (And in fact,
>there are some cases where the legacy API deliberately replicates earlier
>buggy behavior.)
>
>Django #35497  is an
>example of a legacy bug (with a problematic proposed workaround) which is
>just fixed in the modern API.
>-
>
>*Simpler, safer code:* A substantial portion
>
> 
>  of
>django.core.mail's internals implements workarounds and security fixes for
>problems in the legacy API. This would be greatly simplified—maybe
>eliminated completely—using the modern API.
>
>Examples: the modern API prevents CR/NL injections in message headers.
>It serializes and folds address headers properly—even ones with unicode
>names. It enforces single-instance headers where appropriate.
>-
>
>*Easier to work with:* The modern API adds some nice conveniences for
>developers working in django.core.mail, third-party library developers, and
>(depending on what we choose to expose) users of Django's mail APIs.
>
>Examples: populating the "Date" header with a datetime or an address
>header with Address
>
> 
>  objects—without
>needing intricate knowledge of email header formats. Using email.policy to
>generate a 7-bit clean serialization (without having to muck about
>with the MIME parts
>
> 
>).
>
>
> *Concerns & risks*
>
> Compatibility and security, of course…
>
>-
>
>*Backwards compatibility (for API users):* django.core.mail largely
>insulates callers from the underlying Python email package. There are a few
>places where this leaks (e.g., attachments
>
> 
>  allows
>legacy email MIMEBase
> objects), but in
>general the switch should be transparent. (And I have some ideas for
>supporting the other cases.)
>-
>
>*Backwards compatibility (for third-party libraries):* Some libraries
>may use internals I'd propose removing (e.g., SafeMIME and friends);
>we'd handle this through deprecation.
>-
>
>*Backwards compatibility (bug-level):* There's probably some code out
>there that unintentionally depends on legacy email bugs (or the specific
>ways Django works around them). I don't have any examples, but I also don't
>have a good solution for when they surface. Plus, while Python's modern
>email API is pretty mature at this point, there are still new bugs being
>reported against it. Email is complicated.
>-
>
>*Security:* As noted above, the modern API should be more secure than
>the legacy one. But we also have a nice collection of email security
>tests—which *mostly* don't depend on internal implementation. We'd
>keep these.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+

Re: Proposal to upgrade django.core.mail to Python's modern email API

[Arthur Pemberton]

>  The background workers proposal will implement a new background SMTP
EmailBackend (in django.core.mail.backends).

I had missed that fact. Thanks for the explanation.

I for one think that this is a good proposal -- this would modern
transactional email sending.

- Arthur


On Mon, Jun 24, 2024 at 3:14 PM Mike Edmunds  wrote:

> > Would this be designed to be compatible with "Proposal 14: Background
> Workers"?
>
> I wouldn't expect this to impact background workers one way or the other.
> The same goes for the async email proposal(s) floating around.
>
> Virtually all of this work would occur in django.core.mail.message, where
> Python's `email` APIs are used. A goal is to avoid changes that would break
> existing email backends (Django or third-party).
>
> The background workers proposal will implement a new background SMTP
> EmailBackend (in django.core.mail.backends). The existing SMTP EmailBackend
> doesn't directly use Python's `email` APIs, and there should be no reason
> for background SMTP to be any different. (It might be helpful to know that
> Python's `email` library isn't involved in *sending* email; that's
> handled by Python's `smtplib`, which Django uses only in the SMTP
> EmailBackend.)
>
> The existing SMTP EmailBackend *does* use one function I expect will
> become deprecated: django.core.mail.message.sanitize_address(). I haven't
> yet investigated whether that use is still necessary, or whether it's there
> to get around past bugs/limitations in Python's smtplib. If any of it is
> still needed for SMTP, I'd probably want to move that code into the SMTP
> EmailBackend(s).
>
> - Mike
> On Sunday, June 23, 2024 at 10:22:03 PM UTC-7 Arthur Pemberton wrote:
>
>> Would this be designed to be compatible with "Proposal 14: Background
>> Workers"?
>>
>>
>>
>> On Sun, Jun 23, 2024 at 10:46 PM Mike Edmunds  wrote:
>>
>>> I want to propose updating django.core.mail to replace use of Python's
>>> legacy email.message.Message (and other legacy email APIs) with
>>> email.message.EmailMessage (and other modern APIs).
>>>
>>> If there's interest, I can put together a more detailed proposal and/or
>>> ticket, but was hoping to get some initial feedback first. (I searched for
>>> relevant discussions in django-developers and the issue tracker, and didn't
>>> find any. Apologies if this has come up before.)
>>>
>>> [Note: I maintain django-anymail
>>> <https://github.com/anymail/django-anymail>, which implements Django
>>> integration with several transactional email service providers.]
>>>
>>>
>>> *Background*
>>>
>>> Since Python ~3.6, Python's email package has included two largely
>>> separate implementations:
>>>
>>>- a "modern (unicode friendly) API" based on
>>>email.message.EmailMessage and email.policy.default
>>>- a "legacy API" providing compatibility with older Python versions,
>>>based on email.message.Message and email.policy.compat32
>>>
>>> (See https://docs.python.org/3/library/email.html, especially toward
>>> the end.)
>>>
>>> django.core.mail currently uses the legacy API.
>>>
>>>
>>> *Why switch?*
>>>
>>> There are no plans to deprecate Python's legacy email API, and it's
>>> working, so why change Django?
>>>
>>>-
>>>
>>>*Fewer bugs:* The modern API fixes a *lot* of bugs in the legacy
>>>API. My understanding is legacy bugs will generally not be fixed. (And in
>>>fact, there are some cases where the legacy API deliberately replicates
>>>earlier buggy behavior.)
>>>
>>>Django #35497 <https://code.djangoproject.com/ticket/35497> is an
>>>example of a legacy bug (with a problematic proposed workaround) which is
>>>just fixed in the modern API.
>>>-
>>>
>>>*Simpler, safer code:* A substantial portion
>>>
>>> <https://github.com/django/django/blob/stable/5.1.x/django/core/mail/message.py#L32-L190>
>>>  of
>>>django.core.mail's internals implements workarounds and security fixes 
>>> for
>>>problems in the legacy API. This would be greatly simplified—maybe
>>>eliminated completely—using the modern API.
>>>
>>>Examples: the modern API prevents CR/NL injections in message
>>>headers. It serializes and folds address h

Case Sensitive Usernames

[Arthur Pemberton]

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-developers+unsubscr...@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.

Re: Case Sensitive Usernames

[Arthur Pemberton]

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
>>  
>> <https://groups.google.com/d/msgid/django-developers/9a5e1df3-778d-4993-8c32-57870fafd8f9n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

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

Re: Case Sensitive Usernames

[Arthur Pemberton]

Purely anecdotal, but I've never had a user intentionally signup for an 
account with a case-sensitive email address. I'm not such which users 
expect their username or email addresses to be case-sensitive.

Arthur

On Sunday, December 12, 2021 at 10:40:30 PM UTC-5 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 , 
> 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
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/9a5e1df3-778d-4993-8c32-57870fafd8f9n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-develop...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://grou

Re: Case Sensitive Usernames

[Arthur Pemberton]

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 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
>>> <https://groups.google

Re: Improvements to the startproject template

[Arthur Pemberton]

For what it's worth, this is the (general) layout I've used for the past 8+
years of my professional Django development.

Arthur

On Wed, 20 Apr 2022 at 15:22, Olivier Dalang 
wrote:

> +1 for Adam's suggestion, I use it as well and like it very much.
>
> > root folder
> - manage.py
> - ...
> > myproject
> - __init__.py
> - settings.py
> - urls.py
> - ...
> > myapp
> - __init__.py
> - models.py
> - ...
>
> Pros:
> - everything is well namespaced under myproject (`myproject.settings`,
> quite straightforward)
> - makes it clear that `settings.py`, `urls.py`, etc. concern the project
> as a whole, and not just an app.
> - also nice in settings.INSTALLED_APPS (`myproject.myapp` makes it clear
> that myapp is part of this project)
> - it leaves the root level for stuff like .gitignore, db.sqlite, etc, so
> the actual source stays clean from such files.
> - having a parent package allows (does not require) relative imports
> across modules of the same project, which more clearly conveys that such
> apps are tightly coupled
> - with manage.py still in the root folder, you don't need to cd into any
> folder to start working
>
> I use it all the time.
>
> Cheers,
>
> Olivier
>
>
>
>
> Le mer. 20 avr. 2022 à 18:50, Tom Carrick  a écrit :
>
>> I prefer Adam's suggestion in the forum post as it lets you namespace
>> everything under your project name nicely and avoids package name
>> collisions, although it doesn't solve the problem of having two directories
>> with the same name by default.
>>
>> That said, either would be an improvement on what we have so I'm in
>> favour of either approach over doing nothing.
>>
>> Cheers,
>> Tom
>>
>> On Wed, 20 Apr 2022 at 16:49, John M 
>> wrote:
>>
>>> I do exactly this for every new Django project, so it's +1 from me as
>>> well.
>>>
>>> John
>>> On 20/04/2022 12:01, da...@springbourne-tech.com wrote:
>>>
>>> +1 for me - this would be really useful.
>>>
>>> On Monday, April 18, 2022 at 9:02:02 PM UTC+1 pyt...@ian.feete.org
>>> wrote:
>>>
 Hi Tim,

 This feels like a good idea to me.

 Regards,
 Ian

 On Mon, 18 Apr 2022 at 18:17, Tim Allen 
 wrote:

> Greetings, friends!
>
> I've issued a PR that makes two changes to the `startproject` template:
>
>- instead of putting configuration files such
>as `settings.py`, `wsgi.py`, and the
>root `urls.py` in `my_project/my_project`, they are created
>in `my_project/config`
>- start the project with a custom User model app, `users`
>
> Over the years, I've taught or tutored over 100 Djangonauts starting
> their first project. Having to distinguish between two directories with 
> the
> same name is a constant pain point in the teaching process - "cd into
> my_project ... no, the other one!"
>
>- The `config` option seemed to be the consensus from this thread
>in the forum: Django New Project Structure/Name - Using Django -
>Django Forum (djangoproject.com)
>
> 
>- Ticket: https://github.com/django/django/pull/15609
>
> It is sometimes better to show rather than tell, so following our own
> documentation and including a custom User model with the initial project
> template reinforces the best practice that we explicitly point out in the
> documentation.
>
>- Ticket:  #27909 (Use AUTH_USER_MODEL in startproject template) –
>Django (djangoproject.com)
>
>- Avoids ever having this come up again:
>
> https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/
>
> Here's a link to the PR: https://github.com/django/django/pull/15609
>
> My apologies for not starting with a discussion first. I'm an
> infrequent contributor to the Django codebase!
>
> Regards,
>
> Tim
>
 --
> You received this message because you are subscribed to the Google
> 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/33cb49d0-2469-47c0-920e-9501245c5a27n%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...@go

Re: Use of TIME_INPUT_FORMATS in TimeField

[Arthur Pemberton]

To simplify things further, within a view:

TIME_INPUT_FORMATS = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M', '%I:%M %p']

and

forms.TimeField.input_formats = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M']

On Sun, Dec 8, 2024 at 9:55 AM Arthur Pemberton  wrote:

> I finally got back to this.
>
> I have a failing minimal project (not test) that
> demonstrates TIME_INPUT_FORMATS not being respected:
> https://github.com/pembo13/dateentry
>
> In the example, the form should be valid, if TIME_INPUT_FORMATS worked as
> documented.
>
> I _think_ there's something about how the unittest is written that allows
> it to pass, and not expose this.
>
> Regards,
> Arthur
>
> On Tue, Mar 5, 2024 at 3:40 PM Adam Johnson  wrote:
>
>> USE_I18N does not disable localization, but internationalization.
>> USE_L10N was the setting to enable/disable localization, but it was
>> deprecated in Django 4.0:
>> https://docs.djangoproject.com/en/4.0/releases/4.0/#localization . It
>> was removed completely in Django 5.0, in this commit:
>> https://github.com/django/django/commit/8d98f99a4ab5de6f2c730399f53eba8bf6bea470
>> .
>>
>> So I think the phrase “if localization is disabled” is at least a little
>> bit wrong. But I don’t think the setting is ignored, as there are tests
>> confirming that it works:
>> https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/tests/forms_tests/tests/test_input_formats.py#L123-L125
>> . The line that reads the setting should be this one:
>> https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/django/utils/formats.py#L132
>> .
>>
>> If you can provide a failing minimal project, that would be useful to
>> keep debugging. I have some minimal django project templates at
>> https://github.com/adamchainz/django-startproject-templates .
>>
>> On Tue, Mar 5, 2024, at 8:48 AM, Arthur Pemberton wrote:
>>
>> Thanks, I'll look into that. But does that mean that
>> settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic
>> flows that lead to it being used.
>>
>> On Tue, Mar 5, 2024 at 3:00 AM David Sanders <
>> shang.xiao.sand...@gmail.com> wrote:
>>
>> Define TIME_INPUT_FORMATS in your local formats.py setup as per:
>> https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files
>>
>> On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton  wrote:
>>
>> The documentation (
>> https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says
>> that " the default input formats are taken from the active locale format
>> TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS
>> <https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-TIME_INPUT_FORMATS>
>> if localization is disabled". However, neither my reading of the code, or
>> my actual experience shows settings.TIME_INPUT_FORMATS ever being used,
>> even with "USE_I18N = False"
>>
>> TimeField gets the formats from `input_formats =
>> formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of
>> `formats.get_format` -- the documentation of which says "If use_l10n is
>> provided and is not None, it forces the value to be localized (or not),
>> otherwise it's always localized."
>>
>> so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be
>> ignored.
>>
>> How does one use settings.TIME_INPUT_FORMATS ?
>>
>> Arthur Pemberton
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>>

How to run the CustomTimeInputFormatsTests unit test?

[Arthur Pemberton]

I've read 
through 
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/
 
and I'm still uncertain how to properly run it.

As far as I can tell, tests decorated with `@translation.override(None)` do 
not get run when using `./runtests.py`

Even using `./runtests.py 
forms_tests.tests.test_input_formats.CustomTimeInputFormatsTests.test_timeField`
 
results in an error:

TypeError: CustomTimeInputFormatsTests.test_timeField() missing 1 required 
positional argument: 'self'

Arthur Pemberton

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/django-developers/2f3cc486-2e47-476a-a036-92850c5dbce6n%40googlegroups.com.

Re: How to run the CustomTimeInputFormatsTests unit test?

[Arthur Pemberton]

I've submitted https://code.djangoproject.com/ticket/35986 

If I'm missing something, please let me know.

Arthur Pemberton

On Monday, December 9, 2024 at 5:12:57 AM UTC-5 Bendegúz Csirmaz wrote:

> Yes you're right, it's not executed for me either.
>
> On Monday, 9 December 2024 at 17:53:16 UTC+8 Arthur Pemberton wrote:
>
>> I've read through 
>> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/
>>  
>> and I'm still uncertain how to properly run it.
>>
>> As far as I can tell, tests decorated with `@translation.override(None)` 
>> do not get run when using `./runtests.py`
>>
>> Even using `./runtests.py 
>> forms_tests.tests.test_input_formats.CustomTimeInputFormatsTests.test_timeField`
>>  
>> results in an error:
>>
>> TypeError: CustomTimeInputFormatsTests.test_timeField() missing 1 
>> required positional argument: 'self'
>>
>> Arthur Pemberton
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/django-developers/8d0f229c-748c-4749-a1a8-1734cf7ee198n%40googlegroups.com.

Re: Use of TIME_INPUT_FORMATS in TimeField

[Arthur Pemberton]

As further follow up on this, as far as I can tell, the relevant unit test 
does not run, seemingly due to the use of `translation.override(None)`

Removing, that, and running the test `./runtests.py 
forms_tests.tests.test_input_formats.CustomTimeInputFormatsTests.test_timeField`
 
results in the test failing.

Arthur Pemberton

On Sunday, December 8, 2024 at 8:03:22 PM UTC-5 Arthur Pemberton wrote:

To simplify things further, within a view:

TIME_INPUT_FORMATS = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M', '%I:%M %p']

and

forms.TimeField.input_formats = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M']

On Sun, Dec 8, 2024 at 9:55 AM Arthur Pemberton  wrote:

I finally got back to this. 

I have a failing minimal project (not test) that 
demonstrates TIME_INPUT_FORMATS not being respected:
https://github.com/pembo13/dateentry

In the example, the form should be valid, if TIME_INPUT_FORMATS worked as 
documented.

I _think_ there's something about how the unittest is written that allows 
it to pass, and not expose this.

Regards,
Arthur

On Tue, Mar 5, 2024 at 3:40 PM Adam Johnson  wrote:

USE_I18N does not disable localization, but internationalization. USE_L10N 
was the setting to enable/disable localization, but it was deprecated in 
Django 4.0: https://docs.djangoproject.com/en/4.0/releases/4.0/#localization 
. It was removed completely in Django 5.0, in this commit: 
https://github.com/django/django/commit/8d98f99a4ab5de6f2c730399f53eba8bf6bea470
 
.

So I think the phrase “if localization is disabled” is at least a little 
bit wrong. But I don’t think the setting is ignored, as there are tests 
confirming that it works: 
https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/tests/forms_tests/tests/test_input_formats.py#L123-L125
 
. The line that reads the setting should be this one: 
https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/django/utils/formats.py#L132
 
.

If you can provide a failing minimal project, that would be useful to keep 
debugging. I have some minimal django project templates at 
https://github.com/adamchainz/django-startproject-templates .

On Tue, Mar 5, 2024, at 8:48 AM, Arthur Pemberton wrote:

Thanks, I'll look into that. But does that mean that 
settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic 
flows that lead to it being used.

On Tue, Mar 5, 2024 at 3:00 AM David Sanders  wrote:

Define TIME_INPUT_FORMATS in your local formats.py setup as per: 
https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files

On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton  wrote:

The documentation (
https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says 
that " the default input formats are taken from the active locale format 
TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS 
<https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-TIME_INPUT_FORMATS>
 
if localization is disabled". However, neither my reading of the code, or 
my actual experience shows settings.TIME_INPUT_FORMATS ever being used, 
even with "USE_I18N = False"

TimeField gets the formats from `input_formats = 
formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of 
`formats.get_format` -- the documentation of which says "If use_l10n is 
provided and is not None, it forces the value to be localized (or not), 
otherwise it's always localized."

so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be 
ignored.

How does one use settings.TIME_INPUT_FORMATS ?

Arthur Pemberton


-- 
You received this message because you are subscribed to the Google 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/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com
 
<https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an 
email to django-develop...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com
 
<https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.


-- 
You received this message because you a

Re: Use of TIME_INPUT_FORMATS in TimeField

[Arthur Pemberton]

Adam,

Up until now, I've only been reading the test. Now that I actually tried 
running the test, it does not get discovered by the testing system (without 
modifications to test_input_formats.py) and when I do get the test to run, 
it fails.

I used tag "5.1.4" to get the unit tests.

Arthur

On Tuesday, March 5, 2024 at 3:41:10 PM UTC-5 Adam Johnson wrote:

> USE_I18N does not disable localization, but internationalization. USE_L10N 
> was the setting to enable/disable localization, but it was deprecated in 
> Django 4.0: 
> https://docs.djangoproject.com/en/4.0/releases/4.0/#localization . It was 
> removed completely in Django 5.0, in this commit: 
> https://github.com/django/django/commit/8d98f99a4ab5de6f2c730399f53eba8bf6bea470
>  
> .
>
> So I think the phrase “if localization is disabled” is at least a little 
> bit wrong. But I don’t think the setting is ignored, as there are tests 
> confirming that it works: 
> https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/tests/forms_tests/tests/test_input_formats.py#L123-L125
>  
> . The line that reads the setting should be this one: 
> https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/django/utils/formats.py#L132
>  
> .
>
> If you can provide a failing minimal project, that would be useful to keep 
> debugging. I have some minimal django project templates at 
> https://github.com/adamchainz/django-startproject-templates .
>
> On Tue, Mar 5, 2024, at 8:48 AM, Arthur Pemberton wrote:
>
> Thanks, I'll look into that. But does that mean that 
> settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic 
> flows that lead to it being used.
>
> On Tue, Mar 5, 2024 at 3:00 AM David Sanders  
> wrote:
>
> Define TIME_INPUT_FORMATS in your local formats.py setup as per: 
> https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files
>
> On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton  wrote:
>
> The documentation (
> https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says 
> that " the default input formats are taken from the active locale format 
> TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS 
> <https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-TIME_INPUT_FORMATS>
>  
> if localization is disabled". However, neither my reading of the code, or 
> my actual experience shows settings.TIME_INPUT_FORMATS ever being used, 
> even with "USE_I18N = False"
>
> TimeField gets the formats from `input_formats = 
> formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of 
> `formats.get_format` -- the documentation of which says "If use_l10n is 
> provided and is not None, it forces the value to be localized (or not), 
> otherwise it's always localized."
>
> so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be 
> ignored.
>
> How does one use settings.TIME_INPUT_FORMATS ?
>
> Arthur Pemberton
>
>
> -- 
> You received this message because you are subscribed to the Google 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/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-develop...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-develop...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CA%2BX4dQTQwnqe%3DpJ

Re: Use of TIME_INPUT_FORMATS in TimeField

[Arthur Pemberton]

I finally got back to this.

I have a failing minimal project (not test) that
demonstrates TIME_INPUT_FORMATS not being respected:
https://github.com/pembo13/dateentry

In the example, the form should be valid, if TIME_INPUT_FORMATS worked as
documented.

I _think_ there's something about how the unittest is written that allows
it to pass, and not expose this.

Regards,
Arthur

On Tue, Mar 5, 2024 at 3:40 PM Adam Johnson  wrote:

> USE_I18N does not disable localization, but internationalization. USE_L10N
> was the setting to enable/disable localization, but it was deprecated in
> Django 4.0:
> https://docs.djangoproject.com/en/4.0/releases/4.0/#localization . It was
> removed completely in Django 5.0, in this commit:
> https://github.com/django/django/commit/8d98f99a4ab5de6f2c730399f53eba8bf6bea470
> .
>
> So I think the phrase “if localization is disabled” is at least a little
> bit wrong. But I don’t think the setting is ignored, as there are tests
> confirming that it works:
> https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/tests/forms_tests/tests/test_input_formats.py#L123-L125
> . The line that reads the setting should be this one:
> https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/django/utils/formats.py#L132
> .
>
> If you can provide a failing minimal project, that would be useful to keep
> debugging. I have some minimal django project templates at
> https://github.com/adamchainz/django-startproject-templates .
>
> On Tue, Mar 5, 2024, at 8:48 AM, Arthur Pemberton wrote:
>
> Thanks, I'll look into that. But does that mean that
> settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic
> flows that lead to it being used.
>
> On Tue, Mar 5, 2024 at 3:00 AM David Sanders 
> wrote:
>
> Define TIME_INPUT_FORMATS in your local formats.py setup as per:
> https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files
>
> On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton  wrote:
>
> The documentation (
> https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says
> that " the default input formats are taken from the active locale format
> TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS
> <https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-TIME_INPUT_FORMATS>
> if localization is disabled". However, neither my reading of the code, or
> my actual experience shows settings.TIME_INPUT_FORMATS ever being used,
> even with "USE_I18N = False"
>
> TimeField gets the formats from `input_formats =
> formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of
> `formats.get_format` -- the documentation of which says "If use_l10n is
> provided and is not None, it forces the value to be localized (or not),
> otherwise it's always localized."
>
> so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be
> ignored.
>
> How does one use settings.TIME_INPUT_FORMATS ?
>
> Arthur Pemberton
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CA%2BX