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

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 most

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 diff

Re: Deprecate HttpRequest.is_ajax

gt; practice should be documented 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: D

Re: Deprecate HttpRequest.is_ajax

explicitly, by using a dedicated endpoint 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.

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

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

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

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

assword_hash from Werkzeug raises 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 y

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 wort

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 W

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

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 to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

ed to consider the time it 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. >

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

to on >>> disk seems way too overkill 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&

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 back

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 auto-ge

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 G

Re: Google Groups contingency plan

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

Re: Google Groups contingency plan

l, but there is a script here: > https://geek.co.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 &g

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 minefield

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

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 querys

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 `

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 AutoFi

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

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

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

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

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 an

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

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. https://django-postgres-extra.readthedocs.

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 g

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

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

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 mig

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

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 m

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 w

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 c

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 depen

Re: Integrating migrations with the check framework

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

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 than

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

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 featu

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: Snowflake db backend

show some >> adoption, it could then be argued that 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/fundra

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

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 202

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

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

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.

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

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

Re: Admin list view counting

This is a great idea. A related issue I've come across with the paginator is not being able to pass an explicit count into it. If you have a query set with expensive annotations that don't effect the count in any way it's very wasteful to include them in the count SQL statement (on top of general

Re: Admin list view counting

> the > user to specify the number of objects) would solve a whole lot of the rest > of > the problem. > > On Monday 07 August 2017 15:03:15 Tom Forbes wrote: > > This is a great idea. A related issue I've come across with the paginator > > is not being able to pass

Re: Django 2.0 Python version support (Python 3.6+ only?)

One of the biggest gains would be allowing third party packages to begin to add type hints, if we support 3.4 this won't happen for a while at least. Other gains, for Django and third party packages include: - code improvements using unpacking generalizations - speed improvements with OrderedDict

Re: Automatic prefetching in querysets

Exploding query counts are definitely a pain point in Django, anything to improve that is definitely worth considering. They have been a problem in all Django projects I have seen. However I think the correct solution is for developers to correctly add select/prefetch calls. There is no general so

Re: Automatic prefetching in querysets

Some quicker changes that have been brought up here could be implemented in the interim, like adding intelligent warnings. Someone brought up a great point about how the ORM hides most SQL terminology from the user, but still requires the knowledge of the difference between prefetch and select rel

Optimizing out unused annotations from count queries

Hello, I think there is potential room for improvement with how Django handles count() queries, specifically relating to annotations. Currently any annotations that are added to a queryset are included in the SQL statement that is generated in the count() query, including all joins and SQL function

Re: Optimizing out unused annotations from count queries

may be available with stricter rules (such as join types), but we could look at doing that separately if it was difficult. On Sunday, 20 August 2017 03:11:13 UTC+10, Tom Forbes wrote: > > Hello, > I think there is potential room for improvement with how Django handles > count() querie

Re: Optimizing out unused annotations from count queries

> Interestingly enough, just doing a .filter(m2m_relation__foo='bar') might change the results Is that not because it's a filter? Would ". annotate(x=F('m2m_relation__foo'))" change the results in any way? Sorry if I'm not following. On 21 Aug 2017 06:58, "Anssi Kääriäinen" wrote: On Sunday,

Re: Add support for multiple file fields

(I wrote a reply earlier and sent it, but it appears to have disappeared into /dev/null. Apologies if it comes through at some later date.) It seems adding a multiple kwarg and retrofitting it onto the existing FileField might not be the best idea. It might cause confusion with existing FileField

Re: Having a MongoDB connector for Django

JSON support in postgres is a great middle ground for storing unstructured documents. I don't know the specifics of your application, but I would be surprised if a document orientated database is a perfect fit. The majority of such apps are semi-structured, where you have some relations but also s

Re: Having a MongoDB connector for Django

You're right for pointing out that some elements of a relational database can be emulated in a non relational one, like Mongodb. The in-python joins sound s bit scary though. However I would argue that if you find yourself needing such things your data is relational, and therefore a relational dat

Re: ConnectionResetError in test_closes_connection_without_content_length

I added this test for the keep-alive release blocker. It's possible that the exceptions raised in that test vary by OS at least on 3.4, the docs suggest that it should throw BadStatusLine instead. ConnectionResetError is also a correct exception to raise in that specific case, we should just add t

Re: New Feature: Allow password reset token to expire in under a day

I think we shouldn't shoe-horn a timedelta into the existing setting, so my vote is with the second option, but I think a timedelta is much more readable than just an integer. Also, the existing 3 day timeout for password links is quite surprising from a security point of view. The consultants I w

Re: There should be a way to make Templates substitution to raise an exception on error

You could perhaps emulate something like that with a template tag, couldn't you? @register.simple_tag(takes_context=True) def requires(context, *names): for name in names: if name not in context: raise RuntimeError('{0} is not in the template context'.format(name)) And in

Re: There should be a way to make Templates substitution to raise an exception on error

You could perhaps emulate that with a template tag, it seems it would be best if this was kept in the template rather than in some associated Python file: @register.simple_tag(takes_context=True) def requires(context, *names): for name in names: if name not in context: rais

Re: New Feature: Allow password reset token to expire in under a day

RESET_TIMEOUT_DAYS and allow floats? Then >>>> you can just do 1/24 for an hour. >>>> >>>> On 21 September 2017 at 09:50, Eddy C wrote: >>>> >>>>> I think Minute, with default value 30 or 60, is the best unit for this >>>>&g

Re: New Feature: Allow password reset token to expire in under a day

It also seems odd to express it as seconds, it's often going to be a large value between an hour and several days and the lowest resolution for the value anyone would need is minutes. On 22 Sep 2017 01:29, "Tom Forbes" wrote: > I would still vote for a timedelta, im not

Re: CONTRIBUTION TO DJANGO

Hey Heba, For a few popular packages on Github it could be as simple as making a merge request and changing their tox.ini or travis.yml file. Once the django 2.0 alpha is published on PyPi (sometime very soon) you could make a merge request to run the projects tests with the alpha, and inspect the

Re: Templates: __html__ method support

The problem with something more complex like yaml or json is it's not easy to combine the output. If those methods return a string, as in actual json, it's not easy to do anything with them (like combine them into an array or another object). YAML is also whitespace sensitive. If they return a dict

Re: bulk_create on Postgresql: on conflict do nothing / post_save signal

I've been in similar situations before, you can usually get away with using a single query to fetch existing records and only pass data that doesn't exist to bulk_create. This works great for a single identity column, but if you have multiple it gets messy. It seems all supported databases offer a

Refactoring the autoreloader

Hello, I've been thinking on and off about how to improve the autoreloader implementation and I wanted to gather some feedback on potential solutions. For some background, Django uses a fairly basic autoreload implementation that simply polls the last modified time for loaded Python files once a s

Re: WOULD LIKE TO CONTRIBUTE TO DJANGO

Your idea about ignoring conflicts in bulk_create is a great idea, i've made a merge request that attempts to implements this. If anyone has any time to review it it would be much appreciated. I couldn't find a very elegant way of adding it though - Sqlite and mysql need something added just after

Re: Refactoring the autoreloader

or delegating the polling to watchdog. [1] https://www.vagrantup.com/docs/synced-folders/nfs.html [2] https://pythonhosted.org/watchdog/api.html#module-watchdog. observers.polling Cheers, François On 09/29/2017 12:03 PM, Tom Forbes wrote: > Hello, > I've been thinking on and off a

Re: django project avoid reload page where work algorithm

This is the mailing list for the development of Django itself, I would post this to the Django users mailing list instead if you want any answers to your question. It sounds like an ideal use case for celery though. On 8 Oct 2017 01:41, "Xristos Xristoou" wrote: I have a website where the user

Re: Database agnostic EnumField

There is a maybe/someday ticket for this here: https://code.djangoproject. com/ticket/24342 If your interested you could work on adding this into Django through that ticket, it seems like an interesting idea. When removing an enum value, how do you handle existing records? Are all supported datab

RE: models.CalculatedField feature

SQLAlchemy has this, through a feature called Hybrid Attributes: http://docs.sqlalchemy.org/en/latest/orm/extensions/hybrid.html Every Django project i've worked on has had to tackle this problem, often poorly. You usually end up with an instance method and a kind of duplicate manager method, or s

Re: models.CalculatedField feature

I think without client-side Python execution of these functions it greatly limits the use of this feature. In the cases I've seen you have a bunch of `qs.filter(age__gt=18)` scattered around everywhere and a separate `can_drink` function of property. Without the `can_drink` function returning the c

Re: Refactoring the autoreloader

ajor overhaul, we'll have to think carefully about how >> the behavior changes and possible backwards incompatibilities. That said, >> the autoreloader is a dev tool. Changing it isn't going to break anyone's >> production. This makes the big-bang approach viable. &g

Re: ease patching Django object behavior in another django packages

I think Tim’s assessment in the ticket is on point, a DjangoObjectBuilder would look very strange and out of place if included (it’s not particularly pythonic either). Seems like there might be a legitimate issue here (or maybe just bad designs in OpenStack?), but unless I’m misunderstanding somet

  1   2   3   >