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

[Tom Carrick]

I'm in favour of this change, and nice that you're thinking about the
future, but if you're going to write a ticket for this I would focus it on
purely the strictly necessary parts to update to the new API, and when that
is done, make more proposals to simplify the API as you suggest.

I say this just with the goal of getting something that is easy to agree on
merged, before dealing with potentially contentious things
like EmailMultiAlternatives, MIMEBase, etc.

Ignore me if this is irrelevant and those things are indeed necessary, my
knowledge on the topic is a bit lacking.

Tom

On Thu, 27 Jun 2024 at 03:28, Mike Edmunds  wrote:

> Since the early feedback seems positive (though we're still waiting for
> more votes), here's some additional detail on the changes I think would be
> involved to update django.core.mail to use Python's modern email API.
>
> (See my earlier message
>  
> for
> background on Python's legacy vs. modern email APIs and why updating is
> useful.)
>
> Note: Django and Python both have classes named EmailMessage. I'm using
> "Django EmailMessage" to refer to django.core.mail.message.EmailMessage,
> and "Python EmailMessage" (or sometimes just "modern API") to refer to
> Python's modern email.message.EmailMessage.
> Necessary work
> 
>
>1.
>
>Update tests.mail.tests to use modern email APIs
>
>Where a test relies on legacy implementation details, try to rewrite
>it to be implementation agnostic if possible; otherwise try to retain the
>spirit of the test using modern APIs.
>
>Retain all security related tests, with updates as appropriate. (Even
>where we know Python's modern API handles the security for us, it doesn't
>hurt to double check.)
>
>Probably need to add some cases for existing behavior not currently
>covered by tests, particularly around attachments and alternatives.
>
>Remove a test case *only* if it's truly no longer relevant and can't
>be usefully updated. (And perhaps leave behind a brief comment explaining
>why.)
>
>(Legacy email APIs used in tests.mail.tests: email.charset,
>email.header.Header, MIMEText, parseaddr. Also message_from_… currently
>defaults to legacy policy.compat32.)
>2.
>
>Update django.core.mail.message.EmailMessage to use modern email APIs
>
>Change Django's EmailMessage.message() to construct a modern
>email.message.EmailMessage rather than a SafeMIME object (which is based on
>legacy email.message.Message with policy=compat32). Add a
>message(policy=default) param forwarded to Python's EmailMessage
>constructor.
>
>Hoist alternative part handling from Django's EmailMultiAlternatives
>into Django's base EmailMessage to simplify the code. (More on this below.)
>
>In _create_alternatives(), use modern add_alternative()
>
> 
>  and
>friends to replace legacy SafeMIME objects.
>
>In _create_attachments(), use modern add_attachment()
>
> .
>Handle (legacy Python) MIMEBase objects as deprecated, and convert to
>modern equivalent. This is a relatively complex topic; I'll post a separate
>message about it later. (I also have some questions about how best to
>handle content-disposition "inline" and whether we want to somehow support
>multipart/related.)
>
>Remove the private Django EmailMessage methods
>_create_mime_attachment() and _create_attachment() (without deprecation).
>
>(Legacy APIs used in django.core.mail.message: email.message.Message,
>email.charset, email.encoders, email.header, email.mime, email.utils)
>3.
>
>Deprecate unused internal APIs from django.core.mail.message
>
>Django will no longer need these (Python's modern email API covers
>their functionality), but they may be in use by third-party libraries:
>- utf8_charset
>   - utf8_charset_qp
>   - RFC5322_EMAIL_LINE_LENGTH_LIMIT
>   - BadHeaderError^ (more details below)
>   - ADDRESS_HEADERS
>   - forbid_multi_line_headers()^
>   - sanitize_address() (more details below)
>   - MIMEMixin
>   - SafeMIMEMessage
>   - SafeMIMEText^
>   - SafeMIMEMultipart^
>
>(Items marked ^ are exposed in django.core.mail via __all__. I haven't
>looked into the reason for that.)
>4.
>
>Update django.core.mail.__init__ to avoid EmailMultiAlternatives, and
>django.core.mail.backend.smtp to replace sanitize_address. (More details
>below.)
>5.
>
>Update docs
>- deprecation of legacy MIMEBase in attachments list, what to do
>   instead
>   - eliminate EmailMessage/EmailMultiAlternatives distinction
>   - dep

Re: Update returning

[Tom Carrick]

I think it's okay to return something else based on a parameter. This is
already done for e.g. values_list(flat=True) and values_list(named=True).

While the bool addresses the obvious footgun I think it also loses a lot of
flexibility. If you have a field modified by a pre-update trigger or a
generated field that uses a field you updated, you wouldn't be able to see
these without another query, as I understand it.

On Sat, 7 Oct 2023 at 19:20, aivars.kalv...@gmail.com <
aivars.kalv...@gmail.com> wrote:

> Hi!
>
> I considered making `returning: bool` a flag that we are returning data.
> That would make it  `Foo.objects.update(x=1, y=2, returning=True)` and
> avoid some footguns. Or even a new function (`update_returning`?) because I
> have mixed feelings about different return types based on parameters.
>
> Returning fields other than ones updated is a valid case IMO: we can
> update some records and return the PKs of updated records for logging
> instead of having just the number of rows updated. Something
> like`.values_list('pk', flat=True)` is useful then.
>
>
>
>
>
> On Sat, Oct 7, 2023 at 6:46 PM Tom Carrick  wrote:
>
>> Hi Aivars,
>>
>> Since we spoke yesterday I've been thinking about this...
>>
>> I don't really see the value in returning a QuerySet. There are only a
>> limited number of options that make sense at this point, and even those are
>> tough to justify. Like what would happen if you do `Foo.objects.update(x=1,
>> returning=["x"]).values("y")`?
>>
>> I do see value in returning the model instances, though I feel there is a
>> potential footgun here where you can update a field, but not return it, so
>> you'd get the old value in the instance. Something like:
>>
>> `Foo.objects.update(x=1, y=2, returning=["x"])`
>>
>> Now you have updated y, but the model instance that gets returned still
>> has the old value. Maybe this is fine with a warning in the docs.
>>
>> I think regardless of what we do here, we should stick with the proposed
>> and roughly agreed upon API of having an extra argument to `update()`
>> rather than creating a new QuerySet method.
>>
>> Cheers,
>> Tom
>>
>>
>> On Tue, 3 Oct 2023 at 23:38, Plamedi klj  wrote:
>>
>>> Bien
>>>
>>> Le lun. 25 sept. 2023 à 17:44, Aivars Kalvāns 
>>> a écrit :
>>>
>>>> Hi!
>>>>
>>>> I want to implement these changes and I have a PR in the ticket
>>>> https://code.djangoproject.com/ticket/32406
>>>> At the moment I have a new `update_returning` method but I can easily
>>>> replace it with ` (updates=None, *, returning:bool=None, **kwargs)` if you
>>>> decide to add functionality to the existing method instead. I did a search
>>>> on github and found only a single project with `returning` as model field.
>>>> However the returned value in my implementation is a `QuerySet` and I
>>>> can do `.get()`, `.only()`, `.defer()` and `.values()` or `.values_list()`
>>>> on that. Mainly because my use case is updating and refreshing the model in
>>>> a single database operation. The ticket has more examples. What do you
>>>> think, do you see any issues with this approach?
>>>>
>>>> trešdiena, 2021. gada 12. maijs 15:18:50 UTC+3 Tom Carrick rakstīja:
>>>>
>>>>> Apologies, I had totally forgotten about this, but I'm still
>>>>> interested in working on it, but still not sure about a few things.
>>>>>
>>>>> I've been thinking about the return value a bit. I can foresee cases
>>>>> where you wouldn't want the id returned.  You might want the user to 
>>>>> update
>>>>> something by slug, username, or some other identifier without revealing 
>>>>> the
>>>>> IDs. Of course the user could reformat the return value however they like,
>>>>> but I don't see a reason to ask for something that isn't necessary.
>>>>>
>>>>> So I think a list of some kind of object (namedtuple or dict probably)
>>>>> makes the most sense to me. As for also adding the count, I am not sure.
>>>>> The return value would then be e.g. (1, []). I'm guessing this count
>>>>> would remain as the number of matched rows, rather than the updated ones -
>>>>> I am not sure if returning only gives back rows that were modified or not,
>>>>> the Postgres docs are at least unclear

Re: Update returning

[Tom Carrick]

Hi Aivars,

Since we spoke yesterday I've been thinking about this...

I don't really see the value in returning a QuerySet. There are only a
limited number of options that make sense at this point, and even those are
tough to justify. Like what would happen if you do `Foo.objects.update(x=1,
returning=["x"]).values("y")`?

I do see value in returning the model instances, though I feel there is a
potential footgun here where you can update a field, but not return it, so
you'd get the old value in the instance. Something like:

`Foo.objects.update(x=1, y=2, returning=["x"])`

Now you have updated y, but the model instance that gets returned still has
the old value. Maybe this is fine with a warning in the docs.

I think regardless of what we do here, we should stick with the proposed
and roughly agreed upon API of having an extra argument to `update()`
rather than creating a new QuerySet method.

Cheers,
Tom


On Tue, 3 Oct 2023 at 23:38, Plamedi klj  wrote:

> Bien
>
> Le lun. 25 sept. 2023 à 17:44, Aivars Kalvāns 
> a écrit :
>
>> Hi!
>>
>> I want to implement these changes and I have a PR in the ticket
>> https://code.djangoproject.com/ticket/32406
>> At the moment I have a new `update_returning` method but I can easily
>> replace it with ` (updates=None, *, returning:bool=None, **kwargs)` if you
>> decide to add functionality to the existing method instead. I did a search
>> on github and found only a single project with `returning` as model field.
>> However the returned value in my implementation is a `QuerySet` and I can
>> do `.get()`, `.only()`, `.defer()` and `.values()` or `.values_list()` on
>> that. Mainly because my use case is updating and refreshing the model in a
>> single database operation. The ticket has more examples. What do you think,
>> do you see any issues with this approach?
>>
>> trešdiena, 2021. gada 12. maijs 15:18:50 UTC+3 Tom Carrick rakstīja:
>>
>>> Apologies, I had totally forgotten about this, but I'm still interested
>>> in working on it, but still not sure about a few things.
>>>
>>> I've been thinking about the return value a bit. I can foresee cases
>>> where you wouldn't want the id returned.  You might want the user to update
>>> something by slug, username, or some other identifier without revealing the
>>> IDs. Of course the user could reformat the return value however they like,
>>> but I don't see a reason to ask for something that isn't necessary.
>>>
>>> So I think a list of some kind of object (namedtuple or dict probably)
>>> makes the most sense to me. As for also adding the count, I am not sure.
>>> The return value would then be e.g. (1, []). I'm guessing this count
>>> would remain as the number of matched rows, rather than the updated ones -
>>> I am not sure if returning only gives back rows that were modified or not,
>>> the Postgres docs are at least unclear on this. If they're always going to
>>> be the same, I'm not sure there is much reason for returning the count when
>>> len(return_value) will do.
>>>
>>> I'm also not really sure on the data structure though. Namedtuples make
>>> the most sense to me but a dict might be useful for those wanting to shove
>>> this directly into JsonResponse, without needing _asdict(), for example.
>>>
>>> Cheers,
>>> Tom
>>>
>>> On Wed, 27 Jan 2021 at 10:45, Florian Apolloner 
>>> wrote:
>>>
>>>> Hi Simon,
>>>>
>>>> On Wednesday, January 27, 2021 at 5:54:42 AM UTC+1 charettes wrote:
>>>>
>>>>> I think that's the best option here if we want to elegantly add
>>>>> support for this feature while maintaining backward compability. Something
>>>>> along the lines of ...
>>>>>
>>>>
>>>> That is certainly an interesting approach. It kinda breaks the "there
>>>> should be one way of doing things" rule, but…
>>>>
>>>> The usage of `returning` bring another set of questions though. Since
>>>>> UPDATE are not ordered RETURNING data has little value without the primary
>>>>> key associated with the updated rows. Maybe the return value of
>>>>> `returning=[f1, ..., fn]` should be a dict mapping the primary key to list
>>>>> of returning values.
>>>>>
>>>>
>>>> I am not sure I like that. For things where you update just one row and
>>>> want to know the new values the primary ke

Re: Proposing the removal of Oracle from the Django supported backend databases

[Tom Carrick]

I don't have a strong opinion in either direction here.

I would like to point out that every database we support is a maintenance
burden, however. It's an exaggeration that Oracle alone causes problems but
other backends don't. For example when I was working on collations, I ran
into issues with SQLite's lack of good ways to inspect the database. I ran
into problems with MySQL's lacking documentation on collations and its
seeming semi-support for it. I ran into problems with Postgres as you need
to create some of its more powerful collations in SQL first. I also ran
into issues with Oracle, but they were actually easier to overcome than
some of the others.

I also gave up on an attempt at an EnumField for models because Postgres
handles them in a totally different way from other databases and it ended
up raising so many questions that I just gave up.

I would say, however, that Oracle usually has perhaps more than its share
of problems. And of course Oracle's lack of financial support gives impetus
to care less about it, as we seemingly do for MS SQL server, which probably
sees more use overall than Oracle. Bur Oracle is already established in the
codebase.

It also shouldn't be forgotten that while 2% as a relative number is quite
small, the absolute number of people it will affect is quite large, and I
certainly wouldn't call it "irrelevant".

I wouldn't be against moving it to jazzband, say, but without people
stepping up to maintain it (and there is an impetus for this when it's in
Django's codebase), it may just end up abandoned.

Tom

On Thu, 3 Aug 2023 at 13:27, Jörg Breitbart 
wrote:

> +1 from my side for removing oracle support from django itself.
>
> If very low usage + high maintenance burden does not qualify for feature
> removal, idk what does - maybe not being supportive at all. Oh wait...
>
> In the end such low usage numbers are prolly better served by a 3rd
> party package.
>
> Regards,
> Jerch
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0380eceb-c0bc-1a81-411b-b8e0e8588c83%40netzkolchose.de
> .
>

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

Re: Django's automatic admin interface.

[Tom Carrick]

IMO, if we were going to modernise the admin (which is laudable), it
wouldn't be by using JS frameworks or Tailwind, but by simplifying things
further, by removing the last bits of JQuery, simplifying the HTML and
making it more semantic, and rewriting the CSS to use a grid based layout
and cut down the amount of code that is needed to achieve the same result.

I don't have anything against Tailwind or Vue per së, but forcing every
Django project to have them in the backend seems too opinionated and too
much of a maintenance burden.

As you mentioned, there are already opinionated packages out there, I'm
happy they exist, but in my opinion they belong in external packages, not
in core.

Tom

On Wed, 19 Apr 2023 at 11:45, Dipankar  wrote:

> Sorry if my question is wrong.. .. Not exactly technology I wanted to know
> about the frontend framework like tailwindCSS,react or Vue.
>
> In nutshell I want admin interface with tailwindCSS/React/Vue. any
> suggestion ?
>
> On Wed, Apr 19, 2023 at 3:01 PM David Sanders <
> shang.xiao.sand...@gmail.com> wrote:
>
>> Hi Dipankar,
>>
>> Not being rude but serious question: What's the latest front end
>> technology? :)
>>
>> On Wed, 19 Apr 2023, 7:27 pm Dipankar,  wrote:
>>
>>> Is there any plan to replace Django's automatic admin interface with the
>>> latest front end technology?
>>> There are several packages available but what if Django itself provides
>>> the same as core.
>>>
>>> --
>>> Warm Regards,
>>> Dipankar B.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/CAFdBwp_N0remvp8zAPFVda6iyFWVWR%3DZh0EtfE9fzYcPQVixkQ%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/CADyZw-61oX4oh3apDatm_MKCdoYCMLxkk8O4krKMZuPZF2LpNg%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Warm Regards,
> Dipankar B.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFdBwp-cO_g_JCTQhMQVEJe%2BN4FjJD5F-D%2B7LKugRK%2B1-Pq3Rg%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/CAHoz%3DMY5g6fxw8DXCEhm%2BoQDW3isSCBGk7kYhdwB3Omdg4%3DjAQ%40mail.gmail.com.

Re: Deprecate CICharField, CIEmailField, CITextField

[Tom Carrick]

Hi,

I wrote most of the code for collation support, and I also argued (softly)
against deprecating citext support for the reasons you stated.

However, I've changed my mind on this now. As you can't index the citext
column for LIKE queries, doing these types of searches on any real amount
of data is going to be too slow in most cases. I actually think the best
practice right now for having searchable case-insensitive emails is to do
it old-school - have a regular EmailField with an index on UPPER("email")
and then make sure you always use iexact, istartswith etc. and this will
properly use the indexes and result in a faster search.

So I see very few advantages now to keeping CITEXT at all, and they're
quite easy to add as a third party package as Mariusz suggested if anyone
is so inclined.

Cheers,
Tom

On Wed, 12 Apr 2023 at 12:09, Mariusz Felisiak 
wrote:

> Hi
>
> > Unless we want to drop support for the CITEXT extension, ...
>
> What do you mean by that? As far as I'm now, we don't do anything special
> to support CITEXT extension 🤔.
>
> > I'd caution to revert the deprecation and keep support ...
>
> I'm obviously biased as the author of this proposition and patch, however,
> IMO, small differences between using CI fields and collations don't justify
> maintaining 3 additional fields that were mostly untested. Also, they are
> deprecated in a LTS so folks still have *3* more years to update their
> code. In the worst case someone can create 3rd party package with them.
>
> Unless something is fundamentally broken I'm against reverting.
>
> Best,
> Mariusz
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5c11b704-68c4-490d-84bf-90c734cc02d1n%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/CAHoz%3DMb25iGN%2BHodxgE6Y%2B5d%2B5qoHERvkMiuiHrs%3DXnpeC%3D-xg%40mail.gmail.com.

Re: Add a minimal Gitignore

[Tom Carrick]

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 it's time for Django to reconsider and catch up with the times?
>>
>> Cory
>>
>>
>>
>>
>> On Fri, Mar 10, 2023 at 7:03 AM Mariusz Felisiak 
>> wrote:
>>
>>> Hi Daniel,
>>>
>>> Adding .gitignore to the project template has been discussed and
>>> rejected multiple times, e.g.
>>> https://github.com/django/django/pull/13847
>>>
>>> Best,
>>> Mariusz
>>>
>>> --
>>>
>> You received this message because you are subscribed to the Google Groups
>>> "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-develop...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/fd500891-f348-488a-863b-04c372d1bf4bn%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/eda6005e-a4f0-4f15-85dc-d78740227300n%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/CAHoz%3DMZvOnWQQ6n0MLPZAY%3DwDvM%3DNutGKbReVOVbyd5khgdi0w%40mail.gmail.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Tom Carrick]

