Re: Update returning

alid 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:

Re: Update returning

()` 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 >> http

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

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,

Re: Django's automatic admin interface.

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

Re: Deprecate CICharField, CIEmailField, CITextField

operly 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 > &g

Re: Add a minimal Gitignore

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

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

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

Experience with black formatting in django

feedback from your experience would be most appreciated. Regards, Tom (@taldcroft on 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 fro

Re: Improvements to the startproject template

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 f

Re: Deprecate CICharField, CIEmailField, CITextField

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

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

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 n

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 Djang

Re: Recognising Contributions

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

Re: Recognising Contributions

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 Jame

Re: A base compression middleware class

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

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

Re: Update returning

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 ele

Re: On adding comments to database schema

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

Re: Adding ability to choose AutoField type (signed vs unsigned)

I don't think we need this anymore, at least not by default. The default 64 bit range is probably enough for the time being. We could switch the default to be `PositiveBigIntegerField` instead of `BigIntegerField` but I'm not sure if that's sensible. An explicit `id =

Re: Django's build: Try Earthly?

s, but I can't see anything in Earthly that would help manage or reduce this yaml-spaghetti? Tom On Wed, Mar 17, 2021 at 8:10 PM Vlad A. Ionescu wrote: > Hi Django devs, > > Nick Pope directed me to this list. Wondering if anyone is interested in > trying https://github.com/eart

Re: Help with ticket #28426

and retrying the request is a bit overkill and potentially a (unlikely) breaking change. Tom > On 4 Mar 2021, at 17:55, 'Adam Johnson' via Django developers (Contributions > to Django itself) wrote: > >  > I also think this is feature creep and if it's a complicated change it

Re: Invitation to participate in a survey about Django

to achieve. Because right now you could replace startlingly few words to turn this into an email about people’s thoughts on the new Pepsi flavor. Tom On Mon, 1 Mar 2021 at 23:17, Tan, J. wrote: > Dear Django contributor, > > We are doing research on understanding how developers manage a speci

Re: About the ORM icontains operator's disadvantage on PostgreSQL performance and query results.

, so it might not be a huge ask to say “now you should use a gin index”? Tom On Sun, 28 Feb 2021 at 09:28, Tom Forbes wrote: > Thank you for the clarification! > > On Sun, 28 Feb 2021 at 09:23, Mesut Öncel wrote: > >> Yes, 7 years ago I reviewed the ticket fo

Re: About the ORM icontains operator's disadvantage on PostgreSQL performance and query results.

e details, I can make the > necessary explanations. > > Tom Forbes , 28 Şub 2021 Paz, 12:36 tarihinde şunu yazdı: > >> Unless I’m missing something, the ticket you linked was last updated 7 >> years ago with two now-broken images. Which ticket did you open with the >> e

Re: About the ORM icontains operator's disadvantage on PostgreSQL performance and query results.

Unless I’m missing something, the ticket you linked was last updated 7 years ago with two now-broken images. Which ticket did you open with the examples? Tom On Sun, 28 Feb 2021 at 08:31, Mesut Öncel wrote: > The reason I opened all the problems in a single ticket was to s

Re: About the ORM icontains operator's disadvantage on PostgreSQL performance and query results.

Hey, I think it would be best if you opened a new ticket explaining your issue and the performance problems you’ve found (especially around Turkish characters). I’m not entirely clear what you wish to be changed: you wish for an expression index to be created automatically? Tom On Sat, 27 Feb

Re: Add a stable and documented setting to add files to the runserver watcher

a good “escape hatch” for packages that don’t use this signal yet, but it’s also not particularly… great. Not sure. Tom On 8 Feb 2021 at 02:16:45, Diptesh Choudhuri wrote: > I am working on a graphQL project which uses django and ariadne > <https://ariadnegraphql.org/>. This package suppo

Re: Increase default integer keys to 64 bits

