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

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 j

Re: Update returning

ted 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

Re: Update returning

pdating 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 to

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

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 S

Re: Django's automatic admin interface.

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 dow

Re: Deprecate CICharField, CIEmailField, CITextField

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

Re: Add a minimal Gitignore

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 c

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

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

Re: Improvements to the startproject template

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 ha

Re: Deprecate CICharField, CIEmailField, CITextField

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.

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

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

Re: Django's issue tracker uses timezone CDT

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 Ka

Re: Recognising Contributions

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 wit

Re: A base compression middleware class

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 i

Re: Changing widget rendering templates

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 reps

Re: Update returning

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, usern

Re: On adding comments to database schema

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

Re: Update returning

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...

Update returning

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

Re: Quick Filter in the Admin Sidebar

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

Re: Quick Filter in the Admin Sidebar

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 >

Re: Custom collation support

gree 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

Re: Admin accessibility

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

Re: Bug report in Django docs

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

Re: Making max_length argument optional

gestion 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 r

Re: Making max_length argument optional

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 lo

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

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 u

Re: f-strings again.

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

Re: Custom collation support

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

Re: Custom collation support

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 > i

Re: Custom collation support

ather 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 t

Re: HttpResponse headers interface

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” > &

Re: HttpResponse headers interface

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 unnec

Re: HttpResponse headers interface

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

Re: HttpResponse headers interface

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, tha

Re: HttpResponse headers interface

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

Re: HttpResponse headers interface

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

Re: Admin accessibility

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 p

Re: Admin accessibility

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 l

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

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.

Re: Admin accessibility

>> 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 p

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

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 rec

Re: Admin accessibility

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 i

HttpResponse headers interface

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.hea

Re: The blacklist / master issue

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

The blacklist / master issue

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

Custom collation support

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 wha

Re: Admin accessibility

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 a

Re: Admin accessibility

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 site

Re: Admin accessibility

gt; 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:

Admin accessibility

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 th

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

> 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 d

Re: Removing url() ?

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 mov

Re: Making the admin more navigable

rstand 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 wan

Making the admin more navigable

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 behin