Just a small spinoff idea from Adam's suggestion on django-stubs. There is
another package, django-types that started as a fork of django-stubs and
was originally intended to be merged back into it. It removes the need to
use any mypy plugins, making it possible to use type checkers other than
mypy, such as Pyrite, Pyre, etc.  However, django-types isn't nearly as
actively maintained and having competing type stubs libraries is quite
annoying as they each get fixes for different issues, leaving neither in
especially good shape, IMO. Although the work has previously been done I
think there is enough work there detangling it and getting a PR to a
mergeable state for a short project.

Tom


On Sat, 26 Nov 2022 at 17:02, Shai Berger  wrote:

> Hi,
>
> Adding to the above, I have two migration-related ideas.
>
> The first is quite down-to-earth: Support for moving models between
> apps. This is a long-standing problem, esp. in enterprise-y or just
> long-running projects. I have expressed my dissatisfaction with the
> current state of things a couple of years ago[1], and maybe it's time
> to change that.
>
> The second is a bit of a pie-in-the-sky: Allow auto-detection of custom
> migration operations. The auto-detector has its change-detection mostly
> hard-coded into it[2], and it doesn't seem easy or even possible to
> allow third-party code to intervene. But I dream...
>
> Note: These two are quite independent. Auto-detection of the fact that
> a model has moved between apps is not required, supporting such moves
> with flags to makemigrations or even a dedicated management-command
> would be completely satisfactory as far as I'm concerned.
>
> Thanks,
> Shai.
>
>
> [1] https://forum.djangoproject.com/t/why-do-we-need-apps/827/20
> [2]
> https://github.com/django/django/blob/main/django/db/migrations/autodetector.py#L104
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/20221126180231.372b01a2.shai%40platonix.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/CAHoz%3DMbM1M26%2BtrKwX7CoAK_VmORNQGLMLCn_WC5vhAP4PuU4g%40mail.gmail.com.

Re: Improvements to the startproject template

[Tom Carrick]

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...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/a184bfc1-e3fb-4bd7-8378-292194e52595n%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/ffb8a027-d5c7-53b4-1ea7-c9f687b8c80d%40martinhome.org.uk
> 
> .
>

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

Re: Deprecate CICharField, CIEmailField, CITextField

[Tom Carrick]

Hi,

I'm not too sure about this.

While Postgres encourages using non-deterministic collations, they're not
without their downsides. For example, you can't do a LIKE query on a field
using a non-deterministic collation, but you can with CItext - although I
don't believe there's a way to index it. Say, for example, you want to
store your user emails CI - this is great for logging in but it makes it
impossible to search for users with a particular email domain, or trying to
find someone by the username part, say.

On the other hand, we could just say: don't use either, put an index on
UPPER and make sure you always use iexact.

I don't have a very strong opinion.

Cheers,
Tom


On Tue, 25 Jan 2022 at 14:01, Paolo Melchiorre  wrote:

> Hi Mariusz,
>
> I agree with you on deprecating and then removing CI fields.
>
> I only would suggest adding some examples of migrations from CI fields
> to collations in the deprecation notes to help users to easily
> migrate.
>
> So +1 for me too.
>
> Ciao,
> Paolo
>
> On Tue, Jan 25, 2022 at 1:39 PM Mariusz Felisiak
>  wrote:
> >
> > Hi y'all,
> >
> > Django 3.2+ supports "db_collation" [1] for "CharField" and
> "TextField" along with migration operations ("CreateCollation()",
> "RemoveCollation") and the database function "Collate()" [3]. Moreover CI
> fields and the entire "citext" module are discouraged since PostgreSQL 12
> [4] in favor of collations. I think it's time to deprecate CI fields from
> the "contrib.postgres" in favor of "CharField" and "TextField" with case
> insensitive collations (and remove them in Django 5.0).
> >
> > Best,
> > Mariusz
> >
> > [1] https://code.djangoproject.com/ticket/31777
> > [2] https://code.djangoproject.com/ticket/32046
> > [3] https://code.djangoproject.com/ticket/21181
> > [4] https://www.postgresql.org/docs/12/citext.html
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to django-developers+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/833bb13b-3db1-f35b-3d51-a2a4671b45a9%40gmail.com
> .
>
>
>
> --
> Paolo Melchiorre
>
> https://www.paulox.net
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx5j8Y6%2BMH_%2Bug-BGKZ6qaWD9tRWVLXLOXhmTQuvrN8tzw%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/CAHoz%3DMZH_eFng_eehDYkWAf7GnW27XFr7wa9%3D4tqjeDvxJrCsA%40mail.gmail.com.

Re: (Circa end of 2021) Localization issues with input type=date?

[Tom Carrick]

Hi,

