Re: Recognising Contributions

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

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?

Hey! I've recently been trying to improve our local/CI experience so this is quite a nice and timely message! I really like the look of Earthly and it has some uses at $WORK that I'm excited about,

Re: Help with ticket #28426

Personally I don’t think we should prompt the user for anything. If the user gives the username and password in the url (user:pass@host) then we can use that, otherwise we just throw an error. A more complicated solution involving making a request, detecting a 401, prompting the user and

Re: Invitation to participate in a survey about Django

I receive a few of these kinds of emails privately (I’m assuming they scrape my email from git history). On one hand I think it might be appropriate to post something like this to the developers mailing list if it was specifically targeted to Django, and it’s definitely good to help with research.

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.

se "ilike" instead of > "UPPER (column)" in the icontains operator, the 2 problems I mentioned will > be solved. > > Tom Forbes , 28 Şub 2021 Paz, 01:17 tarihinde şunu yazdı: > >> Hey, >> I think it would be best if you opened a new ticket explaining your issue &g

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

Hey Diptesh! It was always my intention to document and expose the autoreloader signals to third party applications, that way ariadne can configure watches on the graphql files it knows about. I think this is preferable to having users having to configure this directly in their projects. We kept

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

Re: Snowflake db backend

it's worth merging. >> >> Additionally Scott - would love to see Disney appear on this page, perhaps >> the "Platinum" section would feel comfortable: >> https://www.djangoproject.com/fundraising/ ;) >> >>> On Fri, 22 Jan 2021 at 21:57, To

Re: Snowflake db backend

I think this should definitely be released as a third party package, and if there is enough community interest it might be considered for inclusion. We could definitely update the docs to link to the package though. On a side note, is Snowflake fast enough for general purpose web apps? When we

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 add > this

Re: Technical Board Decision Needed: Admin append_slash behaviour.

I agree with this especially around the point about timing attacks. I don’t believe potentially being able to infer the names of models in a very, very noisy way (thousands of requests) gives anyone leverage in a system or even any particularly sensitive information at all. Maybe in a really

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

I’m slightly skeptical - a cached class property seems slightly iffy and could be achieved with just a @functools.cache’d classmethod instead? Is there a specific use case where a cached, class _property_ would be the best way? And perhaps we need to care about concurrent access here, more

Re: Integrating migrations with the check framework

might be >>> worth checking how that works. >>> >>> I'm not sure what any public API could look like here. In >>> django-linear-migrations ( >>> https://github.com/adamchainz/django-linear-migrations ) I tapped a bit >>> into the MigrationLoader

Integrating migrations with the check framework

Hey, A fairly common problem with large and/or highly trafficked web applications is migration safety: you want your migrations to be non-locking and instantaneous. The specifics are very database dependent but in Postgres simply altering the nullability of a column can incur serious downtime

Re: Changing the discovery method for management commands

I think it would be quite simple to add support for setuptools entrypoints into the discovery code (using Poetry, or with equivalent setup.py/setup.cfg statements): [tool.poetry.plugins.django] “setup_pytest" = “pytest_django.commands.setup_pytest” Despite it being easy I’m not sure there is a

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 Capoano

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

I would be very much in favour of this. The developer experience of pytest is far better than the unittest module, the tests look more Pythonic and there is a lot more of an ecosystem we can tap into. There was some recent work done about adding timings to the Djanfo test suite as part of the

Re: Primary Key AutoField -> UUID Field

Uri, I would definitely suggest using an actual UUID rather than rolling your own ad-hoc UUID implementation, even if your database does not support a native UUID type. Brian, there is some work ongoing that should make this possible. We will add a setting to control the type of the

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 > asyncio case yes

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 actually might be simpler than I suggested. Discourse has a script to import an mbox: https://github.com/discourse/discourse/blob/master/script/import_scripts/mbox.rb I’m running the box importer script now and it appears to work fine. While some people might have historical mbox files, it

Re: Welcome email

