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

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

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

ment 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 ticke

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

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

Re: Django's automatic admin interface.

d 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

Re: Deprecate CICharField, CIEmailField, CITextField

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

Re: Add a minimal 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 se

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

k 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 mov

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

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 wrot

Re: Deprecate CICharField, CIEmailField, CITextField

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

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

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 type

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 p

Re: Recognising Contributions

rison 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

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 Ja

Re: A base compression middleware class

ea 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 c

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

eful 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&#x

Re: On adding comments to database schema

n 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 woul

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 = PositiveBigIntegerField(...)`

Re: Django's build: Try Earthly?

se for this, 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://

Re: Help with ticket #28426

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 complicat

Re: Invitation to participate in a survey about Django

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 for the updated code

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 show

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

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

ether... 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&qu

Update returning

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

Re: Snowflake db backend

Django database backends 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

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

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,

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

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 cac

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

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

Re: Custom collation support

t of work to add this, but I'm 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

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: > >  > Hi Br

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

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

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

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

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

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

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 n

Re: Making max_length argument optional

lse 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 <http://contrib.pg/> f

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 D

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 WARNIN

Re: f-strings again.

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 wit

Re: Custom collation support

llations, 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 colla

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,

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

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

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

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

Re: HttpResponse headers interface

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

Re: HttpResponse headers interface

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 docu

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

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

Re: Admin accessibility

tty 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

Re: Defaulting to use BigAutoField in models

or indicative of a 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 cas

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: Defaulting to use BigAutoField in models

for havoc with code incompalities throughout django. It'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

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

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

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

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

Re: Admin accessibility

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 pi

Re: The blacklist / master issue

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

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: Defaulting to use BigAutoField in models

potted a small cleanup: > 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 >>

Re: The blacklist / master issue

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

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

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

$EDITOR, 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: >

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

rom the current model state 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

Defaulting to use BigAutoField in models

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

rhaps 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 fro

Re: Admin accessibility

r 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, 2

Re: Admin accessibility

fter 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 wha

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

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

Re: Disabling .delete() in querysets in Django

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 th

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&

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

e 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 w

Re: Removing url() ?

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

  1   2   3   4   5   6   7   8   9   >