It's true that the value is required to be in -MM-DD format, but in
modern browsers (which I think is what we claim to support now, right?) it
will show in the user's localised format. I checked this in Firefox,
Chrome, Edge, and they all look good to me - they come with both a date
picker, and allow you to enter the date in your local format. So I think
the time has come where this might be a beneficial change (for #21470).
However, Firefox is lacking a picker for 
until the next version, though presumably that will be released before any
change here would make it in.

Probably the problem here is that if we make this the default, we will
break people's code who are not explicitly rendering their forms.

It also might be nice to use these in the admin and remove our own date
picker code, if it doesn't pose any problems.

I realise this isn't actually an answer to your initial question, though.

Cheers,
Tom

On Tue, 28 Sept 2021 at 11:16, Carlton Gibson 
wrote:

> Hi all.
>
> There's a PR to add examples using `` for
> `forms.DateInput`.
> https://github.com/django/django/pull/14905
>
> Support for HTML5 input types was added a long time back now in #16630
> .
> Back then there were various issues with localisation when **not** using
> type=text.
> See https://code.djangoproject.com/ticket/16630#comment:11 and following
> discussion.
> The original mailing list thread is here
> 
> .
>
> The goal is to say something succinct but accurate that covers both sides
> of "Why the default is type=text" and "What you need to consider using
> type=date".
>
> Can we solicit some input (🥁) on what issues folks hit? — specifically
> for DateInput the concern was the required date format (I think).
>
> It may well be that things have changed since 2012? (If so we might
> revisit #21470 .)
>
> Thanks.
> Carlton
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/16d05604-4068-4423-9ac4-f8f520d44a42n%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/CAHoz%3DMYCeFm-CHosr6TE%2BmuO3%2BgY-B97KmskozNX5rfYi4GMkA%40mail.gmail.com.

Re: Django's issue tracker uses timezone CDT

[Tom Carrick]

While moving the default to UTC is probably a good idea - you can change
this for yourself in Preferences -> Localization.

Tom

On Fri, 6 Aug 2021 at 16:22, Jacob Rief  wrote:

> This presumably is a legacy from the days when Adrian Holovaty and
> Jacob Kaplan-Moss started the Django project in Kansas City.
>
> The Django issue tracker uses the timezone CDT which is correct for
> central Americas,
> but since Django became a world wide project, in my opinion this should
> either
> be UTC, or if possible, the browser's local time.
>
> Is there any reason, why this never has been adjusted?
>
> – Jacob
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9d952402-1efd-419e-b4a5-0f8635c1ac73n%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/CAHoz%3DMaOq8Hj_8hnjdM%3D9to6mRSQLppZ5oHWJjQ9CA8H%3Dsqq6Q%40mail.gmail.com.

Re: Recognising Contributions

[Tom Carrick]

This is something I've been thinking about a bit as well.

Mostly I think adding authors to the release notes is probably the best
bang for buck in terms of recognition. This is what I was mostly thinking
about myself. The release notes are (I believe) very widely read,
especially in comparison with anything on GitHub.

The other suggestions are, I think, good and worthwhile, but probably not
as impactful.

I am interested / curious about your last point. I think adding some
recognition to in person events might be nice, but I'm not sure what it
would look like in practice.

Tom

On Mon, 5 Jul 2021 at 17:38, 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> I'm all for exposing names in more places.
>
> Linking through to PR's from the release notes would also be useful for
> "pulling back the curtain" and making Django's code a bit less magical.
> Plus it could help the workflow for current contributors.
>
> On Mon, 5 Jul 2021 at 16:07, Tom Forbes  wrote:
>
>> Perhaps we could do this as part of a Sphinx plugin? Right now each entry
>> in the release notes is only implicitly tied to the pull request that adds
>> it.
>>
>> If we could add some kind of pull request ID marker to the release note
>> entries we could create an inline link to the PR (which might be very
>> useful by itself) as well as using it derive a list of contributors for
>> each release.
>>
>> Tom
>>
>> On Wed, 30 Jun 2021 at 09:16, Carlton Gibson 
>> wrote:
>>
>>> Hi David,
>>>
>>> Thanks for this. Yes.
>>>
>>> Let's assume the 2020-2021 time filter is in place.
>>>
>>> Mariusz recently picked up James' PR to add the list of Core
>>> Contributors (back) to the website, which is/was part of the DEP 10
>>> governance changes.
>>> https://github.com/django/djangoproject.com/pull/1099
>>>
>>> The hope is that the DSF Board will approve that in their next meeting,
>>> and we can get it live. With hindsight we perhaps could have moved quicker
>>> but, the idea was to move on from there to recognise current and new
>>> contributors on a more ongoing basis too.
>>>
>>> So... my hope was to probably do something per-major release — so 3.2,
>>> 4.0, 4.1, etc. (Maybe we could do it every month but...)
>>>
>>> * Who were the contributors?
>>> * Who were the new contributors?(Special callout)
>>> * Who was on the Triage and Review team? ('cause it ain't just code)
>>> * And, can we identify other folks to call out...? (T&R team was an
>>> attempt to capture participation here.)
>>>
>>> I think Simon's github-to-sqlite tool is a good candidate.
>>> Some others I've collected whilst this has been bubbling on the
>>> low-ring:
>>>
>>> * Katie McLaughlin provided some git log pointers
>>> https://glasnt.com/blog/script-o-hatrack/
>>> * See also https://github.com/LABHR/octohatrack
>>> * GitHub built this based on Simon's ideas:
>>> https://octo.github.com/projects/flat-data
>>> * "A git query language" https://github.com/filhodanuvem/gitql
>>> * "git quick stats" https://github.com/arzzen/git-quick-stats
>>>
>>> I think there's plenty of tooling there to show how to get the info we
>>> want.
>>> At a guess it's a couple of evenings exploring, and then pulling it into
>>> a report.
>>>
>>> I think if we were to do something along these lines, starting a new
>>> tradition, for Django 4.0 in December, that would be really great.
>>>
>>> I'm not sure as yet on the exact format to present all that.
>>> The blog post for the _Final_ versions could say more without too much
>>> difficulty.
>>> (e.g.
>>> https://www.djangoproject.com/weblog/2021/apr/06/django-32-released/ )
>>>
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>>
>>>
>>>
>>> On Tuesday, 29 June 2021 at 21:35:16 UTC+2 smi...@gmail.com wrote:
>>>
 Hi all,

 I've had this sat in my drafts for a while. Rather than let it sit on
 the shelf any longer I thought it better to share.

 I've been thinking about recognising contributions recently. The main
 issue with the notes here is that it focuses on code rather than
 contributions to the wider Django ecosystem. However, if there are
 improvements that we could make here I think we should explore those, and
 maybe some of them could be used more widely.

 Here are a few ideas of how contributions could be recognise following
 a peer review of other projects. Some are better than others, some are
 easier to implement than others. Hopefully something to prompt some
 discussion. What do folk think? How would you feel if you were recognised
 in one of these ways?

 - Add Python style `contributed by` in the release notes. I'm not so
 sure about adding the ticket number (in fact I think I saw Nick Pope point
 to something today that says we don't ref tickets?). [1]

 - For the headline features add names to the blog post [2]. Could also
 add link to their blog / website /Twitter (less sure about this second
 part).

 - The blog

Re: A base compression middleware class

[Tom Carrick]

It's also worth noting that the security issue mentioned in the docs[1]
makes it unsuitable for many (most?) Django projects, unfortunately, and
brotli is also susceptible to this attack.

It's probably not something I'd be keen on encouraging the use of, though I
also think the idea in principle is a good one.

[1]
https://docs.djangoproject.com/en/3.2/ref/middleware/#django.middleware.gzip.GZipMiddleware

Tom

On Tue, 15 Jun 2021 at 02:16, Curtis Maloney  wrote:

> Hi Illia,
>
> I like the idea here, and your design looks sensible at first blush, but I
> feel conflicted.
>
> As much as I like the idea of allowing more flexibility and
> future-proofing this middleware,
> AIUI the gzip middleware is generally discouraged, as it's typically more
> efficient to have your web server do this work.
>
> I'd be more tempted to deprecate GzipMiddleware in core, and move this
> feature into a 3rd party app.
>
> An additional hook for your interface: a function to test if this
> compressor should be used on this response. For instance, the gzip
> middleware has a minimum size below which it's deemed not worth the effort
> to try to compress.
>
> --
> Curtis
>
>
> On Tue, 15 Jun 2021, at 04:49, Illia Volochii wrote:
>
> Hi all,
>
> There is `GZipMiddleware` that compresses response bodies using gzip.
> https://github.com/django/django/blob/main/django/middleware/gzip.py
>
> But there are other algorithms supported by browsers (e.g., Brotli).
> At the moment, if somebody wants to add support for any of them in a
> Django project, one has to create a new middleware class redefining
> all the logic processing responses.
>
> I propose simplifying the process by creating
> `BaseCompressionMiddleware`. Its subclasses would just need to define
> a tuple of supported compressors.
>
> The tuple elements could be instances of such a data class:
> ```
> @dataclass
> class Compressor:
> name: str
> compress_string_func: Callable[[bytes], bytes]
> compress_sequence_func: Optional[
> Callable[[Iterable[bytes]], Iterator[bytes]]
> ] = None
>
> def is_accepted_by(self, accept_encoding):
> return bool(re.search(rf'\b{self.name}\b', accept_encoding))
> ```
>
>
> And the class could select a compressor using such code:
> ```
> @classmethod
> def select_compressor(cls, request, response):
> ae = request.META.get('HTTP_ACCEPT_ENCODING', '')
> for compressor in cls.compressors:
> if (
> compressor.is_accepted_by(ae)
> and (not response.streaming or
> compressor.compress_sequence_func)
> ):
> return compressor
> ```
>
>
> Note, in the example `compress_string_func` is required and
> `compress_sequence_func` is optional. I think that
> `compress_string_func` would usually be a library function, and
> `compress_sequence_func` would require some custom logic. And we
> should not force users to define the latter.
>
> `GZipMiddleware` could be changed to
> ```
> gzip_compressor = Compressor(
> name='gzip',
> compress_string_func=compress_string,
> compress_sequence_func=compress_sequence,
> )
>
> class GZipMiddleware(BaseCompressionMiddleware):
> compressors = (gzip_compressor,)
> ```
>
>
> And someone wanting to support both Brotli and gzip could define:
> ```
> import brotli
> from django.middleware.gzip import gzip_compressor
>
> brotli_compressor = Compressor(
> name='br',
> compress_string_func=brotli.compress,
> )
>
> class CompressionMiddleware(BaseCompressionMiddleware)
> compressors = (brotli_compressor, gzip_compressor)
> ```
>
>
> Please let me know what you think about such an enhancement.
> I will be happy to create a pull request if this is accepted.
>
> Thanks,
> Illia
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/49535d7e-758c-4acf-a9da-831ccfa1d17bn%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/c4cef215-7cae-4c6b-a9b2-7b4785b3a9bf%40www.fastmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Djan

Re: Changing widget rendering templates

[Tom Carrick]

I agree with everything said here so far.

I just want to add that I wonder if it is perhaps a good idea to deprecate
and dedocument as_p and friends, but leave them in the code base for
existing projects?

Tom

On Sun, 6 Jun 2021, 09:25 smi...@gmail.com,  wrote:

> Hi All,
>
> Thanks for your repsonses and guidance.
>
> I think for the widget changes we have far less flexibility than with
> forms where folk are already using various as_* functions. I'll therefore
> progress with the widget ticket as a breaking change.
>
> For the form changes I think it makes sense to make the existing as_*
> forms as accessible as we can. We can also intoduce a new template that is
> a "best practice" implementation. Making this the defualt while breaking
> wouldn't be too hard for folk to adjust as they would just use `as_table`.
>
> Hopefully I've understood this correctly.
>
> Thibaud -- just a few comments on your email.
>
> > widgets’ rendering to fix:
>
> Looking at the ticket, I think these would require changes to the form
> render rather than the widget. Once we have the template rendering of forms
> PR merged, I think these will be easier to implement.
>
> >  Or provide alternative forms you might already be aware of,
>
> The test project for crispy-forms has a django rendered page, this could
> be of help? https://github.com/django-crispy-forms/crispy-test-project
>
> > showcasing more advanced widget configurations
>
> Looking at your page I think the couple of additional items which would be
> useful to get your views on would be:
>
> - A grouped input (rendered with select, checkbox and radio widgets). I am
> not sure "grouped input" is the right terminology, I'm trying to expain the
> `MEDIA_CHOICES` example as shown here.
> https://docs.djangoproject.com/en/3.2/ref/models/fields/#django.db.models.Field.choices
>
> - A multifield/multiwidget. `SplitDateTimeField` is a good example.
> Personally, I've found this one troublesome (
> https://forum.djangoproject.com/t/accessibility-for-splitdatetimefield/6871
> )
>
> Kind Regards
>
> David
>
> On Sunday, 6 June 2021 at 01:22:19 UTC+1 Thibaud Colas wrote:
>
>> Hi all,
>>
>> I wanted to mention a couple more things that might help in the decision:
>>
>>
>>- There is no direct accessibility issue *for end users* from `as_p`
>>that I know of. The only issue is its propensity to making people create
>>forms with invalid HTML (see #31189
>>), which is problematic
>>when running HTML validation, and is a failure of WCAG 2.1 level A SC
>>4.1.1 Parsing
>> (this
>>standard being the most likely target for Django, although there is no
>>official target as of now).
>>- I’ve just opened two tickets that, if confirmed, would require
>>additional changes to the widgets’ rendering to fix: #32819
>>, #32820
>>.
>>
>> I imagine we want to release changes to forms’ rendering as infrequently
>> as possible. If we considered grouping those changes all in the same
>> release, it could be worthwhile for me to further review forms and fields
>> for any further issues there might be, so they can be fixed at the same
>> time. One problem I’m facing with this and similar audits is that I almost
>> never use Django’s default markup myself, so it would be nice for others to
>> look at the form I’m using for testing (code
>> 
>> , rendering
>> ) and
>> confirm it’s suitable. Or provide alternative forms you might already be
>> aware of, set up differently or showcasing more advanced widget
>> configurations.
>>
>> Those additional tickets reflect the extent of my audit progress to date.
>> One thing I’m considering but am uncertain of is whether non-field errors
>> would also need ARIA markup, to be more identifiable as errors, and-or
>> programmatically associated with the form. I still need to research this,
>> both according to specs, and with actual support from screen readers.
>>
>> Kind regards,
>>
>> Thibaud
>>
>> On Saturday, 5 June 2021 at 09:31:54 UTC+1 Adam Johnson wrote:
>>
>>> I think a breaking change for the widget HTML is fine too, if it
>>> improves everyone’s apps. Perhaps documenting in the release notes how to
>>> undo it (eg copy this template file into your project, reconfigure the
>>> widget to use the template like so) will make it easier for folks with
>>> incompatible CSS to upgrade.
>>>
>>> On Sat, 5 Jun 2021 at 08:45, Carlton Gibson 
>>> wrote:
>>>
 Hi David.

 Thanks for this. Sorry for the slow pick-up: DjangoCon this week. :)

 I'd say option 1: It's an accessibility change and we should just opt
 people int

Re: Update returning

[Tom Carrick]

Apologies, I had totally forgotten about this, but I'm still interested in
working on it, but still not sure about a few things.

I've been thinking about the return value a bit. I can foresee cases where
you wouldn't want the id returned.  You might want the user to update
something by slug, username, or some other identifier without revealing the
IDs. Of course the user could reformat the return value however they like,
but I don't see a reason to ask for something that isn't necessary.

So I think a list of some kind of object (namedtuple or dict probably)
makes the most sense to me. As for also adding the count, I am not sure.
The return value would then be e.g. (1, []). I'm guessing this count
would remain as the number of matched rows, rather than the updated ones -
I am not sure if returning only gives back rows that were modified or not,
the Postgres docs are at least unclear on this. If they're always going to
be the same, I'm not sure there is much reason for returning the count when
len(return_value) will do.

I'm also not really sure on the data structure though. Namedtuples make the
most sense to me but a dict might be useful for those wanting to shove this
directly into JsonResponse, without needing _asdict(), for example.

Cheers,
Tom

On Wed, 27 Jan 2021 at 10:45, Florian Apolloner 
wrote:

> Hi Simon,
>
> On Wednesday, January 27, 2021 at 5:54:42 AM UTC+1 charettes wrote:
>
>> I think that's the best option here if we want to elegantly add support
>> for this feature while maintaining backward compability. Something along
>> the lines of ...
>>
>
> That is certainly an interesting approach. It kinda breaks the "there
> should be one way of doing things" rule, but…
>
> The usage of `returning` bring another set of questions though. Since
>> UPDATE are not ordered RETURNING data has little value without the primary
>> key associated with the updated rows. Maybe the return value of
>> `returning=[f1, ..., fn]` should be a dict mapping the primary key to list
>> of returning values.
>>
>
> I am not sure I like that. For things where you update just one row and
> want to know the new values the primary key doesn't make much sense.
> Granted for multiple rows it would maybe easier to have it automatically
> keyed by the pk, but returning something always (the pk) without having an
> option to disable  it seems kinda wrong to me. Not sure what the best
> option would be.
>
> Cheers,
> Florian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/4eea605a-57d7-4ce3-b233-3eb88c91e110n%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/CAHoz%3DMa2DVUXHotoHW_XB91eW6imgV_Evc%2B4-ApFqwACEa0jnA%40mail.gmail.com.

Re: On adding comments to database schema

[Tom Carrick]

It's funny that you bring this up, I was actually looking at this today and
thinking about picking it up next week.

Jared, the PR was closed without any comment from the author and is
seemingly abandoned. I think it's safe for you to assign the ticket to
yourself and continue the work in a new PR at this point - that was going
to be my plan, anyway.

Tom

On Thu, 6 May 2021 at 15:16, Jared Chung  wrote:

> KimSoungRyoul would you like help with writing the docs and tests for
> this? I'd like to contribute to Django in some way and this is a feature my
> company would greatly value (we have Data Scientists and DBAs interacting
> with db tables managed by Django, so having comment documentation at the DB
> level would have a huge positive impact). It looks like you received
> feedback on your PR  and
> Mariusz pointed out that docs and tests are needed. I'd be happy to help
> out with the docs and tests if I can. You're marked as ticket owner right
> now on ticket 18468 . Please
> let me know!
> *(Disclosure: I'm new to contributing to Django, and hopeful that this can
> be a good ticket for me to start with. I've been using Django now for a
> decade and am excited to start giving back!)*
>
> On Saturday, May 2, 2020 at 10:24:46 PM UTC-7 kimsou...@gmail.com wrote:
>
>> I'm sorry if I sounded like I was pushing you.
>>
>> even missing checklist
>>
>>
>> 2020년 5월 3일 일요일 오전 1시 42분 2초 UTC+9, Mariusz Felisiak 님의 말:
>>
>>> Asking for a review on multiple channels doesn't help. You need to be
>>> patient, we have many PRs in review queue. Please check "Patch review
>>> checklist" [1]. At first glance, docs are missing.
>>>
>>> [1]
>>> https://docs.djangoproject.com/en/3.0/internals/contributing/writing-code/submitting-patches/#patch-review-checklist
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/62705a74-f16d-42c3-b440-4e3e7628351cn%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/CAHoz%3DMbaEAaV1nt9dL576RvLzDSL_LacJ-fRLAe4Bwo416HDfA%40mail.gmail.com.

Re: Update returning

[Tom Carrick]

Simon, you give me too much credit, that is step beyond what I'd thought of
:) It looks good to me.

Why not a dict of dicts or perhaps a dict of namedtuples instead? I think a
list might be a bit annoying to map back to the requested fields.

Maybe I will try to put a proof of concept together...

Tom

On Wed, 27 Jan 2021 at 05:54, charettes  wrote:

> If we were to change the update signature from (**updates) to
> (updates=None, *, returning=None, **kwargs) the `returning` collision could
> be avoided by doing update({"foo": "bar"}, returning=["id", "foo"]) like
> Tom is suggesting.
>
> I think that's the best option here if we want to elegantly add support
> for this feature while maintaining backward compability. Something along
> the lines of
>
> def update(updates=None, *, returning=None, **kwargs):
> if updates and kwargs:
> raise TypeError('updates must be either specified through the
> first positional argument or kwargs')
> if updates is None:
> updates = kwargs
> ...
>
> I guess we could force the usage of positional `updates` if `returning` is
> specified to prevent any silent breakages as well.
>
> The usage of `returning` bring another set of questions though. Since
> UPDATE are not ordered RETURNING data has little value without the primary
> key associated with the updated rows. Maybe the return value of
> `returning=[f1, ..., fn]` should be a dict mapping the primary key to list
> of returning values.
>
> e.g.
>
> Post.objects.create(id=1, score=41)
> Post.objects.update({"score": F("score") + 1}, returning=["score"])
> -> {1: [42]}
>
> Cheers,
> Simon
>
> Le mardi 26 janvier 2021 à 12:36:10 UTC-5, f.apo...@gmail.com a écrit :
>
>> On Tuesday, January 26, 2021 at 5:26:02 PM UTC+1 Adam Johnson wrote:
>>
>>> Not that I am completely convinced that the following is a good idea;
 but what about:
>>>
>>> QuerySet.objects.update(name="Rob").values("id", "name")

>>>
>>> That's not possible since update() directly performs the update - it's
>>> not lazy in any way. It could be done in the other order like
>>> `QuerySet.objects.values("id", "name").update(name="Rob")` but I don't see
>>> the necessity to define "returning" fields in a chainable manner.
>>>
>>
>> Ha, not sure what I was thinking. The sentence below I noted that
>> update() would return something but I didn't think that this would break
>> chaining. My bad.
>>
>> I looked further around and `get_or_create` has the nice workaround of
>> being able to use `defaults__exact` if it clashes with the `defaults`
>> keyword. Sadly we do not have that option here. Truth to be told I do not
>> think that many people have fields called returning
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/86210b9b-4978-4068-ac61-f1a3061bf2a4n%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/CAHoz%3DMbQgTjar9QKWdhdQt8GcnVZVko8OyEO6K9ci1%3Dq_90Q7Q%40mail.gmail.com.

Update returning

[Tom Carrick]

Hi,

I found myself with a use-case today of wanting to return some data from an
update, as I want to make sure I return exactly what is in the database
without making an extra query.

I've found https://code.djangoproject.com/ticket/28682 and agree with the
resolution there.

I suppose there is a way to do this in a backwards compatible way,
something like:

Foo.objects.update(["id", "name"], name="Rob")

But it's very ugly. But how about a new method:

Foo.objects.update_returning(["id", "name"], name="Rob")

Doesn't seem quite so bad. There's also a possibility of something like:

Foo.objects.update_returning(updates={"name": "Rob"}, returning=["id",
"name"])

I'd expect it to return a list of dicts. I'm not sure what's best, if
anything. It could be it's a bit too niche, but it is sometimes quite
useful.

Tom

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

Re: Quick Filter in the Admin Sidebar

[Tom Carrick]

Hi Maxim,

I think the best thing you can do is add a ticket on trac -
https://code.djangoproject.com/ and make a PR on GitHub if it's accepted. I
think it's hard - at least for me - to test something from a gist. Then you
will get some reviews and more feedback.

Cheers,
Tom

On Fri, 4 Dec 2020 at 13:01, Maxim Milovanov  wrote:

> Hey guys,
>
> I've updated my prototype. What's changed:
> -- moved the JS and CSS to nav_sidebar.js and nav_sidebar.css respectively
> -- slight changes in styling
> -- added ESC key support
>
> I've updated my gist
> https://gist.github.com/MilovanovM/84ffbbec02391c1ba1771a3a6aee5797
> My changes are:
> nav_sidebar.html: line 4
> nav_sidebar.css: line 121 and below
> nav_sidebar.js: line 40 and below
>
> Here is the commit in my repo
> https://github.com/MilovanovM/django/commit/837701e79c468f72cbce1921b42c130801927e1c
> I've attached a git patch file as well.
>
> Thanks,
> Maxim
>
> пятница, 4 декабря 2020 г. в 12:00:35 UTC+3, Adam Johnson:
>
>> I'm not sure that the nav_sidebar.html is the best place for the JS
>>> snippet. Probably, it should be placed in the main JS. When DOM is ready it
>>> can be initialized there.
>>
>>
>> Indeed, we can't use inline JS in the admin since that doesn't work with
>> a strict CSP.
>>
>> On Fri, 4 Dec 2020 at 08:42, Maxim Milovanov  wrote:
>>
>>> Hey guys,
>>>
>>> I'm not sure that the nav_sidebar.html is the best place for the JS
>>> snippet. Probably, it should be placed in the main JS. When DOM is ready it
>>> can be initialized there.
>>>
>>> About UX. Agree the the "Clear" feature would be useful. It can be an
>>> "x" icon, or a shortkey (ESC?), or both.
>>>
>>> I'll provide a working sample later.
>>>
>>> Thanks,
>>> Maxim
>>>
>>> среда, 2 декабря 2020 г. в 20:46:30 UTC+3, Collin Anderson:
>>>
 I think this would be really helpful. Looking at the code in the gist,
 that looks about right. It's not too complicated and the basic
 toLowerCase()/indexOf() method of search should hopefully be enough (it's
 what I would do if I were implementing this!). I'd suggest adding some sort
 of clear or x button for canceling/removing the filter, but otherwise I
 think this should be ok UX wise. We can always improve it later.

 On Thursday, November 19, 2020 at 9:38:25 AM UTC-5 t...@carrick.eu
 wrote:

> I haven't looked at the gist, but I think in principle it's a good
> idea. ctrl+f isn't ideal.
>
> I think we need to be careful that the UX is good, if we go with this.
>
> Tom
>
> On Thu, 19 Nov 2020 at 15:16, Maxim Milovanov 
> wrote:
>
>> Yeah, that's why I came up with that idea. There are two projects, 44
>> models on one, 57 models on another. It's very hard to navigate
>>
>> четверг, 19 ноября 2020 г. в 16:50:37 UTC+3, yasie...@gmail.com:
>>
>>> I found this feature very helpful. I'm maintaining two sites with
>>> more than 20 models registered in the admin and some time is annoying 
>>> when
>>> I try to find the one I'm looking for
>>>
>>> El miércoles, 18 de noviembre de 2020 a la(s) 15:13:02 UTC-5, Maxim
>>> Milovanov escribió:
>>>
 Hey guys,

 I've posted a ticket  with
 a proposal to add a quick filtering feature to the sidebar.
 To see it in action just replace the content of nav_sidebar.html by 
 this
 gist
 

 Does it worth adding to the admin features? Hope for any feedback.

 Thanks,
 Maxim

>>> --
>> You received this message because you are subscribed to the Google
>> 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/8376528d-a2df-43b0-829e-43a49bd44dddn%40googlegroups.com
>> 
>> .
>>
> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-develop...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/577ba446-7e78-42d8-8a1d-88db169475d4n%40googlegroups.com
>>> 
>>> .
>>>
>>
>>
>> --
>> Adam
>>
> --
> You received this message because you are subscribed to th

Re: Quick Filter in the Admin Sidebar

[Tom Carrick]

I haven't looked at the gist, but I think in principle it's a good idea.
ctrl+f isn't ideal.

I think we need to be careful that the UX is good, if we go with this.

Tom

On Thu, 19 Nov 2020 at 15:16, Maxim Milovanov  wrote:

> Yeah, that's why I came up with that idea. There are two projects, 44
> models on one, 57 models on another. It's very hard to navigate
>
> четверг, 19 ноября 2020 г. в 16:50:37 UTC+3, yasie...@gmail.com:
>
>> I found this feature very helpful. I'm maintaining two sites with more
>> than 20 models registered in the admin and some time is annoying when I try
>> to find the one I'm looking for
>>
>> El miércoles, 18 de noviembre de 2020 a la(s) 15:13:02 UTC-5, Maxim
>> Milovanov escribió:
>>
>>> Hey guys,
>>>
>>> I've posted a ticket  with
>>> a proposal to add a quick filtering feature to the sidebar.
>>> To see it in action just replace the content of nav_sidebar.html by this
>>> gist
>>> 
>>>
>>> Does it worth adding to the admin features? Hope for any feedback.
>>>
>>> Thanks,
>>> Maxim
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/8376528d-a2df-43b0-829e-43a49bd44dddn%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/CAHoz%3DMaCHxNsukZXUZv9dOtsag9en6fZn0OdaFSMOvWknUkJ%2Bw%40mail.gmail.com.

Re: Custom collation support

[Tom Carrick]

 will slow down its review and affect its mid-term
>>> mergeability. Given it can be achieved using RunSQL operations only the
>>> Field.db_collation extension point is
>>>
>>> +1 to what Aymeric said regarding field alterations. Adding or removing
>>> a collation from a CharField/TextField should generate an AlterField
>>> operation that adds or remove the COLLATE clause from the column
>>> definition. Looks like you already implemented the schema editor bits of it
>>> but it should also be tested which will possibly involve writing some
>>> database introspection bit to assert the operation was correctly performed.
>>>
>>> > In MySQL (at least) columns also have a charset property that goes
>>> hand-in-hand with which collations are available. I know it expands the
>>> scope, but I think it would be good to get that in here. Perhaps it could
>>> be a follow-up ticket though.
>>>
>>> > The code here works across all backends, I'm not sure how it'd work
>>> for the charset. Would we add a new kwarg to Char/TextField just for MySQL?
>>> I think there are a few more questions to answer before tackling it, but I
>>> agree that if we add collations, we should add charsets for MySQL too, as
>>> they're so closely related.
>>>
>>> I guess it should be handled in a different ticket and discussed before
>>> hand. Not sure how common it is to want to define a per-column charset and
>>> since it would be already indirectly achievable by defining a collation
>>> (MySQL charset defaults to the charset of the collation when only the
>>> latter is specified, not sure about Oracle) it feels like the addition of a
>>> top level CharField/TextField option to allow specifying a charset that
>>> uses its default collation is not warranted.
>>>
>>> Simon
>>> Le dimanche 19 juillet 2020 à 09:57:58 UTC-4, t...@carrick.eu a écrit :
>>>
>>>> Thanks for the feedback.
>>>>
>>>> Aymeric, yes, I left out modification until I knew there was some
>>>> interest as that code seemed more impenetrable to me than the field
>>>> addition. I've added this now, does it seem like the right approach? I've
>>>> tested it on everything but Oracle and it seems to work as I'd expect. If
>>>> it generally looks good (and when/if the ticket
>>>> <https://code.djangoproject.com/ticket/31777> is accepted) I'll write
>>>> up tests and docs... I'm not sure how tests are going to work though. Since
>>>> the collation names are different I think I need to write some interesting
>>>> migrations that depend on the database vendor... do we do anything like
>>>> this anywhere else?
>>>>
>>>> Adam, I want to go with a followup ticket for these reasons:
>>>>
>>>> 1. I'm new to the schema migration code and I don't want to take on too
>>>> much at once.
>>>> 2. I haven't used MySQL in a long time so I'm not sure how to test it.
>>>> 3. The code here works across all backends, I'm not sure how it'd work
>>>> for the charset. Would we add a new kwarg to Char/TextField just for MySQL?
>>>> I think there are a few more questions to answer before tackling it, but I
>>>> agree that if we add collations, we should add charsets for MySQL too, as
>>>> they're so closely related.
>>>>
>>>> Tom
>>>>
>>>> On Sun, 19 Jul 2020 at 09:55, Adam Johnson  wrote:
>>>>
>>>>> Yes I'd also like to lend my support.
>>>>>
>>>>> In MySQL (at least) columns also have a charset property that goes
>>>>> hand-in-hand with which collations are available. I know it expands the
>>>>> scope, but I think it would be good to get that in here. Perhaps it could
>>>>> be a follow-up ticket though.
>>>>>
>>>>> On Sun, 19 Jul 2020 at 08:28, Aymeric Augustin <
>>>>> aymeric@polytechnique.org> wrote:
>>>>>
>>>>>> Hello Tom,
>>>>>>
>>>>>> Just wanted to give you some encouragement here, as you've been
>>>>>> monologuing for two months ;-) The PR looks promising!
>>>>>>
>>>>>> Regarding migrations, I'm not seeing how the collation for a column
>>>>>> will be set or unset in the database if you change it in the code e.

Re: Admin accessibility

[Tom Carrick]

Carlton, I think that would be useful, thanks.

Thibaud, shall I add you to the implementation team? It seems like you're
doing more work on this than I am lately. I think we could still use one or
perhaps two more people, but I think it's a good start.

On Mon, 14 Sep 2020 at 16:44, Carlton Gibson 
wrote:

> Hi All.
>
> Thanks for this. I'd be happy to play *Shepherd *if you need someone to
> put their hand up.
> I think that means I need to nag about getting it done. So... 🙂
>
> Who's going to be on the team to do the first review, and then subsequent
> work? Answer that and you have the Implementation Team.
> I like that you've thought about how the team can refresh periodically — I
> don't suppose the burden will be too great but folks tend to cycle-out
> naturally, so good to plan for that.
> Thibaud: Asking for hands in your talk seems sensible.
>
> Kind Regards,
>
> Carlton
>
>
>
> On Sunday, 6 September 2020 at 00:45:36 UTC+2 Thibaud Colas wrote:
>
>> Hi all,
>>
>> Now that the DEP PR has been submitted I was wondering what the next
>> steps would be. According to the documented DEP process I found, it’s at
>> the "forming the team"
>> 
>> stage? How do you go about creating an *Implementation Team* and finding
>> a *Shepherd*?
>>
>> The main reason I ask is that I’ll be giving a talk about accessibility
>> at DjangoCon EU in a couple of weeks, and I thought it would be a good
>> occasion to raise awareness of the issues with the Django admin, and
>> mention this DEP. But I want to make sure I provide accurate information.
>>
>> Thanks in advance,
>>
>> Thibaud
>>
>> On Tuesday, 14 July 2020 at 09:37:01 UTC+1 Thibaud Colas wrote:
>>
>>> 🎉 it’s wonderful to see this happening! Re-reading through the whole
>>> thing, as Tobias mentioned I also find it very easy to read, and makes a
>>> good case.
>>>
>>> On Tuesday, 14 July 2020 at 09:24:15 UTC+1 t...@carrick.eu wrote:
>>>
 I've added a PR to the DEPs repo to hopefully get some eyes on it:
 https://github.com/django/deps/pull/69

 Thibaud, I think whatever you have the time and motivation for sounds
 good, all of those things are useful. If you're not sure about all the
 admin features, I think that's pretty normal. One project I've had on my
 mind for a while now is to build a simple django site that is essentially
 just there to use every feature of the admin, so I might bump that up the
 priority list, though it's somewhat daunting.

 Cheers,
 Tom

 On Mon, 13 Jul 2020 at 01:15, Thibaud Colas 
 wrote:

> Update for the proof of concept CI tests from my side – thank you Tom
> for the feedback. Here are the latest additions to the test suite &
> reports, still living at
> https://thibaudcolas.github.io/django_admin_tests/,
>
> - Added as much as I know about in the admin, and now also outside of
> it a bit (startproject welcome page, error pages)
> - Separated the issues between Axe and HTML_CS so the numbers are
> easier to understand
> - Added anchor links everywhere for easier navigation
> - I’ve also started a draft list of "things to (potentially) audit",
> over at
> https://github.com/thibaudcolas/django_admin_tests#scope-for-future-audits
>
> I think the next two big steps are what you mention:
>
> - Having a way to track the number of issues over time. Currently the
> report overwrites itself every week (well, every build). If you have a
> suggestion on ways to demo this that would be useful please let me know.
> Currently I’m thinking sparklines for each test case could be nice as a
> proof of concept, and a sparkline for the total number of issues. Or see
> whether I should get out of my comfort zone a bit and find a
> dashboard/graphing tool to send the metrics to and graph there.
> - Testing more features of modeladmin. I don’t use it too frequently
> myself so don’t really know what’s “easy” to enable – if you know of an
> existing test suite I could repurpose, or of an example of using a lot of
> functionality – I’d be keen to invest time to add it to my test site.
>
> Alternatively something else I could do is to file a ticket for
> accessibility issues with the welcome page – I’ve tested it with screen
> readers, there are a few issues, but nothing that should be too hard to
> fix, and it might be a good demo of what reporting accessibility issues in
> general could look like?
>
> Cheers,
>
> Thibaud
>
>
> On Tuesday, 30 June 2020 at 18:59:53 UTC+1 Tobias Bengfort wrote:
>
>> Nice writeup! I found it easy to read (I did not catch myself
>> skipping
>> paragraphs which is always a good sign). Contentwise, I would have no
>> issue if this was accepted as is. Maybe I am forgetting about some
>> important de

Re: Bug report in Django docs

[Tom Carrick]

Hi,

This was removed between 3.0 and now. You can see it's no longer in the dev
docs:
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/javascript/

For the contributing docs, it's probably best to use the dev version rather
than from a release.

Tom

On Tue, 25 Aug 2020 at 19:46, Guo Zhang  wrote:

> There is an error in this documentation:
> https://docs.djangoproject.com/en/3.0/internals/contributing/writing-code/javascript/
>
> There is no "django/contrib/admin/bin/compress.py" in the project. It
> seems that the compress js section doesn't work as it shows.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/184366e6-0ea4-4856-8d77-b2c8f84498aan%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/CAHoz%3DMaLYjPtNDXcXeQJTbB4N_j18V%3Dx%3DF%2Bw3DNb5A86qQp%3D0w%40mail.gmail.com.

Re: Making max_length argument optional

[Tom Carrick]

It would work for my use-cases. It was mentioned that it's maybe not the
best as a lot of fields subclass CharField, but I don't see a compelling
argument for an unlimited email or slug field. The one problem I see is
CICharField, you might want to make that unlimited - but the CI fields are
more or less redundant on pg >= 12 once we have column collations in. So I
think it's okay for now. Only problem I can see is if we add more CharField
subclasses in the future...

On Mon, 17 Aug 2020 at 11:02, Carlton Gibson 
wrote:

> Would the subclass in contrib.postgres suggestion be acceptable?
>
> On Mon, 17 Aug 2020 at 10:31, Tom Carrick  wrote:
>
>> I'm not a fan of any solution either, really, even the one I suggested.
>>
>> I think adding a new kwarg, "unlimited" seems okay to me, though it feels
>> a little redundant.
>>
>> I don't like the idea of using TextField, I find them semantically
>> different. An unlimited varchar says to me "one possibly very long thing",
>> whereas TextField feels more like it's free text, or a document, especially
>> as the form fields are different. Subclassing CharField is an option, but
>> the methods I've seen to do this makes it annoying. I need this so often
>> that I do it all the time, but the code is so short that I don't want to
>> bring in a new package to do it. Also, the popular ways to do this are not
>> great. One way is to just set the max_length extremely high, which is not
>> what I want ending up in the database, the other is something like this
>> <https://github.com/jacobian/django-postgres-unlimited-varchar>, which
>> works well, but will stop working well once column collations are in as
>> that PR adds more stuff to CharField.__init__().
>>
>> I think it's time we had something in Django, whatever that ends up being.
>>
>> On Sun, 16 Aug 2020 at 20:28, Carlton Gibson 
>> wrote:
>>
>>> Reading the history, I see an awful lot of -1s to the idea of a default.
>>>
>>> I see “use a TextField” and “use a subclass” a few times, which were my
>>> immediate thoughts just on the recent emails.
>>>
>>> On Sun, 16 Aug 2020 at 18:47, Tom Forbes  wrote:
>>>
>>>> I’m not a fan of implicit max_lengths. Is having to add a keyword
>>>> argument to a model field really that much of a burden? And we also would
>>>> likely never be able to change the default without headaches.
>>>>
>>>> On 12 Aug 2020, at 13:19, t...@carrick.eu  wrote:
>>>>
>>>> I'd like to revive this discussion and try to come to a consensus as
>>>> it's something I find myself wishing for (for Postgres in particular).
>>>>
>>>> My suggestion, after reading through everything:
>>>>
>>>> Give CharField a default max_length that is consistent across all
>>>> vendors. It doesn't really matter what the number is other than that it
>>>> should be large enough to be useful but small enough to work everywhere. I
>>>> think 100 or 255 are both fine options.
>>>>
>>>> If you set max_length=None explicitly, on Postgres this will use an
>>>> unlimited varchar, on everything else will raise an exception on migrate.
>>>>
>>>> Any thoughts?
>>>>
>>>> Cheers,
>>>> Tom
>>>>
>>>> On Saturday, March 5, 2016 at 2:13:14 PM UTC+1 Shai Berger wrote:
>>>>
>>>>> On Saturday 05 March 2016 02:24:17 Loïc Bistuer wrote:
>>>>>
>>>>>
>>>>> > I’m not too keen on a contrib.pg field. CharField is the base class
>>>>> of many
>>>>>
>>>>>
>>>>> > fields, a __init__ kwarg approach such as max_length=None allows us
>>>>> to
>>>>>
>>>>>
>>>>> > reach those as well.
>>>>>
>>>>>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> That's a good point; Can we enable max_length=None in a mixin?
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Django developers (Contributions to Django itself)" group.
>>>>
>>>>
>>&

Re: Making max_length argument optional

[Tom Carrick]

I'm not a fan of any solution either, really, even the one I suggested.

I think adding a new kwarg, "unlimited" seems okay to me, though it feels a
little redundant.

I don't like the idea of using TextField, I find them semantically
different. An unlimited varchar says to me "one possibly very long thing",
whereas TextField feels more like it's free text, or a document, especially
as the form fields are different. Subclassing CharField is an option, but
the methods I've seen to do this makes it annoying. I need this so often
that I do it all the time, but the code is so short that I don't want to
bring in a new package to do it. Also, the popular ways to do this are not
great. One way is to just set the max_length extremely high, which is not
what I want ending up in the database, the other is something like this
, which
works well, but will stop working well once column collations are in as
that PR adds more stuff to CharField.__init__().

I think it's time we had something in Django, whatever that ends up being.

On Sun, 16 Aug 2020 at 20:28, Carlton Gibson 
wrote:

> Reading the history, I see an awful lot of -1s to the idea of a default.
>
> I see “use a TextField” and “use a subclass” a few times, which were my
> immediate thoughts just on the recent emails.
>
> On Sun, 16 Aug 2020 at 18:47, Tom Forbes  wrote:
>
>> I’m not a fan of implicit max_lengths. Is having to add a keyword
>> argument to a model field really that much of a burden? And we also would
>> likely never be able to change the default without headaches.
>>
>> On 12 Aug 2020, at 13:19, t...@carrick.eu  wrote:
>>
>> I'd like to revive this discussion and try to come to a consensus as it's
>> something I find myself wishing for (for Postgres in particular).
>>
>> My suggestion, after reading through everything:
>>
>> Give CharField a default max_length that is consistent across all
>> vendors. It doesn't really matter what the number is other than that it
>> should be large enough to be useful but small enough to work everywhere. I
>> think 100 or 255 are both fine options.
>>
>> If you set max_length=None explicitly, on Postgres this will use an
>> unlimited varchar, on everything else will raise an exception on migrate.
>>
>> Any thoughts?
>>
>> Cheers,
>> Tom
>>
>> On Saturday, March 5, 2016 at 2:13:14 PM UTC+1 Shai Berger wrote:
>>
>>> On Saturday 05 March 2016 02:24:17 Loïc Bistuer wrote:
>>>
>>>
>>> > I’m not too keen on a contrib.pg field. CharField is the base class
>>> of many
>>>
>>>
>>> > fields, a __init__ kwarg approach such as max_length=None allows us to
>>>
>>>
>>> > reach those as well.
>>>
>>>
>>> >
>>>
>>>
>>>
>>>
>>>
>>> That's a good point; Can we enable max_length=None in a mixin?
>>>
>>>
>>>
>>
>>
>>
>>
>> --
>>
>>
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>>
>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>>
>>
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/dfaaa9d3-dff3-46a3-899f-dd7f4eddfe87n%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/468B12C0-2864-4221-9985-044F340E56E1%40tomforb.es
>> 
>> .
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJwKpyScwiRJWWebwjQZ4qoQz6_zuWZP9Q_RAs8bxzV0eRMoqQ%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.goo

Re: Suggestion: "django-admin startproject" should not put secrets in settings.py

[Tom Carrick]

Hi Roy,

There's also a more recent thread on this:
https://groups.google.com/u/2/g/django-developers/c/CIPgeTetYpk

Tom

On Sun, 26 Jul 2020 at 18:00, Roy Smith  wrote:

> In the past, I've worked on a couple of django projects where we violated
> the:
>
> # SECURITY WARNING: keep the secret key used in production secret!"
>
>
> advice because on day one, somebody didn't know what we they were doing
> and never fixed it.  Looking around at a collection of django projects (by
> various developers), I see that's often the case.  SECRET_KEY, oauth keys,
> aws keys, etc all end up in settings.py files.  And show up in github, etc.
>
> This is not terribly surprising.  I expect most people just sit down with the
> tutorial
> ,
> follow the first example:
>
> $ django-admin startproject mysite
>
>
> and instantly have a working, but insecure, setup.
>
> So, why not have startproject start people off on the right foot?  Build a
> settings.py file and a secret_settings.py file.  Put the SECRET_KEY in
> secrets.py.  Have settings.py do "from secret_settings import SECRET_KEY".
> Make secret_settings.py mode 0400 by default (or whatever that translates
> to on windows).  Print out a message telling people to exclude
> secret_settings.py from version control.
>
>
> As people add more secrets, they have a low-effort path to continuing to
> do something reasonable.  A more sophisticated user can tear that out and
> replace it with their own secrets infrastructure.  But, at least we will
> have started newbies off with something reasonable.
>
> I see this has been discussed before
> ,
> but I disagree with a lot of the opinions in that thread.  This wouldn't be
> forcing developers to do it any specific way.  It just provides a default
> that's better than the current default.  Expecting that newbies to follow
> best practices just because they're documented somewhere is irrational, as
> can be seen by perusing github.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/E7AED784-145B-45A5-9C23-8700E72E5CB8%40panix.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/CAHoz%3DMaEHnGimaV6zcvuTU9fTytbr1D4ixJOVLzFJnBtzpFpfw%40mail.gmail.com.

Re: f-strings again.

[Tom Carrick]

I'm also +1, I find f-strings easier to read in most cases. You can go
overboard -  and I probably do - but I don't think the guard against
unreadable f-strings is to ban them outright.

One small negative to % formatting for me is that I sometimes get confused
for a second about whether something is interpolated in the code or if
they're placeholders for sql params or logging calls. But I don't see a
reason to change any of the current ones because of that.

Cheers,
Tom

On Tue, 21 Jul 2020 at 10:55, Dave Vernon 
wrote:

> +1, I'd happily help on any PR with this (it would be my first!).
>
> Kind Regards,
>
> Dave
>
> Springbourne Tech Limited
> M: +44(0) 79 2107 6483
> W: www.springbourne-tech.com
>
>
>
>
>
> *—This E-Mail and its contents are confidential, protected by law
> and legally privileged.  Only access by the addressee is authorised.  Any
> liability (in negligence, contract or otherwise) arising from any third
> party taking any action or refraining from taking any action on the basis
> of any of the information contained in this E-Mail is hereby excluded to
> the fullest extent of the law.  In the event that you are not the
> addressee, please notify the sender immediately.  Do not discuss, disclose
> the contents to any person or store or copy the information in any medium
> or use it for any purpose whatsoever.*
>
>
>
>
> On Tue, 21 Jul 2020 at 09:43, Nick Pope  wrote:
>
>> Hi,
>>
>> So I'm in favour of using f-strings, but agree that there are places
>> where they are not appropriate.
>>
>> I am also against bulk updates in this case as mentioned in my previous
>> comment
>> . I
>> don't think we should exclude replacing .format() with f-strings on a
>> case-by-case basis, however, where performance is a concern.
>>
>> Thanks for your initial documentation, Carlton. Am wondering whether we
>> should be more explicit about the pros and cons of each to help people make
>> the correct decision? Here are my thoughts:
>>
>> %-formatting:
>>
>> + Simple to use printf-style familiar to all.
>> + Default (can be changed
>> )
>> style used internally by the logging module, e.g. logging.info('Message
>> with %s.', value)
>> − Much less flexibility for formatting, see pyformat.info.
>>
>> ``.format()``:
>>
>> + Useful for interpolating a stored template string, e.g. from a
>> database, which isn't possible with f-strings.
>> − Worst performance due to method call.
>> − Much more verbose, makes code less readable.
>>
>> f-strings:
>>
>> + Better performance than other methods due to dedicated FORMAT_VALUE
>>  opcode.
>> + Allows for embedding more complex expressions, e.g. f'Hello
>> {user.get_full_name()}'
>> + Much more concise, makes code more readable.
>> − Cannot be used if string must be translated.
>> − Complex expressions can get out of control. A sensible balance needs to
>> be struck.
>>
>> Regarding performance, here are some simple numbers:
>>
>> python -m timeit -s 'x="test"' 'f"{x}"'
>> 2000 loops, best of 5: 11.8 nsec per loop
>> $ python -m timeit -s 'x="test"' '"%s" % x'
>> 1000 loops, best of 5: 39.1 nsec per loop
>> $ python -m timeit -s 'x="test"' '"{}".format(x)'
>> 500 loops, best of 5: 76.1 nsec per loop
>>
>> I think it is probably also worth updating the documentation added in this
>> commit
>> .
>> It isn't that xgettext doesn't support f-strings... It does:
>>
>> $ echo "_('Hello %s') % user.username" | xgettext --language=python
>> --omit-header --output=- -
>> #: standard input:1
>> #, python-format
>> msgid "Hello %s"
>> msgstr ""
>> $ echo "_('Hello {}').format(user.username)" | xgettext --language=python
>> --omit-header --output=- -
>> #: standard input:1
>> msgid "Hello {}"
>> msgstr ""
>> $ echo "_('Hello {name}').format(name=user.username)" | xgettext
>> --language=python --omit-header --output=- -
>> #: standard input:1
>> #, python-brace-format
>> msgid "Hello {name}"
>> msgstr ""
>> $ echo "_(f'Hello {user.username}')" | xgettext --language=python
>> --omit-header --output=- -
>> #: standard input:1
>> #, python-brace-format
>> msgid "Hello {user.username}"
>> msgstr ""
>> $ echo "_(f'Hello {user.get_full_name()}')" | xgettext --language=python
>> --omit-header --output=- -
>> #: standard input:1
>> msgid "Hello {user.get_full_name()}"
>> msgstr ""
>>
>> It is actually that Python doesn't support modifying the template string
>> prior to interpolating the values which is the requirement for injecting
>> the translated string. PEP 498
>>  makes no explicit mention of
>> this. PEP 501  was initially
>> looking at solving the problem but was deemed a poor fit and was also
>> deferred.
>>
>> Kind regards,
>>
>> Nick

Re: Custom collation support

[Tom Carrick]

Thanks for the feedback.

Aymeric, yes, I left out modification until I knew there was some interest
as that code seemed more impenetrable to me than the field addition. I've
added this now, does it seem like the right approach? I've tested it on
everything but Oracle and it seems to work as I'd expect. If it generally
looks good (and when/if the ticket
<https://code.djangoproject.com/ticket/31777> is accepted) I'll write up
tests and docs... I'm not sure how tests are going to work though. Since
the collation names are different I think I need to write some interesting
migrations that depend on the database vendor... do we do anything like
this anywhere else?

Adam, I want to go with a followup ticket for these reasons:

1. I'm new to the schema migration code and I don't want to take on too
much at once.
2. I haven't used MySQL in a long time so I'm not sure how to test it.
3. The code here works across all backends, I'm not sure how it'd work for
the charset. Would we add a new kwarg to Char/TextField just for MySQL? I
think there are a few more questions to answer before tackling it, but I
agree that if we add collations, we should add charsets for MySQL too, as
they're so closely related.

Tom

On Sun, 19 Jul 2020 at 09:55, Adam Johnson  wrote:

> Yes I'd also like to lend my support.
>
> In MySQL (at least) columns also have a charset property that goes
> hand-in-hand with which collations are available. I know it expands the
> scope, but I think it would be good to get that in here. Perhaps it could
> be a follow-up ticket though.
>
> On Sun, 19 Jul 2020 at 08:28, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Hello Tom,
>>
>> Just wanted to give you some encouragement here, as you've been
>> monologuing for two months ;-) The PR looks promising!
>>
>> Regarding migrations, I'm not seeing how the collation for a column will
>> be set or unset in the database if you change it in the code e.g.:
>>
>> MySQL : ALTER TABLE ... MODIFY ... VARCHAR(...) COLLATE ...
>> PostgreSQL : ALTER TABLE ... ALTER COLUMN ... TYPE varchar(...) COLLATE
>> ...
>>
>> I think this needs to be in scope, else it will be hard for maintainers
>> of existing projects to take advantage of this new feature.
>>
>> --
>> Aymeric.
>>
>>
>>
>> On 18 Jul 2020, at 13:29, Tom Carrick  wrote:
>>
>> I've written a proof of concept:
>> https://github.com/django/django/pull/13207
>>
>> The diff is quite small, though I'm not sure if there's something I'm
>> doing wrong - this is my first foray into schema migration internals so I'm
>> learning as I read the codebase.
>>
>> Tom
>>
>> On Fri, 17 Jul 2020 at 13:55, Tom Carrick  wrote:
>>
>>> I've had a deeper look at this now and think I have an API proposal.
>>> First, the state of supported vendors:
>>>
>>> 1. All vendors support adding a collation to text/varchar fields.
>>> 2. The syntax is more or less the same.
>>> 3. However, the collation names themselves are different.
>>> 4. PostgreSQL is the only vendor that allows creating custom collations
>>> at runtime.
>>>
>>> So I'm thinking we add a new `collation` parameter to `CharField` and
>>> `TextField`, that simply takes a string of the collation ID. I'm not quite
>>> sure on the implementation as I don't know the ORM that well, but my naive
>>> approach would be to just add a new format string to the `data_types` dict
>>> that is calculated during the field __init__(), either an empty string to
>>> use the default collation, or e.g. ' collate '. There's may
>>> well be a better approach.
>>>
>>> By using this - because the collation names are not the same across
>>> vendors - the user is saying "I'm okay with this only working on one
>>> database vendor", so there should be a warning in the docs. There is
>>> perhaps some scope in the future to make this take a callable that can
>>> figure out the collation per-database. This would be useful for getting
>>> case-insensitive lookups working across all backends, for example. But I
>>> want to keep that out of the scope because it's some extra work and I'm not
>>> sure on the implementation.
>>>
>>> Another downside is that people like to use CharField as a base class
>>> for other column types that might not support collations, but I think this
>>> should be in the user's hands to make sure they aren't do

Re: Custom collation support

[Tom Carrick]

I've written a proof of concept: https://github.com/django/django/pull/13207

The diff is quite small, though I'm not sure if there's something I'm doing
wrong - this is my first foray into schema migration internals so I'm
learning as I read the codebase.

Tom

On Fri, 17 Jul 2020 at 13:55, Tom Carrick  wrote:

> I've had a deeper look at this now and think I have an API proposal.
> First, the state of supported vendors:
>
> 1. All vendors support adding a collation to text/varchar fields.
> 2. The syntax is more or less the same.
> 3. However, the collation names themselves are different.
> 4. PostgreSQL is the only vendor that allows creating custom collations at
> runtime.
>
> So I'm thinking we add a new `collation` parameter to `CharField` and
> `TextField`, that simply takes a string of the collation ID. I'm not quite
> sure on the implementation as I don't know the ORM that well, but my naive
> approach would be to just add a new format string to the `data_types` dict
> that is calculated during the field __init__(), either an empty string to
> use the default collation, or e.g. ' collate '. There's may
> well be a better approach.
>
> By using this - because the collation names are not the same across
> vendors - the user is saying "I'm okay with this only working on one
> database vendor", so there should be a warning in the docs. There is
> perhaps some scope in the future to make this take a callable that can
> figure out the collation per-database. This would be useful for getting
> case-insensitive lookups working across all backends, for example. But I
> want to keep that out of the scope because it's some extra work and I'm not
> sure on the implementation.
>
> Another downside is that people like to use CharField as a base class for
> other column types that might not support collations, but I think this
> should be in the user's hands to make sure they aren't doing that.
>
> We should also add a `CreateCollation` operation for Postgres, similar to
> the `CreateExtension` operation that currently exists. If the user wants to
> use a custom collation they must create it first, similar to using
> extensions currently.
>
> The advantage to this is that users can use collations without having to
> make SQL migrations, which I think would be nice. The really nice thing is
> the ability to have case-insensitive lookups that work across all database
> vendors, rather than only Postgres as it currently is. And as I mentioned
> in the previous message, Postgres is discouraging our current method of
> using the citext extension in favour of this approach.
>
> Cheers,
> Tom
>
> On Wed, 27 May 2020 at 14:17, Tom Carrick  wrote:
>
>> I think it would be useful to be able to create collations and use them
>> with model fields. The motivation here is mostly that citext is somewhat
>> discouraged <https://www.postgresql.org/docs/12/citext.html> in favour
>> of creating a collation. I'm not sure how this would work on other
>> databases,or what the API would look like. I didn't see a ticket for it or
>> another discussion, but maybe there is one.
>>
>> Perhaps a Collation class would make sense, and it could be added to a
>> Field with a new parameter. I'm not sure how easy it would be to only
>> create a collation once, so perhaps it would need a CreateCollation
>> migration as well, but I know very little about the internals of migrations.
>>
>> Cheers,
>> Tom
>>
>

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

Re: Custom collation support

[Tom Carrick]

I've had a deeper look at this now and think I have an API proposal. First,
the state of supported vendors:

1. All vendors support adding a collation to text/varchar fields.
2. The syntax is more or less the same.
3. However, the collation names themselves are different.
4. PostgreSQL is the only vendor that allows creating custom collations at
runtime.

So I'm thinking we add a new `collation` parameter to `CharField` and
`TextField`, that simply takes a string of the collation ID. I'm not quite
sure on the implementation as I don't know the ORM that well, but my naive
approach would be to just add a new format string to the `data_types` dict
that is calculated during the field __init__(), either an empty string to
use the default collation, or e.g. ' collate '. There's may
well be a better approach.

By using this - because the collation names are not the same across vendors
- the user is saying "I'm okay with this only working on one database
vendor", so there should be a warning in the docs. There is perhaps some
scope in the future to make this take a callable that can figure out the
collation per-database. This would be useful for getting case-insensitive
lookups working across all backends, for example. But I want to keep that
out of the scope because it's some extra work and I'm not sure on the
implementation.

Another downside is that people like to use CharField as a base class for
other column types that might not support collations, but I think this
should be in the user's hands to make sure they aren't doing that.

We should also add a `CreateCollation` operation for Postgres, similar to
the `CreateExtension` operation that currently exists. If the user wants to
use a custom collation they must create it first, similar to using
extensions currently.

The advantage to this is that users can use collations without having to
make SQL migrations, which I think would be nice. The really nice thing is
the ability to have case-insensitive lookups that work across all database
vendors, rather than only Postgres as it currently is. And as I mentioned
in the previous message, Postgres is discouraging our current method of
using the citext extension in favour of this approach.

Cheers,
Tom

On Wed, 27 May 2020 at 14:17, Tom Carrick  wrote:

> I think it would be useful to be able to create collations and use them
> with model fields. The motivation here is mostly that citext is somewhat
> discouraged <https://www.postgresql.org/docs/12/citext.html> in favour of
> creating a collation. I'm not sure how this would work on other
> databases,or what the API would look like. I didn't see a ticket for it or
> another discussion, but maybe there is one.
>
> Perhaps a Collation class would make sense, and it could be added to a
> Field with a new parameter. I'm not sure how easy it would be to only
> create a collation once, so perhaps it would need a CreateCollation
> migration as well, but I know very little about the internals of migrations.
>
> Cheers,
> Tom
>

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

Re: HttpResponse headers interface

[Tom Carrick]

Ah, I think I just misread your earlier mail then.

Sorry about the confusion!

Tom

On Thu, 16 Jul 2020 at 20:44, Carlton Gibson 
wrote:

> Hey Tom,
>
> The movement of the discussion was (or at least seemed to be, prompting
> concern) to eventually deprecate and remove, even if on a longer time
> scale. It’s that that raised the red flags I think.
>
> Folks have been stung before: a new feature is introduced with a “May be
> deprecated in future”, rhetorically implying “don’t worry, it won’t really
> be deprecated”, but then inevitably it is, and then there’s the breaking
> change.
>
> (That we didn’t remove the feature immediately doesn’t change the
> situation for the end user — I think James made a similar point in the
> discussion around url() about NOT doing extended deprecations: it just
> delays the pain, it we can’t accept it straight out, maybe the change
> wasn’t so harmless.)
>
> Currently the patch says "Both interfaces will continue to be supported.”
> As long as that’s not changed to any version of "May be deprecated in
> future”[*] then super, nice, I like it.
>
> > As long as we agree to not deprecate it, which I thought we had…
>
> My email this afternoon was prompted by the concern that this wasn’t
> agreed, and the consequences of that.
>
> I hope all that make sense: I feel like I’m saying the same things again —
> perhaps I’m not being clear.
>
> I like the feature; as far as I am aware no-one has said they don’t; if
> we’re not going to break the existing interface then concerns are allayed I
> think.
>
> Kind Regards,
>
> Carlton
>
>
> [*] See previous points about, “let’s talk about it when Django is 30”
>
> On 16 Jul 2020, at 19:12, Tom Carrick  wrote:
>
> But the proposed patch doesn't break any existing code, does it? As far as
> I can tell, the old interface works the same as it always did. As long as
> we agree to not deprecate it, which I thought we had, then nothing is
> breaking. Changing code in other places was at Adam's suggestion, but it's
> unnecessary, it can be removed without consequence.
>
> Perhaps I'm missing something?
>
> Tom
>
> On Thu, 16 Jul 2020 at 18:48, Carlton Gibson 
> wrote:
>
>> Hey Nick.
>>
>> On 16 Jul 2020, at 17:41, Nick Pope  wrote:
>>
>> I honestly thought the approach Carlton mentioned in
>> https://github.com/django/django/pull/13186#discussion_r454956921 struck
>> the correct balance and we could even, if desired, highlight in the release
>> notes for the new `response.headers` that the old approach has not gone
>> away such that developers do not need to rush to update their code. As
>> highlighted by the examples above, it feels like there is precedent for
>> that. Also if the data model approach is plumbed in to use `.headers` as in
>> the proposed implementation, I don't see this as being a burden to maintain.
>>
>> Please let's be pragmatic about this stuff and not be driven to adhering
>> to "one way to do it" as an extremist ideology rather than a laudable
>> preference.
>>
>>
>> This was exactly my thought. Add the new .headers feature — I don’t think
>> there’s anyone saying it isn’t nicer in isolation — but leave the existing
>> interface alone.
>>
>> But the concern was expressed to me that deprecation and eventual removal
>> of the original way of doing it (under any timescale, as we saw just
>> recently with `url`) involves updating every line of Django that ever set
>> response header. It’s THAT burden that’s at issue. It would be too much: at
>> that point the new niceness of .headers doesn’t justify the expense.[*]
>>
>> If we can add .headers without the breaking change (under any timescale —
>> I joked with Adam that Django is 15, so perhaps we could discuss it when
>> it’s 30…) then I’m all for it. I agree the implementation of `__setitem__`
>> &co doesn’t add a maintenance burden.
>>
>> Not breaking existing code is our biggest selling point.
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>>
>> [*] Hopefully that’s not extremist…—unless cost-benefit analysis is
>> extremist these days, which it could be 😀
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/ED88B9B4-D47

Re: HttpResponse headers interface

[Tom Carrick]

But the proposed patch doesn't break any existing code, does it? As far as
I can tell, the old interface works the same as it always did. As long as
we agree to not deprecate it, which I thought we had, then nothing is
breaking. Changing code in other places was at Adam's suggestion, but it's
unnecessary, it can be removed without consequence.

Perhaps I'm missing something?

Tom

On Thu, 16 Jul 2020 at 18:48, Carlton Gibson 
wrote:

> Hey Nick.
>
> On 16 Jul 2020, at 17:41, Nick Pope  wrote:
>
> I honestly thought the approach Carlton mentioned in
> https://github.com/django/django/pull/13186#discussion_r454956921 struck
> the correct balance and we could even, if desired, highlight in the release
> notes for the new `response.headers` that the old approach has not gone
> away such that developers do not need to rush to update their code. As
> highlighted by the examples above, it feels like there is precedent for
> that. Also if the data model approach is plumbed in to use `.headers` as in
> the proposed implementation, I don't see this as being a burden to maintain.
>
> Please let's be pragmatic about this stuff and not be driven to adhering
> to "one way to do it" as an extremist ideology rather than a laudable
> preference.
>
>
> This was exactly my thought. Add the new .headers feature — I don’t think
> there’s anyone saying it isn’t nicer in isolation — but leave the existing
> interface alone.
>
> But the concern was expressed to me that deprecation and eventual removal
> of the original way of doing it (under any timescale, as we saw just
> recently with `url`) involves updating every line of Django that ever set
> response header. It’s THAT burden that’s at issue. It would be too much: at
> that point the new niceness of .headers doesn’t justify the expense.[*]
>
> If we can add .headers without the breaking change (under any timescale —
> I joked with Adam that Django is 15, so perhaps we could discuss it when
> it’s 30…) then I’m all for it. I agree the implementation of `__setitem__`
> &co doesn’t add a maintenance burden.
>
> Not breaking existing code is our biggest selling point.
>
> Kind Regards,
>
> Carlton
>
>
>
> [*] Hopefully that’s not extremist…—unless cost-benefit analysis is
> extremist these days, which it could be 😀
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ED88B9B4-D474-4562-BFDB-4362B7168E56%40gmail.com
> 
> .
>

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

Re: HttpResponse headers interface

[Tom Carrick]

Hmm. I do think that Python's data model is a Good Thing. Where we might
disagree is that I don't think this is an appropriate use of it.I'll try to
illustrate with an example. Consider this code:

response = HttpResponse()
response['foo'] = 'bar'

Now, if I try to look at this code without context, putting my Django
knowledge to the back of my head, intuitively, this doesn't look like I'm
setting a header. To me it actually looks more like my response is JSON
(increasingly common these days) and I'm setting the 'foo' key on it to
'bar'. Now, is this likely to happen and cause confusion? Probably not,
since we tend to spell out our headers such as Content-Type rather than
content-type, and custom headers tend to be prefixed with 'X-'. But I do
think there is potential confusion, especially to beginners or perhaps
people who know a little frontend development and expect any request to
return JSON, and perhaps haven't had to interact with headers as their
libraries take care of them.

However, the reason I bring this up isn't so much this potential for
confusion, but more this: When I think about a HTTP request, 99% of the
time, I'm thinking about the response content. Only rarely am I ever
thinking about the headers. Usually interacting with headers is abstracted
away in middleware or some other place. So why should setting a key on the
response set something on the headers? It seems unintuitive to me.

Personally, I think that is enough to meet the bar of "clearly superior",
but I'm aware I don't have the only opinion.

Another thing this is useful for is that it's actually possible (in a
documented, public way) to see all the response headers. Of course the
server could modify this, but it's still useful when debugging to see what
Django is setting, and right now the only way I can think to do this is to
look at `response._headers`, and I'd rather not be using undocumented APIs.

If the concern is primarily about the diff size, it's quite trivial (if we
decide to keep the existing API as-is forever and just add the new
interface on top) to drop the commits changing those and just add tests for
the new interface. It is then purely additive in the sense that the old API
works just the same and isn't going anywhere.

Regardless, I'm happy to go wherever the consensus is.

Cheers,
Tom

On Thu, 16 Jul 2020 at 14:25, Carlton Gibson 
wrote:

> Some concerns were expressed privately to me privately in the week about
> the change here.
>
> I was thinking about it, and re-reading the API Stability document
> https://docs.djangoproject.com/en/3.0/misc/api-stability/.
>
> The more I look at it, the less convinced I am that the proposal here
> meets the "when we discover clearly superior ways to do things" criterion.
>
> Yes, I think, if we were starting from scratch, we'd probably put headers
> in a mapping attached to the response, so the request.headers here
> proposed.
>
> I think that probably is (definitely is?) easier for a beginner to grok.
> But looking at the diff — where all the changes are just from:
>
> response['Content-Disposition'] = 'attachment; filename="somefilename.csv"'
>
> to:
>
> response.headers['Content-Disposition'] = 'attachment;
> filename="somefilename.csv"'
>
> I can't see that this is clearly superior, to just having the response
> itself act as said mapping.
>
> I learnt Python through Django. This exact case was my first expose to the
> Python Data Model. Oh, objects can act like dictionaries. Cool.
> Didn't think about it again for half a dozen years. But it wasn't so
> difficult.
>
> The s/response/response.headers/g (from one POV) just looks like more
> code, despite the initial "Yeah, sounds good."
>
> Then I come to the “one way to do it. OK, I get that.
>
> But I look at the prospect of forcing every project that ever set an HTTP
> header to have to update. I look again at the "clearly superior", and I
> have to conclude that the change isn't justfied.
> That's too bigger cost for too small a gain.
>
> So, despite earlier enthusiasm, I have to lean towards a -1 here.
> Like request.headers, I initially took this as a purely additive gain, but
> that's not compatible with the goals expressed in the API Stability policy.
> So I think we should pass.
> Not easy.
>
>
>
> Django is in a good place: we're at the point where it's easy to update,
> and that's the expectation. The API Stability policy (and it's
> enforcement) is largely responsible for that.
> It's important not to forget. We on this list see a *little* change as a
> nothing. Across the massive install base it's anything but.
> David's mention of url() is  a good one — for each complaint we see here,
> and we saw a few, there will be a thousand we don't — people just do the
> work, but that's not something we should impose lightly.
>
>
>
> The are a couple of good additions to take:
>
> * Setting headers via an init kwarg would be cool.
> * Maybe the CaseInsenstiveMapping is worth using too. (Not so sure what
> the benefi

Re: HttpResponse headers interface

[Tom Carrick]

I guess there is still some debate on how to handle the old interface. I'll
give my opinion, but I want to make it clear I don't mind that much what we
do with it.

When I've seen people learning Django, they come across these magical
strings you somehow add to the response, but aren't content, that does
magical things like make the content download rather than show in the
browser. To people who don't yet understand HTTP, this feels very... well,
magical.

This new interface has the advantage of being extremely clear what's
happening to people who are less familiar with HTTP than we are. It's
setting a header, it's right there in the name. I also feel it's much more
explicit.

I would prefer "one right way to do it", but I also don't see a compelling
reason to deprecate the old interface. It's been there forever, a huge
amount of code uses it, and I don't see a problem with leaving it there.
The way it's implemented is just interacting with the new headers anyway,
so it should be trivial to keep them in sync. Adam has suggested in the PR
to note that it "may" be deprecated in the future. Even if we don't
actually plan to do this, I like it. It's sneaky, we get people to
hopefully migrate to the newer interface but don't break people's code, at
least for a good long time.

To summarise, I'm:

+1 for the new interface.
+1 for keeping the old interface.
-0 for documenting the old interface as an alternative.

On Wed, 15 Jul 2020 at 11:43, Javier Buzzi  wrote:

> @Tom looks great, should we add depreciation notices to the
> response.__gettitem__/del that way there are no 2 right ways to do things?
> I would probably keep it around until 3.2... I personally like the whole
> respose.headers it's much more readable.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/86889efe-b876-46cc-8dc4-1559d6a6487do%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/CAHoz%3DMa7VDDSVj-5e1yF0RrCr0WKxujpN2-LwQc3NQNNT92V%3DQ%40mail.gmail.com.

Re: HttpResponse headers interface

[Tom Carrick]

I think the PR has everything now and is ready for review:
https://github.com/django/django/pull/13186

On Wed, 15 Jul 2020 at 08:38, Carlton Gibson 
wrote:

> Just to be clear:
>
> > I think we should keep the old interface.
>
> I mean as well as adding the new .headers property. (So +1)
> (Sorry if that was already clear.)
>
> On Tuesday, 14 July 2020 16:41:43 UTC+2, Carlton Gibson wrote:
>>
>> I think we should keep the old interface.
>>
>> The BC concerns are one point: it's every bit of Django code ever
>> written. To keep __setitem__ &co is a small price to pay not to needlessly
>> break that code.
>>
>> Beyond that though, the proposed API is very nice, but the pendulum will
>> swing back: having response objects conform to the Python Data Model, by
>> looking like dicts, will again come to seem desirable. In
>> the meantime it'll be merely be handy that you can so use them> humour> — The number of times, "I can just..." will pay off here (IMO)
>> tells further against removing those special methods.
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Tuesday, 14 July 2020 16:07:15 UTC+2, Jon Dufresne wrote:
>>>
>>> > I don't see a reason to deprecate it at all just now (though perhaps
>>> in _my_ ideal world that would happen at some point), but I'm not sure if
>>> it's worth keeping the current interface in the documentation at all?
>>>
>>> IMHO, we should eventually take the advice from the zen of Python "There
>>> should be one-- and preferably only one --obvious way to do it.". While we
>>> should not take this as dogma, I do think it is generally wise.
>>>
>>> If there are increased concerns about existing projects, perhaps we
>>> could delay the initial deprecation or apply some kind of extended
>>> deprecation period that would allow projects more time to migrate. Removing
>>> the old interface from the docs is a great first step.
>>>
>>> But ultimately, I think having two interfaces to solve the same tasks
>>> confuses new library users and makes project coding styles more difficult
>>> than necessary.
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9a37d067-381f-46ab-bfc9-543d59a61c31o%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/CAHoz%3DMYLD6UAeu0CKkNMVwJpymvSKkMQUKzGpoKGAbcrNyZusw%40mail.gmail.com.