he Forum Powers That Be™ to see about permissions for you. > >> On 29 Oct 2020, at 16:09, Tom Forbes wrote: >> >> One alternative to the scraper might be using Google Takeout 率 >> (https://takeout.google.com/), but it’s unclear if that would export the >> mess

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

I think a google groups to discourse import is more than possible and would be good. I was quite skeptical about discourse at first, but it’s really quite awesome and definitely a set up from google groups. After a brief bit of searching I can see there is a tool to export all messages from a

Re: Instance Based Management?

I think what Mathew really wants is support for table partitioning. You can get this right now with this library[1] for postgres. I’m not sure if this makes sense to add to core, however support is quite broad (MYSQL, MariaDB, Postgres and Oracle). 1.

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

You might have a point regarding the frequency of bumping the PBKDF iteration setting. Is bumping it 5 times in 13 months really required? On the other hand you might want to consider staying on the LTS releases and avoid issues such as this, and the issue you’re describing is quite niche.

Re: Making max_length argument optional

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

Re: Django 4.0 sessions

> Is it possible to change the sessions deprecation Django version so that > users will have about 2 or 3 years to convert their sessions? Any session (or signature) that uses sha1 will no longer be valid in Django 4.0. Keeping insecure hash algorithms around for another 2 to 3 years at the

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

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! > > So, can we refocus

Re: The blacklist / master issue

As an international framework I think we should make our interface as language and culturally agnostic as possible. ‘Allow’ and ‘Deny’ are simply semantically clearer than ‘white’ and ‘black’. That alone is a convincing argument for me. > On 19 Jun 2020, at 13:55, Alexander Lyabah wrote: > >

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

I’d like to re-propose switching Django to use BigAutoField’s rather than the current AutoField. This has been proposed[1] before (and a MR made[2]) but it was closed due to implementation issues and not much else has happened since then. As many of you are aware the max value a standard

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: Disabling .delete() in querysets in Django

I don’t think a Django-wide setting to disable Queryset.delete() is appropriate. As you said, it’s easy enough to configure for the specific models that may (or may not!) benefit from this. A Django-wide setting like this would also break just about everything that calls “delete()” on a

Re: Removing url() ?

An idea for a Django equivalent to “rails generate” has been floating around my mind for quite a while. Automated codemods are not only useful for fixing deprecations but also many common, repetitive tasks that might involve modifying multiple files or boilerplate (creating a simple model,

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

Re: Google Groups contingency plan

il/2018/05/16/migrating-google-groups-archives-between-accounts > > <https://geek.co.il/2018/05/16/migrating-google-groups-archives-between-accounts> > . I think having a trial run ofthis would be a good first step to knowing > where we're at with preserving the data. >

Re: Google Groups contingency plan

t; On 26 Apr 2020, at 17:34, ⁨אורי⁩ <⁨u...@speedy.net⁩> wrote: > > > On Sun, Apr 26, 2020 at 7:14 PM Tom Forbes <mailto:t...@tomforb.es>> wrote: > Hello, > Given the recent worldwide situation I’ve found myself thinking a lot about > contingency plans recently. I wanted to r

Google Groups contingency plan

Hello, Given the recent worldwide situation I’ve found myself thinking a lot about contingency plans recently. I wanted to raise a question about our reliance on Google Groups and if we had any contingency plans if this service was shut down? To put it politely, it's pretty obvious that Google

Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

I would be in favour of Adam’s proposed changes. Adding more context to them and stripping the appended timestamp would make them more user friendly. > As a developer I would like to know who generated the code. If a migration is > auto-generated, I would like to know that. I checked and

Re: Deadlock bug in logging? Reproducible case

Just to confirm - are you running into this issue while using the Django development server in production, or does this occur with Gunicorn/uwsgi as well? Tom > On 23 Apr 2020, at 12:40, Brian Tiemann wrote: > > It also happens in 3.6.9, which is my prod environment. > > FWIW, by way of

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

ll now. The performance drop probably won't be >>> significant especially since this is SQLite. >>> >>> I'll update you here with the exact benchmarks later. I'm busy now with >>> school work, but I'll get back to it again later today. >>> >>&

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

t takes to > make the databases in-memory. > > Re-running migrations and recreating the SQLite database from scratch for > every worker might be a time-sink, but it could actually prove quicker than > other methods. I'll try it out as well and see. > > Thank you for your sugg

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

There is an interesting addition to the standard library in Python 3.8: multiprocessing.shared_memory (https://docs.python.org/3/library/multiprocessing.shared_memory.html). It’s only on 3.8 but it might be worth seeing if that has a performance improvement over passing a large string into the

Re: GSoC proposal research - type hinting

As an avid user of type hints I think it would be fantastic. I believe with the upcoming release we only target Python versions that support type hinting, which was one of the issues holding us back before. I would recommend choosing a specific part of Django and investigating adding type

Re: GSoC Mentors

Happy to help any way I can (very time constrained in the near future, but that should ease off). I think sharing the burden as a group is a great idea. On Wednesday, 25 March 2020 08:43:49 UTC, Carlton Gibson wrote: > > Hi all. > > We're reaching the end of the application period for GSoC.

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

Ahh, interesting! I think I can help mentoring, I’ll leave a reply in the official thread  > On 26 Mar 2020, at 11:40, Carlton Gibson wrote: > > Hi Tom. > > (I was wondering if you might fancy mentoring on this project? ) > > On Thursday, 26 March 2020 12:35:34 UT

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

> incompatible in macOS due to a recent update Can you elaborate on this a bit? How has a recent update made forking incompatible on MacOS? Tom > On 23 Mar 2020, at 19:22, Ahmad A. Hussein wrote: > > Django's parallel test runner works through forking processes, making it > incompatible on

Re: New Merger nomination.

Thanks for that James! Out of interest what is the exact implementation of the public vote? Is that performed at a meeting, via the mailing list or via the same/similar software used to elect the DSF board? Tom On Friday, 13 March 2020 20:25:58 UTC, James Bennett wrote: > > So I guess it's

Re: [Probably BUG] set_password and check_password accept values other than string as parameters

ses TypeError: > > In [16]: from werkzeug.security import generate_password_hash > > In [17]: generate_password_hash([1, 2, 3]) > TypeError: Expected bytes > > IMHO throwing an exception is a more reasonable approach. > > Anyway, thank you for your help :) > Dawid > &g

Re: New Merger nomination.

+1 from me! Seems like a no-brainer to make Claude a merger, his past and present contributions have been fantastic. On Friday, 13 March 2020 19:30:19 UTC, Mariusz Felisiak wrote: > > I nominate Claude Paroz to a new MERGER for 8 years of contributions to > Django, including triaging tickets,

Re: [Probably BUG] set_password and check_password accept values other than string as parameters

In this context it means that you shouldn’t encrypt, hash or otherwise manipulate the password before passing it into the method. Django, many other packages and Python itself will accept objects that can be coerced into a string (via __str__) rather than throw an exception. We’re all

Re: Use "raise from" where appropriate, all over the codebase

I agree with this change from a correctness standpoint but I would like to make the point that chained exceptions might be slightly annoying when displayed via console output, as you see the inner exception first and have to scroll up to see the exception you actually have to handle. Tom > On

Re: declarative settings

My two cents: JSON isn’t great as a configuration language - It’s annoyingly picky about some things. YAML or TOML are “better” (for some definition of better) choices for this domain, in my option. However, Django is historically quite hesitant about including third party packages and I think

Re: Forms submitted by bots

IMO this is outside of the scope of this mailing list. There is no simple answer to this problem, nor a general solution. There is however a wealth of information on this topic that you can find with a few Google searches. If there is something we can do to Django to make it easier to integrate

Re: Deprecate HttpRequest.is_ajax

nt or by appending something that >>>> manifests their intention - like in >>>> https://docs.djangoproject.com/en/2.2/topics/class-based-views/mixins/#more-than-just-html >>>> >>>> <https://docs.djangoproject.com/en/2.2/topics/class-based-views/mixins/

Re: Deprecate HttpRequest.is_ajax

ented when it is deprecated? > > From: django-developers@googlegroups.com > [mailto:django-developers@googlegroups.com] On Behalf Of Tom Forbes > Sent: Saturday, November 16, 2019 10:16 AM > To: django-developers@googlegroups.com > Subject: Re: Deprecate HttpReq

Re: Deprecate HttpRequest.is_ajax

I think this is a good starting point. What do we think about adding a “accepts_json” helper of some kind? It seems that the vast, vast majority of usages I can find of “is_ajax” is to return a JSON response, which I feel could be served nicely with a helper. There are also, annoyingly, two

Re: Deprecate HttpRequest.is_ajax

I would agree. Flask has done the same: DeprecationWarning: Request.is_xhr is deprecated. Given that the X-Requested-With header is not a part of any spec, it is not reliable In my opinion there are not many good reasons to have to change behaviour if a request is made via XHR. I think the

Re: GitHub Actions

No there isn’t. Right now Docker-box is optimized for local development and exists outside of the main repository, and for now I’d suggest not trying to integrate it. That can be some future work though! Regarding services vs apt, docker services is the only realistic way to do it. We cannot

Re: GitHub Actions

s?check_suite_id=299641652> > > -- > Johannes Hoppe > > www.johanneshoppe.com <http://www.johanneshoppe.com/> > > Want to chat? Let's get a coffee! > https://calendly.com/codingjoe/call <https://calendly.com/codingjoe/call> > > Lennéstr. 19 > 14

Re: GitHub Actions

Maybe this discussion is slightly off topic, and at the risk of derailing things I’d like to put out my view on this. There is more to it than just “using Github’s computing power”, just as there is more to using AWS than “using Amazon’s computing power”. That’s only a small part of it: it’s

Re: GitHub Actions

do we think? Tom > On 6 Nov 2019, at 13:58, Tom Forbes wrote: > > Yes there will be. Now Github has added caching I think we are good to go. > > I will send a link here with the longer running on my fork and we can look at > starting there. Once (if?) that’s merged then we

Re: GitHub Actions

Yes there will be. Now Github has added caching I think we are good to go. I will send a link here with the longer running on my fork and we can look at starting there. Once (if?) that’s merged then we can enable the “allow forks to run actions” option and we can iteratively add more tests as

Re: GitHub Actions

concerned about the lack of delivery on some Google groups messages. I had not been sent the first message from Johannes (it’s not in spam or any other place), and would have missed it if Felix has not replied. Tom >> On 31 Oct 2019, at 09:49, Florian Apolloner wrote: >  > I thin

Re: Removing old branches from the Django Git repository.

I second this, there are a few other branches in that list (successful or not) that have historic value to Django. Is there a pressing need to delete them, other than spring cleaning? I guess maybe it’s sentimental value, and nobody would ever check them out, but still... Tom > On 10 Oct

Re: Explore integrating django-docker-box in some way?

; I was going to archive the repo, but it seems I don't have the necessary > permissions. Carlton, do you? > > On Tuesday, 8 October 2019 21:45:22 UTC+11, Adam Johnson wrote: > +1 to archiving django-box > > On Tue, 8 Oct 2019 at 11:01, Tom Forbes > wrote: > Thank yo

Re: Explore integrating django-docker-box in some way?

er-box > is fantastic, it makes things much easier to setup. > > Thank you to everyone involved! > > On Wednesday, 5 December 2018 00:02:27 UTC, Tom Forbes wrote: >> >> To have this completely working at sprints without having everyone >> building their own local i

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

Hey David, I like this idea, while I don’t think the use case is common there have been a few times where I’ve needed this and got around it by creating/modifying the through model in bulk. Having a method that does this would be good IMO. Unless anyone has strong opinions against this then can

Re: Redis cache support in core

That's not necessarily a blocker, and Memcached is not simple to run on Windows either - there are no official prebuilt binaries, as far as I'm aware. > On 5 Sep 2019, at 14:29, Matthew Pava wrote: > > I’d just like to point out that Redis support on Windows is limited at best. > All other

Re: ipdb throws AttributeError in autoreload.py with 2.2.2

IPython seems to override `__main__`, which I certainly did not expect: https://github.com/ipython/ipython/blob/257e4c45563598810b0a771de286004617510fc1/IPython/core/debugger.py#L238

Re: Django 2.2 and the watchman reloader

to ensure only the main thread triggers the file changed notification), but otherwise it seems to be working OK locally. On Mon, Feb 25, 2019 at 10:22 PM Tom Forbes wrote: > I have a small PR here to remove the “watchman unavailable” message, > whilst keeping the one that specifies which re

Re: ERROR: The included URLConf 'website.urls' does not appear to have patterns in it. If u see valid patterns in the file then there is issue of Circular import.

As Adam states before, in the first reply to your original message, this mailing list is for the internal development of Django and not for getting help with your Django projects. There are numerous other places to ask, check his email for a few, and a lot of people (myself included) willing

Re: DEP 0008 (Formatting using Black) is accepted

There has been a particularly healthy debate on the mailing list, I think it was clear that a consensus was not going to be reached. Are there any points you wanted to bring up there that where not already made on the mailing list thread? Tom > On 11 May 2019, at 17:30, Michael Martinez >

Re: injecting settings

I think what you are describing is a hard problem(tm) with no clear and generic way to solve it. Django doesn’t have the concept of a dependency tree in apps, and while this is annoying in some cases there isn’t much we can do to solve it. If I understand your proposition, it would inevitably

Re: About query strings in urls when using rest api

This mailing list is for the development of Django itself, not for support using Django. Please use the django-users mailing list for that, or IRC #django on freenode, or a site like Stack Overflow. Also, please never add private credentials in query strings like that. Use a POST request. >

Re: A different approach for the auto-reloader

ss which is in charge of > restarting the 'upstream' web server process (in our case a dumbed-down > runserver dev server) only when it detects there have been changes. > > Been meaning to try this for some time. It would have been much harder > before Tom Forbes' work on refa

Re: Proposal to format Django using black

> so there is no way to know who is nodding along with which arguments. That somewhat impedes the point of posting this to get consensus, and if you ascribe to that view then all mailing list discussions about project wide changes are somewhat useless, as there could be a silent majority

Re: Proposal to format Django using black

I would be +1 for Black. I think it makes a lot of sense for a project like Django, and it does seem that a non trivial amount of both contributor and reviewer time is spent on formatting fixes. The choice of double quotes by default used to annoy me, but after using black for a while I think

Re: Why does ModelForm do validation and not Model

The idea is that you generally always have to do extensive validation when accepting user input through a form. These validations could require additional database queries or other somewhat expensive lookups (especially with validate unique). However if you are loading data from a trusted source,

Re: Add to QuerySet method `one` that acts as `first` but without ordering

I don’t think we should add a method like this for a few reasons. Firstly without an order by in SQL the order of rows is undefined, in practice myql orders rows but Postgres returns a different order per transaction. This will be confusing to users who don’t understand this and come to

Re: Request to reconsider ticket #27910: using an Enum class in model Field choices

I really like this implementation, it seems really clean and simple. I would suggest that it might be worth seeing it’s simple to make the display text optional, I think in the general case capitalising the key name would be acceptable. Users can always override it if required or if they need

Re: Official Django Docker Container Deprecated

I think the point we are trying to make is that it’s fundamentally not a good thing to try and distribute a one-size fits all docker image for a specific framework. For reference here is one you can use yourself: FROM python:3 COPY requirements.txt . RUN pip install -r requirements.txt COPY . .

Re: Official Django Docker Container Deprecated

There never was an official Django image, it was an "official docker" Django image that they maintained. The page image page explains why it was deprecated: https://hub.docker.com/_/django For most usages of this image, it was already not bringing in django from > this image, but actually from

Re: Django 2.2 and the watchman reloader

+1, Tom Forbes a écrit : > > Hey Claude, > Thanks for your feedback on the feature, I fully agree with you. I think > we should remove that warning message about the missing package. I will > make a PR to do that. > I'm not completely sure it's a good idea to entirely remove the m

Re: Use CDN for djangoproject.com

configuration change) since I don't think CloudFront supports passing a custom Host header to the origin like Fastly does (i.e., you'll probably need to edit /etc/hosts). Cheers, Tobias On Sat, Feb 23, 2019, 7:15 PM Tom Forbes wrote: > Sorry, I did not completely grok your message. I would be in fav

Re: Use CDN for djangoproject.com

Sorry, I did not completely grok your message. I would be in favour of just invalidating the whole cache if needed, it seems the simplest solution. Invalidating most of the cache on every non-dev deploy would also be OK I think. On Sun, 24 Feb 2019, 00:10 Tom Forbes, wrote: > Which CDN are

Re: Use CDN for djangoproject.com

hey run an old fork of Varnish which is not fun to configure. >>>>> >>>>> On Thu, 14 Feb 2019 at 11:16, Josh Smeaton >>>>> wrote: >>>>> >>>>>> Cloudflare have many SSL options, including fully encrypted and >>>>>

Re: Django 2.2 and the watchman reloader

Hey Claude, Thanks for your feedback on the feature, I fully agree with you. I think we should remove that warning message about the missing package. I will make a PR to do that. Regarding creating another reloader: it should not be that difficult to do at all since we have all the other pieces

  1   2   3   >