Better than that: 3.2 is the first step to changing the default. See “customising the type of primary keys” in the release notes (https://docs.djangoproject.com/en/dev/releases/3.2/). “GENERATED BY DEFAULT AS IDENTITY” would be a nice improvement though. Tom > On 29 Jan 2021, at 01:58, Cur

Re: Update returning

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

Update returning

m 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

Re: Snowflake db backend

ends are much more plugin oriented and could definitely bring some advantages. But that’s a non-trivial task with a lot of constraints especially for a fairly community driven project like Django. Tom > On 22 Jan 2021, at 22:34, Scott Fought wrote: > > Snowflake (at this point)

Re: Snowflake db backend

evaluated it the performance characteristics where similar to Redshift, optimised for large analytical aggregation rather than fast, smaller result sets typically seen with Django apps. Tom > On 22 Jan 2021, at 21:49, Scott Fought wrote: > >  > We have written a Snowflake DB bac

Re: Polymorphics relationship

Hey, when proposing a feature it helps to give an example and clearly state what you wish to add, then we can give a much better opinion. Tom > On 21 Jan 2021, at 20:41, Jonnathan Carrasco > wrote: > > I have inspect the code base of django core and database, and we

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

Re: Technical Board Decision Needed: Admin append_slash behaviour.

an order of magnitude longer than the fast “404 but not really” path. So it begs the question “do we really want to?” Tom > On 6 Jan 2021, at 13:20, James Bennett wrote: >  > I'm going to be the contrarian here and at least ask whether the right answer > is "don't do any

Re: GitHub Actions

Sorry for bumping such an old thread, but I've created a github actions POC and written it up here: https://forum.djangoproject.com/t/improving-the-contribution-experience-with-github-actions/5964 On Monday, 11 November 2019 at 08:11:57 UTC Johannes Maron wrote: > Hi Mariusz, > > Cool, let me

Re: Add decorator django.utils.functional.cached_classproperty

than with our other cache implementations. However, this is a really small change, so maybe it’s OK. Tom > On 30 Dec 2020, at 14:46, Boris Krause wrote: > Hello, > I propose new feature - decorator cached_classproperty. > Django has a lot of methods for caching, like

Re: Integrating migrations with the check framework

anything more complicated. Tom On 23 Dec 2020 at 17:32:23, Ryan Hiebert wrote: > This is an interesting discussion that is separate from, but related to, > django-safemigrate, which we use to separate which migrations may run > before or after deployment. I intend follow along with this d

Integrating migrations with the check framework

oured outputs for dangerous operations. 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-deve

Re: Changing the discovery method for management commands

sure there is a compelling enough reason to add this is. Can you elaborate on exactly what `setup_pytest` would do? I see use cases mainly around commands that modify files in your Django project after installation, can you think of any other situations where this would be useful? Tom On 19 Dec 2020 at 13:

Re: App label with dot

Yes, a more friendly error message would be far better here! User-facing runtime exceptions like unpacking errors are never good. This should be quite a simple change to make, I’d suggest opening a trac ticket first and we can go from there. Tom > On 18 Dec 2020, at 16:38, Federico Capo

Re: Replace the default django test runner to a more robust testing framework (like pytest)

that most of the Python ecosystem has settled on pytest, and if we go along with that as well then we can reduce our maintenance burden whilst making our users happier. Tom > On 15 Dec 2020, at 13:52, Diptesh Choudhuri > wrote: > > Though the django default runner gets the job d

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,

Re: Custom collation support

also not sure if it's worth doing. Any thoughts? It'd be good to close the ticket, one way or another. Tom On Mon, 20 Jul 2020 at 15:35, charettes wrote: > > I like this idea, but I think we'd still want to offer the option of > using strings, since most projects run only against one

Re: Primary Key AutoField -> UUID Field

-created primary key type. Initially it will be restricted to AutoField subclasses only, but the intent is to make UUIDFields work with this as well. The first bit of work is here: https://github.com/django/django/pull/13179 Tom > On 14 Nov 2020, at 16:54, אורי wrote: > >  &

Re: Fail test runs on unraisable exceptions?

Would we need to run “gc.collect” after each test to make it deterministic? I’m all for this change - I think it’s a sensible thing to do. Tom > On 30 Oct 2020, at 16:30, Adam Johnson wrote: > >  > -Werror transforms warnings into exceptions. This is what happens with the > a

Re: Welcome email

the external Discourse API. I’ll leave that to anyone who has access and is willing (Andrew?). Tom On 29 Oct 2020 at 16:43:07, Tom Forbes wrote: > It actually might be simpler than I suggested. Discourse has a script to > import an mbox: > https://github.com/discourse/discour

Re: Welcome email

, it might be better to get the source of truth from Google Groups? Tom On 29 Oct 2020 at 16:11:04, Andrew Godwin wrote: > I'd be more than happy to assist a trial of moving things to the forum; > we've had it running for over a year now, and I feel it's a much easier way > to run a

Re: Welcome email

created it originally? This might be lost in the sands of time, but it might be good to find out if we can as this group might disappear if their account is suspended/deleted for whatever reason. Tom > On 29 Oct 2020, at 15:14, Carlton Gibson wrote: > > Hey Tom. > > I pinged t

Re: Welcome email

One alternative to the scraper might be using Google Takeout 率 (https://takeout.google.com/), but it’s unclear if that would export the messages themselves. And it would require the actual owner of the group to do that with their account. Tom > On 29 Oct 2020, at 15:05, Tom Forbes wr

Re: Welcome email

on both places. The second required adding a specific API key to existing users, which might trigger some confusing emails. I have some time free in the next few days and I’d love to do a proof of concept to see if it’s feasible, but I’d need elevated permissions on the forum. Tom 1. https

Re: Instance Based Management?

-extra.readthedocs.io/en/master/table_partitioning.html Tom > On 27 Oct 2020, at 05:30, Jure Erznožnik wrote: > >  > Hi Matthew, > > I think you found the wrong mailing list for this question. Might I suggest > you try django-us...@googlegroups.com? The question seems better suited the

Re: Admin accessibility

;>>> >>>> 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 f

Re: Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

. However, I would say that based on your previous posts to this mailing lists around authentication that you are definitely in need of some form of federated login/SSO for your several web properties. That would certainly alleviate this issue and some of the other problems you’ve reported here. Tom

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

Re: Making max_length argument optional

ptable? > > 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. >> &

Re: Making max_length argument optional

ry, 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_lengt

Re: Making max_length argument optional

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 <http://contrib.pg/> field. C

Re: Django 4.0 sessions

ppears relevant. Tom > On 9 Aug 2020, at 13:37, אורי wrote: > >  > Django developers, > > I'm using Django 3.0 with sessions on my websites, Speedy Net and Speedy > Match. I understand that sessions as they are now (in Django 3.0) will be > changed and removed in Django

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 th

Re: f-strings again.

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 fi

Re: Custom collation support

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

Re: Custom collation support

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

Re: contrib.auth.Group comment

I think this makes sense - I would create a ticket in Trac. On Wednesday, 17 June 2020 at 10:55:44 UTC+1 mike.d...@gmail.com wrote: > Auth Groups are fabulous for designing access control into a project. > However, success in such design relies heavily on either user memory or > documentation.

Re: Custom collation support

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

Re: HttpResponse headers interface

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

Re: HttpResponse headers interface

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/

Re: HttpResponse headers interface

he 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

Re: HttpResponse headers interface

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

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

() 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 h

Re: Admin accessibility

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: > Upd

Re: Defaulting to use BigAutoField in models

deeper problem. 1. https://code.djangoproject.com/ticket/30526 On Sunday, 28 June 2020 at 14:27:28 UTC+1 Tom Forbes wrote: > I spent some time last week experimenting with my patch, the biggest issue > I could find was that under some situations we add explicit casts to array

Re: Admin accessibility

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 >

Re: Defaulting to use BigAutoField in models

s also not possible > to migrate tables over to the new type. > > I'm not sure I agree here. For folks that are setting a up a new project > starting with UUIDField primary keys can be useful and if we're adding a > setting for this purpose I think we should it make it as flexible as >

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:

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

A small incremental change with some Django helpers and showing their use in the default settings.py is a great step forward, I would be +1 on that. Tom > On 25 Jun 2020, at 18:52, Kit La Touche wrote: > >  > Wow, `distutils.util.strtobool` is great to know about! > >

Re: Admin accessibility

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

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

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 outli

Re: Admin accessibility

#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 wit

Re: The blacklist / master issue

banner on > that landing page. Feel free to choose > > https://eji.org/ > https://org2.salsalabs.com/o/6857/p/salsa/donation/common/public/ > > And this kind of contribution will work much better. > > Thank you, for this opportunity to share my opinion. > >> On M

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

Re: Defaulting to use BigAutoField in models

up: > https://code.djangoproject.com/ticket/31698 > <https://code.djangoproject.com/ticket/31698> ) > > On Fri, 12 Jun 2020 at 11:40, Tom Forbes <mailto:t...@tomforb.es>> wrote: >> I think we should restrict the setting between normal and big auto fields >> only. Allowing UUI

Re: The blacklist / master issue

ssarily 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 202

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

Re: Proposal - Warn user when creating or applying a delete migration?

TOR, if the > terminal is interactive. This would be a nice usability improvement for use > of --empty or other situations where the user knows they need to edit the > migration too. > > On Fri, 12 Jun 2020 at 12:56, Tom Forbes <mailto:t...@tomforb.es>> wrote: > Full

Re: Proposal - Warn user when creating or applying a delete migration?

Fully agree, I would be against adding a y/n prompt. However we could make the `makemigrations` output more noticeable if it contains destructive operations? We could make the this line[1] output red text on destructive operations, yellow on maybe destructive (like altering a type), and green

Re: Defaulting to use BigAutoField in models

te so there’s no > way I can think of to express “make this auto-generated field a BigAutoField > only if this model is new”. > > The autodetector knows if a model is new. It could be that during one version > Django outputs BigAutoField for fields added in CreateModel only. >

Defaulting to use BigAutoField in models

by a PositiveIntegerField and so suffer from the same AutoField limitations Any thoughts on this? Tom 1. https://groups.google.com/d/msg/django-developers/imBJwRrtJkk/P4g0Y87lAgAJ <https://groups.google.com/d/msg/django-developers/imBJwRrtJkk/P4g0Y87lAgAJ> 2. https://github.com/django/django/pull/8924/

Custom collation support

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

Re: Admin accessibility

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 s

Re: Admin accessibility

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 t

Re: timesince 'depth' parameter

I like this idea. However while `depth=1` makes sense for shorter time periods where the difference between `4 hours` and `4 hours and 3 minutes ago` is not required to be displayed, when you get a value that is over a year ago it loses a lot of granularity. The difference between `1 year` and

Re: Admin accessibility

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

Re: Disabling .delete() in querysets in Django

()” on a queryset. Tom > On 20 May 2020, at 13:57, אורי wrote: > >  > Django developers, > > I recently disabled .delete() in querysets in all managers in my project, > after encountering a bug in a bulk delete queryset in my tests > [https://code.djangoproject.com/ticket/31600

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

Re: Removing url() ?

, adding a route, etc). libCST looks perfect for this, thanks for sharing. Tom > On 10 May 2020, at 14:12, Bruno Alla wrote: > >  > I've started working on a tool provides a set of codemodders for Django: > > https://github.com/browniebroke/django-codemod > > It's bas

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

ing 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 > re

Re: Removing url() ?

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

Re: Generate JWTs with Django

Thank you for the fantastic summary James. You’re spot on about the various implementation issues that plague JWT libraries. While I think it’s an OK technology if you use a very explicit subset and you know what you’re doing (see https://github.com/google/jws) it is indeed a bit of a

  1   2   3   4   5   6   7   8   >