Re: HttpResponse headers interface

[Tom Carrick]

I've pushed a proof of concept here:
https://github.com/django/django/pull/13186

I decided to do a bit more than I initially intended. It seems like the
headers can be stored as a public interface and single source of truth now,
rather than just adding an extra public property based on it, by using a
slightly modified CaseInsensitiveMapping.

Perhaps I'm missing some reason - and if there is one, let me know - that
this shouldn't be a public, documented interface, but I'm not sure what
that is.

If this all seems good, I'll write up docs and tests (all current tests
seem to be passing). I'm wondering though, if we should prefer this
interface over the old one, as it's a bit more explicit in my view. I'd be
happy to go through the docs and change the examples to using the headers
attribute directly. I don't see a reason to deprecate it at all just now
(though perhaps in _my_ ideal world that would happen at some point), but
I'm not sure if it's worth keeping the current interface in the
documentation at all?

One further small addition, I think it would be good to be able to pass
headers into the HttpResponse object, so rather than doing:

response = HttpResponse()
response['foo'] = 'bar'
return response

You could instead return HttpResponse(headers={'foo': 'bar'})

Perhaps that's better in a separate ticket / PR, but it seems like a
minimal amount of effort to add it at the same time.

Cheers,
Tom

On Wed, 17 Jun 2020 at 21:53, Adam Johnson  wrote:

> I have also found this a little odd when writing tests. It would certainly
> make it easier to write both normal Django code and tests, and it's a small
> addition, so +1 from me.
>
> On Wed, 17 Jun 2020 at 15:35, Tom Carrick  wrote:
>
>> I don't find myself using HttpResponse very often, usually I'm using
>> DRF's Responses. But today I needed to use one, and as I was writing tests,
>> I ended up somewhat astonished, so with the principle of least astonishment
>> in mind... I had anticipated that I could check the headers with
>> `response.headers`, similar to how the new request.headers
>> <https://code.djangoproject.com/ticket/20147> works, but apparently this
>> is not the case. After reading the docs, I found out that I should just
>> treat the HttpResponse object itself as if it were a dictionary of headers.
>> This seems very strange to me, it's not what I expect, but maybe I'm in the
>> minority.
>>
>> I have no interest in deprecating the old API, but it would be nice if
>> the headers were all accessible from a simple headers dict, and perhaps
>> make this the source of truth, allowing access with any casing but
>> preserving the original casing for output. It looks like what is currently
>> HttpResponse._headers was once HttpRequest.headers, but this was 13
>> years ago <https://code.djangoproject.com/ticket/5479>, I don't think
>> it'd be confusing to add the property back as something different.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAHoz%3DMa9-m%2Bfqj0wqzQ7qW5Aiw3POHtNOp2NTBaHeP_ux5FhLg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAHoz%3DMa9-m%2Bfqj0wqzQ7qW5Aiw3POHtNOp2NTBaHeP_ux5FhLg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> --
> Adam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2HCJKbW%3D3dNkB7BDV4R6eSAGokg%3DPENFd%3D%2BhNwaTt9OQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM2HCJKbW%3D3dNkB7BDV4R6eSAGokg%3DPENFd%3D%2BhNwaTt9OQ%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/CAHoz%3DMa7QfRHgaT7iJTAqnpzVo6ZoHKcdLVp8dER%2BCus0G_wpw%40mail.gmail.com.

Re: Admin accessibility

[Tom Carrick]

I've added a PR to the DEPs repo to hopefully get some eyes on it:
https://github.com/django/deps/pull/69

Thibaud, I think whatever you have the time and motivation for sounds good,
all of those things are useful. If you're not sure about all the admin
features, I think that's pretty normal. One project I've had on my mind for
a while now is to build a simple django site that is essentially just there
to use every feature of the admin, so I might bump that up the priority
list, though it's somewhat daunting.

Cheers,
Tom

On Mon, 13 Jul 2020 at 01:15, Thibaud Colas  wrote:

> Update for the proof of concept CI tests from my side – thank you Tom for
> the feedback. Here are the latest additions to the test suite & reports,
> still living at https://thibaudcolas.github.io/django_admin_tests/,
>
> - Added as much as I know about in the admin, and now also outside of it a
> bit (startproject welcome page, error pages)
> - Separated the issues between Axe and HTML_CS so the numbers are easier
> to understand
> - Added anchor links everywhere for easier navigation
> - I’ve also started a draft list of "things to (potentially) audit", over
> at
> https://github.com/thibaudcolas/django_admin_tests#scope-for-future-audits
>
> I think the next two big steps are what you mention:
>
> - Having a way to track the number of issues over time. Currently the
> report overwrites itself every week (well, every build). If you have a
> suggestion on ways to demo this that would be useful please let me know.
> Currently I’m thinking sparklines for each test case could be nice as a
> proof of concept, and a sparkline for the total number of issues. Or see
> whether I should get out of my comfort zone a bit and find a
> dashboard/graphing tool to send the metrics to and graph there.
> - Testing more features of modeladmin. I don’t use it too frequently
> myself so don’t really know what’s “easy” to enable – if you know of an
> existing test suite I could repurpose, or of an example of using a lot of
> functionality – I’d be keen to invest time to add it to my test site.
>
> Alternatively something else I could do is to file a ticket for
> accessibility issues with the welcome page – I’ve tested it with screen
> readers, there are a few issues, but nothing that should be too hard to
> fix, and it might be a good demo of what reporting accessibility issues in
> general could look like?
>
> Cheers,
>
> Thibaud
>
>
> On Tuesday, 30 June 2020 at 18:59:53 UTC+1 Tobias Bengfort wrote:
>
>> Nice writeup! I found it easy to read (I did not catch myself skipping
>> paragraphs which is always a good sign). Contentwise, I would have no
>> issue if this was accepted as is. Maybe I am forgetting about some
>> important details though.
>>
>> I had just some ideas that might be good additions:
>>
>> - mention ATAG somewhere
>>
>> - It would be nice to have a real commitment to accessibility. Something
>> along the lines of "accessibility bugs must be treated with the same
>> priority as any other bugs".
>>
>> - The step from "leaving accessibility in the hands of
>> individual contributors" to "you have to commit for 9 months" is a tad
>> big. I keep wondering if we can do something to improve the options in
>> between those. One idea would be to formalize an "a11y" keyword so
>> interested contributors can easily find related tickets.
>>
>> tobias
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e65e3879-d74c-4401-9232-29eb0a73385cn%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/CAHoz%3DMZ_%2BR%2BMWxeJtsQt1%3DW-9hT-wS7Nk7ALUKnozDaRKzQFbw%40mail.gmail.com.

Re: Admin accessibility

[Tom Carrick]

I've had some time to work on this, I've written up a draft... draft DEP
today, and I'd like to request feedback. I've written it quite hastily over
the last few hours with the expectation that it will need to be
substantially rewritten. I've added it as a local PR on my fork of DEPS to
keep the discussion in one place. I'm happy to take broad feedback here,
but try to keep specific feedback on the PR itself to keep the noise off
this thread. PR: https://github.com/knyghty/deps/pull/1

I'm also requesting someone to shepherd this, and ideally also a co-author,
particularly someone on the technical board, a core dev, or someone else
with experience of Django's governance, as I think this is the first
process DEP written by a non-core dev.

Cheers!
Tom

On Thu, 25 Jun 2020 at 19:31, Tom Carrick  wrote:

> I've managed to have a quick look, it looks really promising. Having a
> total number of issues to compare against would be good to avoid
> regressions or introducing new issues. I do have one concern. To be viable,
> it needs to live in the django repo somewhere. And we'd need a full admin
> site to test against, with every admin feature (stacked / tabular inlines,
> filtering, search, date filters, list editable, autocomplete, ...) to be
> fully representative and catch everything. This seems like a really big
> amount of stuff to add into the repo, that will need to be maintained, and
> possibly an easy thing to forget about. Also the maintenance is tricky, we
> should ideally not update this site too often or the total number of issues
> won't be as easily comparable. I wonder if there's another way to handle
> it, but I can't think of one.
>
> I also imagine this would be pretty intensive to run, it would probably be
> best to not run it by default and have a buildbot command to run this
> manually for PRs where there are changes to the admin.
>
> On Thu, 25 Jun 2020 at 02:15, Thibaud Colas 
> wrote:
>
>> Hi Tom,
>>
>> Great to hear – no rush if you’re busy with other things. Here’s a quick
>> proof of concept, with 20 different pages/scenarios, tested with Axe, HTML
>> Code Sniffer, and Lighthouse:
>> https://github.com/thibaudcolas/django_admin_tests.
>>
>> I’m not a big fan of Lighthouse personally, and I already had the rest of
>> the tools set up, hence why I went with this. I spent a bit of time making
>> a report out of the test results, which you can see an example of at
>> https://thibaudcolas.github.io/django_admin_tests/. This is generated in
>> Travis, currently set up to run those tests & regenerate the report from
>> Django’s `master` branch once per week.
>>
>> I added instructions on the README to run this locally if anyone wants to
>> try it out, and a few words about what to make of the report / issues. I
>> didn’t look into what the issues were though.
>>
>> Let me know what you think, and I should be able to spend more time on
>> this next week if it helps.
>>
>> On Wednesday, 24 June 2020 at 09:11:52 UTC+1 t...@carrick.eu wrote:
>>
>>> A quick update first. I'm pretty busy with a combination of day job and
>>> personal projects, but I should have time to start writing the draft DEP in
>>> the next week or two.
>>>
>>> Thibaud, I think the absolute most important thing is a way to measure
>>> progress, even if - as others have mentioned - that measure is imperfect. I
>>> think getting a proof of concept of Lighthouse running against a few admin
>>> pages would be extremely helpful. It's also probably one of the more
>>> difficult things. If that seems like too much, I think catching what the CI
>>> would miss is the next most important thing, so I think your #1 suggestion
>>> would work well.
>>>
>>> On Tue, 23 Jun 2020 at 22:34, Thibaud Colas  wrote:
>>>
>>>> Hey Tom,
>>>>
>>>> I wanted to check if there is anything we/I could do to help in the
>>>> meantime? Whether that’s by starting to map or audit the Django admin, or
>>>> setting up a sample CI pipeline with accessibility tests, or something else
>>>> altogether. It’s a bit daunting to get started with this but I think I
>>>> could realistically do one of:
>>>>
>>>> 1. Create a draft map of the Django admin UI for later manual auditing
>>>> purposes.
>>>> 2. Audi a specific part of Django and creating a ticket with concrete
>>>> things to fix.
>>>> 3. Set up static analysis for the CSS or HTML to look for common
>>>> accessibility gotchas.
>>>> 4. S

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

[Tom Carrick]

I do have a use-case where having a default SECRET_KEY makes things much
easier - docker.

Normally you can't run management commands in a Dockerfile if there's no
secret key (and often other things) set, and usually it's best to run
collectstatic as a build step.

So your options end up being:

1. Providing a default - works well as long as you remember to change it
for production.
2. Adding ARG SECRET_KEY=x to the line before - works ok, but when you
start needing to add more env vars for various other settings, it gets
really annoying.
3. Having a specific settings file just for building the image - also
somewhat annoying.

What I usually do (perhaps unwisely) is this:

from django.core.management.utils import get_random_secret_key
SECRET_KEY = os.getenv("SECRET_KEY", get_random_secret_key())

This makes it pretty obvious (to me) if I've forgotten to set a value in an
environment because I'll keep getting logged out of the site.
That is probably a terrible experience for new users, though, I can imagine
it's pretty confusing if you don't know what the problem is.

On Fri, 26 Jun 2020 at 12:20, Shai Berger  wrote:

> Hello,
>
> On Fri, 26 Jun 2020 00:46:02 -0700 (PDT)
> Florian Apolloner  wrote:
>
> > On Thursday, June 25, 2020 at 7:52:31 PM UTC+2 kit@gmail.com
> > wrote:
> >
> > > Personally, I think that *at minimum* providing Django-builtin "get
> > > from env"  helpers would be great; beyond that, I'd love to have
> > > them be included around `DEBUG` and `SECRET_KEY` with the current
> > > values as defaults, so they're optional. Once we see how this gets
> > > used, we can see about passing it a file instead of `os.environ`,
> > > or borrowing other ideas from any of the various supporting
> > > projects that have been suggested.
> >
> > I am all for minimal variants, but I do not think this would could
> > it. [...]
>
> > And there are plenty more things to consider; for instance I do not
> > agree that it makes sense to have "SECRET_KEY" default to a value
> > when missing in the env. It is way to easy to type "SECRT_KEY" and
> > never realize that. So if "SECRET_KEY" is taken from the environment
> > it should fail loudly if it is not present.
> >
> > [...] please note that the bar to add
> > this to Django is very high since it can (at least for things like
> > django-environ) easily live outside of Django with no realy downside.
> >
>
> Before this, when explaining the motivation for this, Kit said:
>
> > My hope is to make the smallest possible change to just start us
> > moving towards more clearly flagging, especially for newer devs,
> > "these are things that will need additional configuration in order to
> > move from 'works on my machine' to 'deployed'."
>
> We already have a tool designed for this: the "check --deploy"
> management command[1]. We can improve it a little by helping it detect
> that the SECRET_KEY is carelessly kept hard-coded from the initial
> project creation, e.g. by including somewhere a marker class:
>
> class HardCoded(str): pass
>
> and then in the default template
>
> SECRET_KEY = HardCoded('generated_value_like_today')
>
> Then the check could easily detect it and tell the user they need to
> change it.
>
> I think that a settings-only solution cannot be appropriate here, for
> the reasons Florian noted -- Kit is basically asking the default
> template to educate the user about deployment, but there is a tension
> between this and having things Just Work, which is important for
> beginners, and Just Work Securely (which is why the default SECRET_KEY
> needs to be a generated, random secret). To resolve this tension, we
> need a tool which is aware of context -- a tool which differentiates
> between the beginner on their laptop, and the novice doing their first
> deployment. The settings, in general, cannot make this distinction; a
> management command can.
>
> We have a whole bunch of documents about deployment[2] - maybe a little
> too much, and this probably encourages shorter "just do this" type
> deployment tutorials. Maybe we should make the checklist[3] more
> prominent, maybe we should make "check --deploy" even more prominent.
> But I don't think a single settings file can be all things for all
> users.
>
> My 2 cents,
> Shai.
>
>
> [1]
> https://docs.djangoproject.com/en/3.0/ref/django-admin/#cmdoption-check-deploy
> [2] https://docs.djangoproject.com/en/3.0/howto/deployment/
> [3] https://docs.djangoproject.com/en/3.0/howto/deployment/checklist/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/20200626131942.553c2b54.shai%40platonix.com
> .
>

-- 
You received this message because you are subscribed to

Re: Admin accessibility

[Tom Carrick]

I've managed to have a quick look, it looks really promising. Having a
total number of issues to compare against would be good to avoid
regressions or introducing new issues. I do have one concern. To be viable,
it needs to live in the django repo somewhere. And we'd need a full admin
site to test against, with every admin feature (stacked / tabular inlines,
filtering, search, date filters, list editable, autocomplete, ...) to be
fully representative and catch everything. This seems like a really big
amount of stuff to add into the repo, that will need to be maintained, and
possibly an easy thing to forget about. Also the maintenance is tricky, we
should ideally not update this site too often or the total number of issues
won't be as easily comparable. I wonder if there's another way to handle
it, but I can't think of one.

I also imagine this would be pretty intensive to run, it would probably be
best to not run it by default and have a buildbot command to run this
manually for PRs where there are changes to the admin.

On Thu, 25 Jun 2020 at 02:15, Thibaud Colas  wrote:

> Hi Tom,
>
> Great to hear – no rush if you’re busy with other things. Here’s a quick
> proof of concept, with 20 different pages/scenarios, tested with Axe, HTML
> Code Sniffer, and Lighthouse:
> https://github.com/thibaudcolas/django_admin_tests.
>
> I’m not a big fan of Lighthouse personally, and I already had the rest of
> the tools set up, hence why I went with this. I spent a bit of time making
> a report out of the test results, which you can see an example of at
> https://thibaudcolas.github.io/django_admin_tests/. This is generated in
> Travis, currently set up to run those tests & regenerate the report from
> Django’s `master` branch once per week.
>
> I added instructions on the README to run this locally if anyone wants to
> try it out, and a few words about what to make of the report / issues. I
> didn’t look into what the issues were though.
>
> Let me know what you think, and I should be able to spend more time on
> this next week if it helps.
>
> On Wednesday, 24 June 2020 at 09:11:52 UTC+1 t...@carrick.eu wrote:
>
>> A quick update first. I'm pretty busy with a combination of day job and
>> personal projects, but I should have time to start writing the draft DEP in
>> the next week or two.
>>
>> Thibaud, I think the absolute most important thing is a way to measure
>> progress, even if - as others have mentioned - that measure is imperfect. I
>> think getting a proof of concept of Lighthouse running against a few admin
>> pages would be extremely helpful. It's also probably one of the more
>> difficult things. If that seems like too much, I think catching what the CI
>> would miss is the next most important thing, so I think your #1 suggestion
>> would work well.
>>
>> On Tue, 23 Jun 2020 at 22:34, Thibaud Colas  wrote:
>>
>>> Hey Tom,
>>>
>>> I wanted to check if there is anything we/I could do to help in the
>>> meantime? Whether that’s by starting to map or audit the Django admin, or
>>> setting up a sample CI pipeline with accessibility tests, or something else
>>> altogether. It’s a bit daunting to get started with this but I think I
>>> could realistically do one of:
>>>
>>> 1. Create a draft map of the Django admin UI for later manual auditing
>>> purposes.
>>> 2. Audi a specific part of Django and creating a ticket with concrete
>>> things to fix.
>>> 3. Set up static analysis for the CSS or HTML to look for common
>>> accessibility gotchas.
>>> 4. Sett up automated in-browser accessibility checks on some parts of
>>> Django to show what that might look like in a CI pipeline.
>>>
>>> … and document the steps along the way, and report back here or as a
>>> ticket.
>>>
>>> Cheers,
>>>
>>> Thibaud
>>>
>>> On Tuesday, May 26, 2020 at 10:22:26 AM UTC+1, Tom Carrick wrote:
>>>>
>>>> Some further thoughts...
>>>>
>>>> Mariusz, I don't think I agree that WCAG is massive. It can look a
>>>> little large but I think that's mostly because each guideline is split into
>>>> smaller pieces and it's quite wordy to avoid ambiguity. There are in 2.1 50
>>>> success criteria for AA, many of which can be checked automatically, and
>>>> many of those that can't don't apply to us as we don't use audio / video.
>>>> There's also a nice quick reference
>>>> <https://www.w3.org/WAI/WCAG21/quickref/> that can be filtered to
>>>> remove AAA and anything

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

[Tom Carrick]

Javier, I just wanted to point out another option for configuration:
pydantic  - it offers a very slick
and intuitive interface for settings management across environments,
seamless handing of environment variables by using type hints, and so on. I
wouldn't recommend it for anything other than large sites with complex
configurations, but it does work well for those, once you grapple with how
to integrate it with django's settings so they're all exposed as
`settings.FOO`, and so on.

I don't think I would want to integrate anything like this into Django
proper, but it might deserve a mention in the documentation.

Tom

On Wed, 24 Jun 2020 at 23:52, Javier Buzzi  wrote:

> This makes sense, I have a project that has a lot of settings files that
> get activated depending on the value of DJANGO_SETTINGS_MODULE. The
> solution i outlined above takes your reservations under consideration, if
> you want to use it, great, if not also great -- its a supplement not a
> requirement.
>
> - Buzzi
>
> On Wednesday, June 24, 2020 at 5:24:35 PM UTC-4, Dan Davis wrote:
>>
>>  tMost of the world is not as seamless as heroku.  My DevOps won't give
>> me any more than a handful of environment variables.  I wanted something
>> like DATABASE_URL, but all I have is DJANGO_LOG_DIR and
>> DJANGO_SETTINGS_MODULE, and so I need many, many settings files. I think
>> that happens a lot, and maybe a common pattern.
>>
>> From a 12factor perspective, I would like to get it down to local
>> settings (development) and production settings - yet for a lot of users,
>> DevOps is not really supporting a full PaaS-like experience any way.
>>
>> So - all of this has to be optional, which seems to rule out making it
>> part of the starting project template.  For sure, I've got my personal
>> template, and work has an on-premise template and a Cloud template as well
>> - but the department of developers doesn't always use these.  I find
>> databases containing the tables for other projects, long after the models
>> and migrations are gone, indicating a start by copy mode.
>>
>> On Wed, Jun 24, 2020 at 1:35 PM Kit La Touche  wrote:
>>
>>> Carlton—thanks very much for the feedback. Javier—likewise. In
>>> particular, the imagined API you describe above is very appealing to me:
>>> start with `from_env` and then if you learn more about this and want to,
>>> add in some `EnvFileLoader`.
>>>
>>> I want to make clear my motivation and agenda here: I have recently had
>>> some conversations with newer devs about their experiences with deployment
>>> of apps they're working on, and with a friend at Heroku about his informal
>>> research into the problems people have with the same. One recurring
>>> friction point (and this is not just on Heroku at all, to be clear) is that
>>> there are a number of things that people *don't know they need to
>>> configure* for a working deployment.
>>>
>>> There are four settings that are recurring particular gotchas that
>>> people miss: the secret key, debug, static files, and databases. Static
>>> files seems big and out of scope, databases seems adequately handled by
>>> dj-database-url for most cases, and if your case is more complex, you'll
>>> learn it, but the other two (secret key and debug) seemed easy enough to
>>> flag as "you probably need to configure these!" with this sort of change to
>>> settings. This would be a first step towards shortening the distance from
>>> `startproject` to a working deployment.
>>>
>>> Newer devs in particular have, based on my conversations and this
>>> friend's research, been unlikely to (a) know that there are different
>>> `startproject` templates, and (b) feel equipped to choose one, if they do
>>> know.
>>>
>>> My hope is to make the smallest possible change to just start us moving
>>> towards more clearly flagging, especially for newer devs, "these are things
>>> that will need additional configuration in order to move from 'works on my
>>> machine' to 'deployed'."
>>>
>>> Towards that end, I thought that adding a "you might want to get this
>>> from the env" helper would be a clear indication to a new dev that this is
>>> a matter to even consider. Adding other configuration-getting options like
>>> different secret-store file backends seems like a good next step.
>>>
>>> Thanks,
>>>
>>> --Kit
>>>
>>> On Wed, Jun 24, 2020 at 11:13 AM Javier Buzzi 
>>> wrote:
>>>
 I looked at the libs that do what we want:

 django-configurations - it looks like they use environment variables /
 either via loading them from the environ or a key/value pair file. Having
 classes inside the settings.py might be weird to people.. at the least very
 different.
 confucius - very simplistic, only supports environ and is classed
 based, similar to django-configurations.
 django-environ - supports env file and environ, non-class based.
 dynaconf - supports all kinds of loading options (toml, json, ini,
 environ, .env

Re: Admin accessibility

[Tom Carrick]

A quick update first. I'm pretty busy with a combination of day job and
personal projects, but I should have time to start writing the draft DEP in
the next week or two.

Thibaud, I think the absolute most important thing is a way to measure
progress, even if - as others have mentioned - that measure is imperfect. I
think getting a proof of concept of Lighthouse running against a few admin
pages would be extremely helpful. It's also probably one of the more
difficult things. If that seems like too much, I think catching what the CI
would miss is the next most important thing, so I think your #1 suggestion
would work well.

On Tue, 23 Jun 2020 at 22:34, Thibaud Colas  wrote:

> Hey Tom,
>
> I wanted to check if there is anything we/I could do to help in the
> meantime? Whether that’s by starting to map or audit the Django admin, or
> setting up a sample CI pipeline with accessibility tests, or something else
> altogether. It’s a bit daunting to get started with this but I think I
> could realistically do one of:
>
> 1. Create a draft map of the Django admin UI for later manual auditing
> purposes.
> 2. Audi a specific part of Django and creating a ticket with concrete
> things to fix.
> 3. Set up static analysis for the CSS or HTML to look for common
> accessibility gotchas.
> 4. Sett up automated in-browser accessibility checks on some parts of
> Django to show what that might look like in a CI pipeline.
>
> … and document the steps along the way, and report back here or as a
> ticket.
>
> Cheers,
>
> Thibaud
>
> On Tuesday, May 26, 2020 at 10:22:26 AM UTC+1, Tom Carrick wrote:
>>
>> Some further thoughts...
>>
>> Mariusz, I don't think I agree that WCAG is massive. It can look a little
>> large but I think that's mostly because each guideline is split into
>> smaller pieces and it's quite wordy to avoid ambiguity. There are in 2.1 50
>> success criteria for AA, many of which can be checked automatically, and
>> many of those that can't don't apply to us as we don't use audio / video.
>> There's also a nice quick reference
>> <https://www.w3.org/WAI/WCAG21/quickref/> that can be filtered to remove
>> AAA and anything else unwanted. Once you drill down it can again get quite
>> wordy, but it covers a lot. I think it's worth remembering here is that the
>> point is not to strictly adhere to a standard for the sake of it, just to
>> improve the overall accessibility, and WCAG is a useful and measurable tool
>> to get us some of the way there.
>>
>> Thibaud, I more or less agree with everything there. I'm not sure
>> developers should have to do full accessibility checks for their changes in
>> the admin. Using a screen reader for example can be very frustrating and
>> confusing if you're not used to it, and it can take an inordinate amount of
>> time, and I don't really wish that burden on (for example) first time
>> committers who already have a lot of stuff to do, I think this will only
>> discourage contributions. I think it should be the responsibility of the
>> accessibility team to provide feedback, suggestions, etc. on relevant PRs
>> or fix things when they're noticed after manual audits.
>>
>> ATAG looks handy, but at first glance we couldn't even get to A, it
>> requires auto-saving. It also generally seems like something that would
>> cover a rich text editor plugged into the admin more than the admin itself,
>> though I think it's laudable as a future target.
>>
>> The more I think about it, I think the DEP should be a process DEP rather
>> than a feature DEP. As others have mentioned, we don't need a DEP to fix
>> accessibility issues - just fix them. But forming a team seems useful, and
>> I think a DEP is required for that. I think the DEP should be limited to:
>>
>> 1. The accessibility team, how membership is decided, who it's
>> accountable to, it's role/responsibilities, etc.
>> 2. Perhaps the initial standard(s) to target, although this could also be
>> decided by the a11y team post-assembly and agreed with the technical board
>> and/or core devs.
>>
>> As I said, I'm happy to write up the DEP, but since it'll be a process
>> DEP, I think I'd need the support of a core dev, someone on the technical
>> board, or just someone who has more knowledge of Django's "bureaucracy",
>> for lack of a better word.
>>
>> Tom
>>
>> On Tue, 26 May 2020 at 01:20, Thibaud Colas  wrote:
>>
>>> Hi Tom,
>>>
>>> It’s exciting to see this getting started! To me a DEP would be hi

HttpResponse headers interface

[Tom Carrick]

I don't find myself using HttpResponse very often, usually I'm using DRF's
Responses. But today I needed to use one, and as I was writing tests, I
ended up somewhat astonished, so with the principle of least astonishment
in mind... I had anticipated that I could check the headers with
`response.headers`, similar to how the new request.headers
 works, but apparently this is
not the case. After reading the docs, I found out that I should just treat
the HttpResponse object itself as if it were a dictionary of headers. This
seems very strange to me, it's not what I expect, but maybe I'm in the
minority.

I have no interest in deprecating the old API, but it would be nice if the
headers were all accessible from a simple headers dict, and perhaps make
this the source of truth, allowing access with any casing but preserving
the original casing for output. It looks like what is currently
HttpResponse._headers was once HttpRequest.headers, but this was 13 years
ago , I don't think it'd be
confusing to add the property back as something different.

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

Re: The blacklist / master issue

[Tom Carrick]

On moving away from the master branch, it would be a lot of effort (not
just in the repo, but docs, Trac, etc.), but I think it's worth doing
regardless. I think there is often some reluctance to do something
time-consuming because it takes someone's time away from technical issues.
I don't think this is necessarily true. Although we could always use more
contributors, this is something that's fairly easy for a newcomer (talking
specifically about the changes to docs). There's no requirement to know
about ORM internals, async implementation, or anything else. Just some time
and thoroughness. I'd be happy to put the time in, and I'm sure there are
many other (potential) contributors willing to do so, and It doesn't stop
the more technical people working on the issues they want to. I think all
that is really required - if/when a decision is made, would be to review
the PR, change the branch in Github, migrate Trac. Of course I don't know
what else is affected, so maybe I'm being optimistic here.

This does have some precedent also, there was a move from trunk to master
when moving from SVN to git. That was part of a bigger change to a new VCS
system, admittedly, but I think this is also important. With that said, I
do think we should wait and see what naming convention git / GitHub /
GitLab etc. decide on. It seems like "main" has the most traction, which
seems fine to me, and, as has been mentioned, is less of a misnomer anyway.

One argument I've seen against both of these that I don't think has been
addressed in this thread is that this will set off a trend of renaming more
things, mastery, masters degrees, and so on. In case it needs to be
addressed, this strikes me as a slippery slope fallacy. Just because we do
one thing, doesn't mean we must necessarily do another vaguely related
thing. I don't see (or foresee) any interest in this, and I think as is
always the case in these things, we go where the consensus is. For example,
trolls aside, I don't see any criticism of e.g. Frontend Masters.

Just some further thoughts.
Tom


On Tue, 16 Jun 2020 at 15:44, Roger Gammans 
wrote:

> Funny you should say that but the git developers mailing list in is awash
> with patches and shouting about just this at the moment.
>
> It looks likely the patches will go in too - so that's not much of an
> arguement against.
>
>
> On Tue, 2020-06-16 at 16:35 +0300, אורי wrote:
>
> I think *master* is the default branch name in any Git repository. It's
> not about Django and even not GitHub. Do you want to change the default
> branch name in Git?
> אורי
> u...@speedy.net
>
>
> On Mon, Jun 15, 2020 at 7:28 PM Tom Carrick  wrote:
>
> This ticket was closed wontfix
> <https://code.djangoproject.com/ticket/31670#ticket> as requiring a
> discussion here.
>
> David Smith mentioned this Tox issue
> <https://github.com/tox-dev/tox/issues/1491> stating it had been closed,
> but to me it seems like it hasn't been closed (maybe there's something I
> can't see) and apparently a PR would be accepted to add aliases at the
> least (this is more recent than the comment on the Django ticket).
>
> My impetus to bring this up mostly comes from reading this ZDNet article
> <https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/>
> - it seems like Google have already made moves in this direction and GitHub
> is also planning to. Usually Django is somewhere near the front for these
> types of changes.
>
> I'm leaning towards renaming the master branch and wherever else we use
> that terminology, but I'm less sure about black/whitelist, though right now
> it seems more positive than negative. Most arguments against use some kind
> of etymological argument, but I don't think debates about historical terms
> are as interesting as how they affect people in the here and now.
>
> I don't think there is an easy answer here, and I open this can of worms
> somewhat reluctantly. I do think Luke is correct that we should be
> concerned with our credibility if we wrongly change this, but I'm also
> worried about our credibility if we don't.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1b47e74f1811390add42c91dab4ccea104b89fcf.camel%40gammascience.co.uk
> <https://groups.google.com/d/msgid/django-developers/1b47e74f1811390add42c91dab4ccea104b89fcf.camel%40ga

The blacklist / master issue

[Tom Carrick]

This ticket was closed wontfix
 as requiring a
discussion here.

David Smith mentioned this Tox issue
 stating it had been closed,
but to me it seems like it hasn't been closed (maybe there's something I
can't see) and apparently a PR would be accepted to add aliases at the
least (this is more recent than the comment on the Django ticket).

My impetus to bring this up mostly comes from reading this ZDNet article

- it seems like Google have already made moves in this direction and GitHub
is also planning to. Usually Django is somewhere near the front for these
types of changes.

I'm leaning towards renaming the master branch and wherever else we use
that terminology, but I'm less sure about black/whitelist, though right now
it seems more positive than negative. Most arguments against use some kind
of etymological argument, but I don't think debates about historical terms
are as interesting as how they affect people in the here and now.

I don't think there is an easy answer here, and I open this can of worms
somewhat reluctantly. I do think Luke is correct that we should be
concerned with our credibility if we wrongly change this, but I'm also
worried about our credibility if we don't.

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

Custom collation support

[Tom Carrick]

I think it would be useful to be able to create collations and use them
with model fields. The motivation here is mostly that citext is somewhat
discouraged  in favour of
creating a collation. I'm not sure how this would work on other
databases,or what the API would look like. I didn't see a ticket for it or
another discussion, but maybe there is one.

Perhaps a Collation class would make sense, and it could be added to a
Field with a new parameter. I'm not sure how easy it would be to only
create a collation once, so perhaps it would need a CreateCollation
migration as well, but I know very little about the internals of migrations.

Cheers,
Tom

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

Re: Admin accessibility

[Tom Carrick]

nt / paginating, etc). I also find it worthwhile to add a
> succinct definition of how each of those pages is likely to be used – for
> example things that are only configured once for a site’s lifetime are
> presumably not as worth improving as a screen a user would see on a daily
> basis. Here is an example in practice:
> https://docs.google.com/spreadsheets/d/1rTMilzKhcb43Y3fZKGJJeoKWLCR00bfgwVB9f6OaC2U/edit
> <https://docs.google.com/spreadsheets/d/1rTMilzKhcb43Y3fZKGJJeoKWLCR00bfgwVB9f6OaC2U/edit#gid=0>.
> This can also be used to track the auditing effort, and form the basis of
> an automated test suite for CI (or simply repeat testing).
>
> Finally, consider ATAG2.0 <https://www.w3.org/TR/ATAG20/> (Authoring Tool
> Accessibility Guidelines) compliance additionally to WCAG. At a high level,
> ATAG is made of two parts:
>
> - Part A: Make the authoring tool user interface accessible. That sounds
> like what we’re discussing here.
> - Part B: Support the production of accessible content. That’s a whole
> other topic but feels relevant too.
>
> ATAG is nowhere near as well known / established / easy to test for, but
> it feels very relevant to the Django admin in particular, and I’m sure
> there will at least be some useful bits to consider in its success criteria
>
> Hope this helps!
>
> Thibaud
>
>
> On Monday, May 25, 2020 at 11:56:39 AM UTC+1, Tom Carrick wrote:
>>
>> Hi,
>>
>> Thanks for the feedback. I had thought about a DEP when I was writing up
>> the original post actually, I just wasn't sure what it should contain. Here
>> are my thoughts, based on the feedback so far:
>>
>> - Defining a standard to target.
>> - Forming an a11y team that covers the django admin and all sites in the
>> django github organization, and defining its role, membership, etc.
>> - Deciding on a CI process
>> - An outline of current issues and how to solve them.
>>
>> If anyone can think of anything else, please let me know. If/when there's
>> a consensus I'll start writing a draft.
>>
>> Mariusz, I mentioned this in the original post, but
>> https://www.w3.org/WAI/policies/ has a good overview of laws and EU
>> directives in this area. From my browsing through, it seems that they all
>> either, have their own national standard, or are using WCAG 2.0/2.1 AA.
>> Since we probably don't want to define our own standard, I think AA is the
>> way to go. This seems to also be the recommendation I hear from people in
>> the accessibility field working on regular websites. AAA seems to be more
>> suited for very specialist sites that explicitly target disabled people.
>>
>> Most of AAA is completely feasible for us, but there are some reasons it
>> would be difficult:
>>
>> - All language needs to be at a lower secondary education level, or have
>> an alternative that is. This doesn't seem feasible, for e.g. the
>> documentation.
>> - Users that are logged out need to be able to resume their session where
>> they left off after logging in, with all form fields filled, etc.
>>
>> There are others that are difficult, but I don't think any apply to us
>> currently.
>>
>> Cheers,
>> Tom
>>
>>
>> On Mon, 25 May 2020 at 11:09, Mariusz Felisiak 
>> wrote:
>>
>>> Hi Tobias,
>>>
>>>   I'm not a WCAG expert, and it's not clear to me what steps we would
>>> like to take. In the ticket we have only steps describes as *"very
>>> basics which should include"*, so I can imagine that's not all we need
>>> to do to be WCAG 2.1 compliant on AAA, AA or A level. As far as I'm
>>> concerned WCAG is quite massive. Moreover if we want to make changes in CI
>>> we should discussed available tools, etc. We can change colors but what
>>> next? We will be not able to guarantee that the contrast of all elements
>>> remains appropriate, we cannot do this manually.
>>>
>>> Best,
>>> Mariusz
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-d...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/be97c4e7-f961-4d46-998f-693ca6076f09%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/be97c4e7-f961-4d46-998f-693ca6076f09%40googlegroups.com?utm_medium=email

Re: Admin accessibility

[Tom Carrick]

Hi,

Thanks for the feedback. I had thought about a DEP when I was writing up
the original post actually, I just wasn't sure what it should contain. Here
are my thoughts, based on the feedback so far:

- Defining a standard to target.
- Forming an a11y team that covers the django admin and all sites in the
django github organization, and defining its role, membership, etc.
- Deciding on a CI process
- An outline of current issues and how to solve them.

If anyone can think of anything else, please let me know. If/when there's a
consensus I'll start writing a draft.

Mariusz, I mentioned this in the original post, but
https://www.w3.org/WAI/policies/ has a good overview of laws and EU
directives in this area. From my browsing through, it seems that they all
either, have their own national standard, or are using WCAG 2.0/2.1 AA.
Since we probably don't want to define our own standard, I think AA is the
way to go. This seems to also be the recommendation I hear from people in
the accessibility field working on regular websites. AAA seems to be more
suited for very specialist sites that explicitly target disabled people.

Most of AAA is completely feasible for us, but there are some reasons it
would be difficult:

- All language needs to be at a lower secondary education level, or have an
alternative that is. This doesn't seem feasible, for e.g. the documentation.
- Users that are logged out need to be able to resume their session where
they left off after logging in, with all form fields filled, etc.

There are others that are difficult, but I don't think any apply to us
currently.

Cheers,
Tom


On Mon, 25 May 2020 at 11:09, Mariusz Felisiak 
wrote:

> Hi Tobias,
>
>   I'm not a WCAG expert, and it's not clear to me what steps we would like
> to take. In the ticket we have only steps describes as *"very basics
> which should include"*, so I can imagine that's not all we need to do to
> be WCAG 2.1 compliant on AAA, AA or A level. As far as I'm concerned WCAG
> is quite massive. Moreover if we want to make changes in CI we should
> discussed available tools, etc. We can change colors but what next? We will
> be not able to guarantee that the contrast of all elements remains
> appropriate, we cannot do this manually.
>
> Best,
> Mariusz
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/be97c4e7-f961-4d46-998f-693ca6076f09%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/CAHoz%3DMaG5C7hHJ%3DJZaLZ8DNsevZzr8hmJ%3Dd4S%3D1mmTsXkiyPZw%40mail.gmail.com.

Re: Admin accessibility

[Tom Carrick]

Hi Adam,

> Which checker did you use?

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

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

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

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

Cheers,
Tom

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

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

Admin accessibility

[Tom Carrick]

Sorry, long post incoming.

The admin currently has some accessibility issues. Not a huge amount,
actually, but they should be fixed regardless. I hope I don't need to
convince anyone here of the importance of accessibility, but I'll try to
make the case as briefly as possible for the benefit of the wider community.

There is a trend towards stronger accessibility laws - there is a good
roundup of them here: https://www.w3.org/WAI/policies/ - and I'll come back
to this later. Most of these cover the public sector and small segments of
the private sector, but there's also an overview of some laws used against
private entities more generally here:
https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines#Legal_obligations

I should make it clear that I'm not a lawyer and have no idea if any of
this would apply to the admin, since it's not intended for general
consumption, so I think I'd rather make this point: Developers and other
people using the admin - "staff users" of some kind - can have disabilities
too, and we should be catering for them, especially since the remedies are
not at all difficult. It's also worth pointing out that accessibility
improvements almost always improve the general experience. For example,
making sure everything is easily accessible for keyboard only users is also
beneficial to power users. Better contrast and larger fonts are more
legible for everyone, not just for those with low vision, etc.

So I think the place to start here is to decide on a guideline to aim for,
and I'm pretty convinced at this point that WCAG 2.1 at Level AA is the way
to go: https://www.w3.org/TR/WCAG21/

Why not AAA? Well, it's really hard / time-consuming. For example, users
have to be able to select their own foreground / background colours, if a
user's session expires, they need to be able to login in again and pick off
where they left off (forms filled, etc.), and more. Moreover, every law
I've looked at seems to use WCAG 2.0 (2.1 is just a couple years old and is
backwards compatible) at Level AA, so this seems like the target to aim
for. I don't see a reason to not make specific improvements to AAA where
they're relatively simple, however, but my point is that we should make AA
a minimum requirement.

So if that is accepted, we need a few things:

1. Document it and update the contributing docs.
2. Audit the admin properly.
3. Fix any issues.
4. Make sure reviewers have this in mind for admin changes (I'm not sure if
there's any CI solution for this, but it would be nice to have).

I haven't audited the entire admin, but I have run a checker through some
pages. The main issues are with contrast and small font sizes, and the
changelist also seems quite painful. For example, there are no labels on
the checkboxes to select rows, which is going to be pretty hard to
understand and use if you're blind. A quick aria-label can fix this without
affecting it for sighted users.

Another issue here is harder to solve, it requires two tabs to move to
another row of the change list in the default state (one for the checkbox,
one for the link to the change form page). If you have editable fields in
the change list, it's another tab for each. It would be nice to be able to
use vim keys to move up and down rows, perhaps be able to hit * to select a
row for an action. In general, keyboard shortcuts would be handy elsewhere
too. It would be nice to be able to hit a key to open the nav sidebar which
also sets tab focus on the first link, for example.

But these details aren't the point of the post. The point of the post is to
decide if this is worth it (clearly I think it is), and how to move
forwards on it. Any thoughts?

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

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Tom Carrick]

> This often confuses beginners and “returners” alike.

I'm neither a beginner nor returner and I still have to remind myself that
request.POST doesn't contain my JSON data.

I think it's a positive change. I agree there are things that would provide
a better ROI, but people have to be willing to do them. I also think
there's no harm in tackling things with a lower ROI.

Tom

On Wed, 6 May 2020 at 10:49, Steven Mapes  wrote:

> Ah yes that's true, totally forgot about *request.body*  just then even
> though I was using it a few days ago. So yes renaming it would help in that
> regard as I do remember seeing a few S/O question where it's confused
> people in the past.
>
> *Mr Steven Mapes*
> Software Development and Solutions
> E: st...@jigsawtech.co.uk
> P: 07974220046
> W: https://uk.linkedin.com/in/stevemapes/
> [image: Twitter] 
>
> This E-Mail and its contents are confidential, protected by law and
> legally privileged. Only access by the addressee is authorised. Any
> liability (in negligence, contract or otherwise) arising from any third
> party taking any action or refraining from taking any action on the basis
> of any of the information contained in this E-Mail is hereby excluded to
> the fullest extent of the law. In the event that you are not the addressee,
> please notify the sender immediately. Do not discuss, disclose the contents
> to any person or store or copy the information in any medium or use it for
> any purpose whatsoever.
> On May 6 2020, at 9:43 am, Adam Johnson  wrote:
>
> I always took the capitalisation of GET &co to come from HTTP
>  — I'd say that's where PHP
> took it from too but 🤷‍♀️
>
>
> Yes GET and POST are capitalized in HTTP, but then COOKIES is not
> (Set-Cookie / Cookies headers), and FILES and META aren't direct references
> to anything in HTTP.
>
> Also I'm not sure it's a particularly good argument. Capitalization inside
> Python should be based upon the conventions of Python, not the conventions
> of the system the code talks to. For example, we have SELECT ... FOR UPDATE
> in SQL, but .select_for_update() in the ORM.
>
>
> Hmmm. I have to say I think there are areas where we could get a better
> ROI on our time than this.
>
>
> I think if we took the amount of time spent by users due to the confusion
> of GET/POST, divided by the amount of time to make the code and docs
> changes, it would come out with a relatively good ratio.
>
> My inspiration (or "the final straw") for making this proposal was a
> recent forum question with confusion on the meaning of POST:
> https://forum.djangoproject.com/t/ajax-post-to-view-not-displaying-content/2034
>  .
> I'm pretty sure I saw another one in the past month but can't find it But
> it's an issue I've seen repeatedly. I know I've even spent time figuring
> out how I'd get the query params during a POST request.
>
> please do not use *request.form_data* as that is also misleading as you
> can POST many more sources than form data such as with APIs. post_data
> would be much clearer.
>
>
> Steven - I think you're confused by the current name. request.POST *only*
> contains POST'd form data. It does not contain other POST'd data, such as
> JSON bodies. So perahps that's another point for the name change?
>
> On Wed, 6 May 2020 at 09:29, Steven Mapes  wrote:
>
> Combined them would be very very bad and you would have the same problems
> as with $_REQUEST in PHP where you have to decide which one wins as you can
> make a POST to a URL with querystring where one of the parameters uses the
> same name as a element of the POST and but where the value is different.
> It's bad practice but it's valid
>
>
> On Wednesday, 6 May 2020 08:00:56 UTC+1, Jure Erznožnik wrote:
>
> I agree. If anything, I've always had issues with GET & POST being
> different entities in the first place, but never with their names. I would
> really like to see an entity combining both of them. THAT one, maybe the
> preferred way of doing so, would be lowercase, but RAW representations of
> incoming data, I for one like them being upper case. Always makes me think
> twice before playing with them.
>
> The content negotiation thingy is also something I would like to see more
> time invested in: I have a project where I have to hack & slash DRF's
> implementation in order to get what I want, but perhaps I'm tackling the
> issue incorrectly. But that's beside the point. People will always try to
> do stuff framework developers didn't think of. What's important is to give
> them a platform where they can do so easily.
>
> LP,
> Jure
>
> On 06/05/2020 08:08, Carlton Gibson wrote:
>
> Hmmm. I have to say I think there are areas where we could get a better
> ROI on our time than this.
>
> I always took the capitalisation of GET &co to come from HTTP
>  — I'd say that's where PHP
> took it from too but 🤷‍♀️
> That they're a bit "unpythonic" (Meh

Re: Removing url() ?

[Tom Carrick]

I'm in favour. Yes, it's some extra effort, and we have here some 30 or 
40-odd projects that have either been migrated to this or will need to be 
in the future. But if you're hopping between LTS releases, that's another 4 
years, which seems a good chunk of time for me, especially if you just move 
to re_path(), which is pretty trivial, enough to be scripted. And I think 
if you upgrade at every release then you expect a bit more work to do in 
that case.

I don't see a compelling enough reason to hold on to dead / undocumented 
code for close to a decade.

Cheers,
Tom

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

Re: Making the admin more navigable

[Tom Carrick]

I've added a PR here https://github.com/django/django/pull/12159

I'd appreciate if someone can give it a look, it's been a while since I've 
done any front end dev so there are probably nicer ways to do it.

I'm also getting a test failure, and I don't quite understand how my code 
could have caused it, so would also appreciate some help debugging that if 
it's possible.

Cheers,
Tom

On Sunday, November 24, 2019 at 11:20:39 PM UTC+1, Tobias Kunze wrote:
>
> On 19-11-24 10:29:36, Tom Carrick wrote: 
> >1. Is this something people actually want, or is it just me? 
>
> +1, especially with a flag to disable it. Thank you for taking this up! 
>
> We live in the days of wide screens, where using the screen for something 
> meaningful is definitely a good idea. I find it tedious to always click 
> back 
> to the start of admin pages to then select another category/model. 
>
> >2. How is the navigation best done? Since some projects can be very 
> large, 
> >I'm partial to something vertical, rather than horizontal, so a sidebar 
> >seems good. What the best UX is on smaller screens would be I'm a little 
> >less sure. 
>
> For the beginning, you can just hide the sidebar on smaller screens. They 
> won't lose any functionality, and users on larger screens will still 
> profit. 
>
> Later on, you can consider having a navigation hidden behind some menu 
> button, 
> to be shown when tapped, but I don't think that's required. 
>
> >3. Should we provide an API for adding more links? I guess we could have 
> >some overridable structure, perhaps in the form of `{"category": 
> ["link1", 
> >"link2", ...], ...}` 
>
> I'd say for the beginning the sidebar should show the links the admin home 
> page shows, so adding a link to one would also add it to the other. 
>
> In a second step we can distinguish between the two (and also figure out 
> if a 
> link should be shown as "active" in the sidebar.) 
>
> >5. Would this make the admin home page redundant, and if so should we 
> >replace it with something, and what should that something be? 
>
> I don't think the main admin page would be redundant or should be 
> replaced. 
> It'd still be used for mobile pages/smaller screens, at the very least, 
> and 
> changing the main site is also a major/breaking modification. Adding a 
> sidebar, especially with an option to disable it, won't hurt in upgrades 
> generally, but losing/changing home page functionality would be painful. 
>
> Tobias 
>

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

Making the admin more navigable

[Tom Carrick]

Hi folks,

One thing that every Django admin skin seems to do is add a sidebar or some 
other navigation to every admin page. It's clear that there is a want for 
this and personally, those skins don't offer much more that I need other 
than this, and they often end up unmaintained or lagging behind Django 
version support.

I'm happy to work on this perhaps over the holidays, but I wanted to at 
least sound it out a bit.

To be clear, this is what I'm proposing:

We have some kind of navigation (sidebar, etc.) that essentially replicates 
the admin home page - links to list pages for models categorised by apps.

This raises in my mind a few things...

1. Is this something people actually want, or is it just me?

2. How is the navigation best done? Since some projects can be very large, 
I'm partial to something vertical, rather than horizontal, so a sidebar 
seems good. What the best UX is on smaller screens would be I'm a little 
less sure.

3. Should we provide an API for adding more links? I guess we could have 
some overridable structure, perhaps in the form of `{"category": ["link1", 
"link2", ...], ...}`

4. Would this have an impact on projects / apps overriding the admin and 
how important is this?

5. Would this make the admin home page redundant, and if so should we 
replace it with something, and what should that something be? Generally the 
only other thing on there is the admin change history.

6. The admin's current browser compatibility is very wide, per 
https://docs.djangoproject.com/en/2.2/faq/admin/#what-browsers-are-supported-for-using-the-admin
 - 
I don't know if we need still support such old browsers, but the 
implementation (and time to test) will likely be affected by this.

I welcome any input / thoughts on this.

Cheers,
Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3c54c76c-0f24-4b24-b02a-833ce1116e92%40googlegroups.com.