Re: Easy Pickings: support robust on_commit handlers

Apologies for some reason I didn't get any replies to my inbox! If you'd like to tag me on any WIP PRs I'm willing to lend a hand and test. On Thursday, 7 April 2022 at 22:19:44 UTC+10 revan...@almabase.com wrote: > > Hi Josh, > > I am also interested to work on this ticket. I am also aware of

Easy Pickings: support robust on_commit handlers

I've just created a ticket for supporting robust on_commit handlers that I think might be a good first ticket for somebody looking to get into contributing to Django. https://code.djangoproject.com/ticket/33616 I'd be more than happy to review any patch and provide guidance if required. It's

Re: [TB] Proposal to add Florian Apolloner to Releasers team.

Sorry to hijack, but maybe something to think about next time - but considering the 2 fellows cover the release process quite well already, would it be worth considering a "junior" releaser as a third? Someone to be mentored via pairing that would help encourage either new contributors OR keep

Re: Proposal to add attribute 'step' to FloatField and DecimalField

Just to clarify - you're talking about form fields rather than model fields, right? I can see the argument for form fields but not for model fields. Is there a better API we can think of for customising widgets from the field constructor that could then be passed through? As a rough example:

Re: Idea for Rollback Migration Rules

I run into the problem you're trying to solve often and it's quite frustrating. I don't think storing the migration text in the database is the right solution - I don't know why, but it just *feels* wrong. Such a rollback would only support SQL based migrations - any RunPython migration

Re: Overriding template blocks without copy/pasting entire template files

/#overriding-vs-replacing-an-admin-template seems to suggest this was always possible, so I'm quite confused. On Tuesday, 16 June 2020 15:54:11 UTC+10, Josh Smeaton wrote: > > Changed 5 years ago > <https://code.djangoproject.com/timeline?from=2015-04-22T17%3A28%3A19-05%3A00=second> >

Re: Overriding template blocks without copy/pasting entire template files

> django-overextends as the influence. > > > Kind Regards, > > Carlton > > > > On Tuesday, 16 June 2020 07:03:53 UTC+2, Josh Smeaton wrote: >> >> Something that has bugged me for awhile is the requirement to copy and >> paste an entire template whe

Overriding template blocks without copy/pasting entire template files

Something that has bugged me for awhile is the requirement to copy and paste an entire template when you would just like to override a single block. This arises mostly when overriding admin templates, like `admin/base.html`. In my ideal world, I'd be able to do something like this: #

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

I agree that "dangerously" doesn't and shouldn't be in the name - it's unnecessarily verbose. I think a name like "no_escape" ,or similar, conveys the meaning properly and is no more verbose than mark_safe. On Thursday, 20 February 2020 10:16:12 UTC+11, Kye Russell wrote: > > Personally I

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Johnson wrote: > Sorry I was a bit keen after a reminder of the thread by Josh Smeaton on > reddit. I skimmed again and it felt like there was consensus on some kind > of rename, and it had moved to decision on the name. I guess I'm also sick > of fixing this in client projects :) >

Re: Django 3.0 Release Notes - ASGI

ase. > > Andrew > > On Mon, Oct 14, 2019 at 5:45 PM Josh Smeaton > wrote: > >> A co-worker just linked me to >> https://docs.djangoproject.com/en/dev/releases/3.0/#asgi-support and >> asked me (basically) if we can start doing all kinds of async work in one >>

Re: django-admin startproject settings.py has some security holes

A quick idea from the top of my head, is to change the assignment of SECRET_KEY in the generated settings to something like: SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY", "insecure-") It signals that secrets in the environment are a good idea, that the default generated value is insecure,

Django 3.0 Release Notes - ASGI

A co-worker just linked me to https://docs.djangoproject.com/en/dev/releases/3.0/#asgi-support and asked me (basically) if we can start doing all kinds of async work in one of our projects. Unfortunately, I didn't really know how to answer. Preface: I haven't followed the ASGI plan very

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

available for running >>>> right away. We can make this smaller, for sure, but we can also suggest >>>> people download this beforehand (i.e at their hotel). >>>> >>>> I don’t know how feasible this is but it’s also very easy to run a >>>> ca

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

ts and configuring docker to use a local mirror >> on the network is a one-line change for atendees. >> >> >> >> >> On 4 December 2018 at 23:52:42, Josh Smeaton (josh@gmail.com) wrote: >> >> Size of the image could definitely be a concern, esp

Re: Django LTS support time

I don't think the DSF has the capacity or the will to run a business offering paid support contracts. But nothing is stopping an enterprising individual or company from doing so. All security patches are made public (eventually) and backporting fixes would be fairly low effort.

Re: Creating a new "Triage & Review Team"

I think that's sensible, including making the team public. > This struck me as a little absurd: if we weren't going to dissolve it, Nick should definitely be part of the old "Django Core". It's not done yet, and while we're in this limbo stage, we're potentially missing out on some good

Re: Make Development More Accessible

Mariatta has put together a some PEPs for migrating CPython issues over to GitHub. https://www.python.org/dev/peps/pep-0581/ proposing the migration. https://www.python.org/dev/peps/pep-0588/ migration plan. Django and Cpython are not the same, so there'll be substantial differences. But it's

Re: Redis cache support in core

go_redis.cache.RedisCache` -- > > it's basically the way it works with DB backends, I don't see why it > > wouldn't be a good idea for cache as well. > > > > Ivan. > > > > On Thu, Jun 20, 2019, 04:02 Josh Smeaton > wrote: > > > Celery explicitly

Re: Redis cache support in core

ndency? > Celery, for example, does that: you can just install celery[redis] without > having to figure out what other packages you need to enable redis support. > > Ivan. > > On Wed, Jun 19, 2019 at 6:44 AM Josh Smeaton > wrote: > >> There are already several 3rd

Re: Redis cache support in core

There are already several 3rd party packages that implement redis as a django cache backend, for example https://github.com/niwinz/django-redis We already have a base class for cache backends - and several implementing it (such as memcache). I don't think there's much benefit taking on another

Re: Faster Migrations! But at what cost?

Just to add some stats to the conversation, our largest project has ~90 apps (+3rd party), and 240 migration files. This is after we reset our migration history when migrating from 1.8 -> 1.11 (just over a year ago). We would have had well in excess of 800 migration files at that point. To

Re: Proposal to format Django using black

To answer the question about decision making... Usually a decision is made if there’s reasonable consensus in the discussion or after a vote. If no clear consensus can be reached with the core team, then a decision can be escalated to the technical board for a vote. In the future, if the core

Re: Proposal to format Django using black

Whoops, you are correct. It did not at the time I added black to my projects, my information was quite out of date. Sorry for the wrong correction! On Wed, 24 Apr 2019 at 22:51, Florian Apolloner wrote: > > On Wednesday, April 24, 2019 at 1:25:55 PM UTC+2, Josh Smeaton wrote: >> &

Re: Proposal to format Django using black

Black does not support disabling formatting by block with a comment. It removes all choice except for the upfront choices of length and string normalisation. On Wed, 24 Apr 2019 at 20:22, Rene Fleschenberg wrote: > Hi > > > The arguments against a particular code style will never stop. In this

Re: Proposal to format Django using black

FWIW, I'd be opposed to YAPF at all, but especially over Black. The community (that is, large projects that aren't Django) are standardising around Black - a single unambiguous format style. Having a slightly different format to everybody else I see as backwards. Contributors would also likely

Re: Proposal to format Django using black

ng them? Must be even better for productivity. > > Ivan. > > On Wed, Apr 17, 2019 at 12:35 AM Josh Smeaton > wrote: > >> Ivan, what you’re talking about is subjective code formatting, and lends >> itself to extreme bikeshedding and little consensus. Django already has a

Re: Proposal to format Django using black

Ivan, what you’re talking about is subjective code formatting, and lends itself to extreme bikeshedding and little consensus. Django already has a formatting standard that mergers try to enforce at review and commit time. But it’s time consuming, prone to missing things, and requires lots of back

Re: Proposal to format Django using black

Yes, let’s not discuss the tools choice in quotes, that’s for another place. To provide some information though, black will not convert single quote strings if the string itself contains a double quote. It won’t escape the character, it’ll use single quotes. On Mon, 15 Apr 2019 at 18:48, Kye

Re: Proposal to format Django using black

Agree with Florian that the progressive rollout is more trouble than it's worth. Tangling up feature changes with whole file formatting will make it harder to review changes, but will also be more difficult to use tools like git blame. As for disagreeing with some of Blacks choices - you learn

Re: Filterable subqueries ...

With regard to the stunning silence you're witnessing, it's my guess that you haven't made yourself clear enough in a concise way. The stackoverflow post is large, and doesn't point out what's missing very clearly. What is the SQL you want? What is the SQL you're getting, and what is the

Re: Add an defer=True option for model fields

There is a ticket for this one already, filed 4 years ago by me :) https://code.djangoproject.com/ticket/24096 There are a few options described, but I think `defer=True` was winning out. I don't think we considered an `undefer`, but a `defer(None)` would fix that. Once that API is built, then

Re: Will Django ever CompositePrimaryKeys?

To add - there's definitely appetite for this feature, but it's a difficult one, and no one has stepped up to do it. There are DEP drafts that cover pieces: https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst

Re: Validation of m2m

Considering https://code.djangoproject.com/ticket/12938 is still marked as "open" and https://code.djangoproject.com/ticket/24731 is more or less a duplicate (is there a reason it isn't closed as a dupe specifically?), I don't think any more consensus is really required. The problem seems

Re: Google Summer of Code 2019

If you really think you want to work on a deployment project, you should get the requirements together very quickly, so someone on this list can sanity check that it's something both feasible and useful. I have done a **lot** of different deployments, and other than deploying to heroku, they

Re: Use CDN for djangoproject.com

Cloudflare have many SSL options, including fully encrypted and authenticated comms all the way through (terminate and reconnect). Typically done by having a “hidden” origin domain that also hosts a certificate. I’m unsure if it’s possible to have both origin and front hosting the same name so

Re: Use CDN for djangoproject.com

Why do we not want to use Cloudflare? FWIW I agree that the docs site performance is not great (also from melbourne) - but I'd still suffer the performance hit over going via RTD mirrors for familiarity. On Tuesday, 12 February 2019 18:34:09 UTC+11, Florian Apolloner wrote: > > Especially

Re: include only columns from selected related models in select_related query

Personally, I depend on this behaviour, but it's only because I'm aware of it. Others would be too though, so we can't just make that change (not that you're suggesting that approach). One approach I think could be good would be:

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

For the vast majority of users, right now, Vue or React are the only real options. Let's not try predicting the future, and just focus on what the trends currently are. Users going for newer targets are likely more advanced, and can figure out the necessary changes. Aymerics articles are

Re: Proposal to re-open #27017 (updating only dirty fields in save())

That's a +1 from me. I've certainly hit the bugs you've mentioned before, and I can't think of a good reason not to do dirty field tracking, especially if it were to be opt in. Bikeshedding a little bit, rather than having a global setting, I'd rather see an option on Options/Meta so that opt

Re: Google Summer of Code 2019

Other ideas can be found in the DEPS repo too: https://github.com/django/deps/pulls The only one of those 3 that would be GSOC doable (IMO) would be the query expression language one. On Friday, 25 January 2019 01:43:13 UTC+11, Carlton Gibson wrote: > > Perhaps it's partly the GSoC doesn't

Re: revisiting the Python version support policy

Don't discount being able to use features from newer versions of python within Django itself. https://docs.python.org/3/whatsnew/3.6.html - dicts are more performant - dicts/kwargs/class attributes are ordered (cpython implementation detail for 3.6 - allowing us to consider removing descriptor

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

If we were happy with that particular implementation, then I'd prefer adding it as an official subclass thats importable for users rather than just dumping the code to the docs. But I guess the issue is a slippery slope - how many subclasses do we add for various ModelAdmin use cases. It's

Re: What do you think about unify templates feature?

Are you using https://docs.djangoproject.com/en/2.1/ref/templates/api/#django.template.loaders.cached.Loader in your tests? And you should find a way to test rendering from the command line, which will allow you to get much better timing information. On Friday, 18 January 2019 20:40:29

Re: Widening participation (Thoughts from DjangoCon)

ier to entry which I think we should be aiming towards. If we are > looking to expand the development group and get more people onboard we may > need to shake things up, as the status quo is problematic in that area. > > On 11 December 2018 at 12:04:32, Josh Smeaton (josh.s...@gmail.com >

Re: Widening participation (Thoughts from DjangoCon)

I don't think something like Jira would even be a consideration. The only reason Github issues would be a consideration is if the group thought the onboarding experience (being where users already are with a tool they're already familiar with) would have more value than sticking with with the

Re: A faster paginator for django

I think most people would typically sort/paginate on the primary key field, which still exhibits a linear scan, where the first few pages are fast and the last few pages take significantly longer. Just wanted to call that out in case there were listeners thinking an index solves the problem.

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

es at most. Hopefully this should improve the > experience at sprints, however the current Dockerfile weighs in at 650+mb > so the problem may switch from ‘it is hard to set up an environment’ to ‘it > is hard to download one’! > > > > > On 5 November 2018 at 23:02:30, Josh Sme

Re: TestCase.setUpTestData in-memory data isolation.

Our project also suffers extensively with mutating objects assigned from setUp, preventing us from moving most of our tests to setUpTestData. I'll likely begin using your pypi package right away, thanks Simon! Backward compat issues are probably likely - but they'd be in test cases

Re: Add Python 3.7 support for Django 1.11?

Good merge! Should this also be a policy change, or is it better to maintain a position of "if it's relatively easy and unobtrusive"? On Sunday, 18 November 2018 10:08:43 UTC+11, Tim Graham wrote: > > Okay, I've merged the PR, https://github.com/django/django/pull/10654. > > On Saturday,

Re: Allow querying JSONField with F objects #29769

Hi Mani, No response can mean either the readers here do not have the same problem and have no comment, or your implementation does not require much discussion. In any case, you could continue with the process by proposing a formal patch, and getting someone to review it once it meets the

Re: Remove pyinotify autoreloader support

I ran a slightly modified version of your test code since we have many modules at "top level". "k3" is one of the top level modules that houses a bunch of apps. In total there are about 1340 python files (including recently squashed migrations and tests). Here's the results: Project: 1575

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

I'm sorry I haven't had the time to review or contribute yet, but I think it'll be a very useful project - especially for new contributors that might have a little docker experience. The current vagrant solution is heavy, does not work properly on windows and some linuxes, and isn't that easy

Re: backend specific tests

I don't think there's a full list of extensions the test suite uses, but https://docs.djangoproject.com/en/2.1/ref/contrib/postgres/operations/ would be close to a full set I'd imagine. On Sunday, 4 November 2018 14:43:23 UTC+11, Dan Davis wrote: > > So, the contributor guidelines page about

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

I'm in the same boat as Simon - I've wanted this many times in the last few months, but only when working at the shell. I'd be +1 for get and -1 for filter also. On Thursday, 1 November 2018 05:12:53 UTC+11, charettes wrote: > > As I've mentioned on the ticket I've been wishing get(pk) could

Re: Widening participation (Thoughts from DjangoCon)

I strongly dislike Trac in nearly every way. It's hard to search and the filters are next to useless, and the categorisation features we use are not very useful. I believe the better way to search Trac is to use google and site:code.djangoproject.com which is a red flag itself. On Saturday, 27

Re: QuerySet.iterator together with prefetch_related because of chunk_size

I tend to agree with Tobi. Prefetching silently not working on iterator can be quite confusing, unless you have a good understanding of both APIs. It might be possible to do what you're asking, but it'd mean that django is now actually caching the result when it explicitly says it isn't - even

Re: Jenkins resources

Hi Matt, The django-box project[0] uses very close to the same ansible configuration that is used to configure all of the Jenkins slaves Django uses with the notable omission of an Oracle builder. Since the repos are separate, there has been some divergence on the Jenkins side of things, but

Re: A Django Async Roadmap

I think most of what you've laid out sounds great and that pursuing async Django is in the projects best interests. The sync to async and async to sync wrappers that have come out of channels give me much more confidence that this project is doable in a reasonable amount of time with backwards

Re: Proposal: security enhancements

Most of this sounds really good. As Jacob mentioned, CSP can be quite scary, and sounds like something a novice could try to implement for "good security" and end up causing way more issues. I'd really like to see easy integration for report only mode, with controls that are harder to turn for

Re: #django-dev IRC channel

Yes - that's probably a good idea! On Thursday, 26 April 2018 05:11:33 UTC+10, Kenneth wrote: > > Hello, > > I was just curious about the #django-dev IRC Channel. > Currently, the only mention for this channel is on the Code of Conduct FAQ > page. >

Re: django-firebird test expressions

Have you looked into using Cast for this particular query to see if it passes? https://docs.djangoproject.com/en/2.0/ref/models/database-functions/#cast Cast(RawSQL('%s', ['value']), CharField(max_length=10) ? If that worked, then perhaps you could find a clever way to wrap problem

Re: django-firebird test expressions

It looks correct to me. RawSQL is defining a parameter to be included in the query. The RawSQL expression itself is used in the select and on the left hand side of the WHERE clause, so the parameter needs to be included there. The right hand side of the WHERE clause is a regular string (which

Re: Shouldn't manage.py call python3 instead of python?

As a datapoint, I've seen roughly 1 person per week in #django IRC confused about specific startup exceptions due to them using python 2 rather than python 3 on Django >= 2.0. Unsure how many of these are due to the shebang. That said, it looks like there are no good solutions other than maybe

Re: Shouldn't manage.py call python3 instead of python?

I think you're right and PEP394 is the relevant text: https://www.python.org/dev/peps/pep-0394/ TL;DR For now, *python* should refer to python2 and *python3* should be used to refer to python 3. On Saturday, 7 April 2018 07:07:35 UTC+10, Bobby Mozumder wrote: > > The header of manage.py has:

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

It sounds like you understand what the current behaviour is, and you think that it would be better modelled with Q objects, is that the case? I can see where you're coming from, as even the docs explain the difference loosely in terms of AND and OR. Q(entry__headline__contains='Lennon') &

Re: Gsoc 2018

I'm sorry, but the deadline has already passed for applications. It closed on the 27th of March (2 days ago) according to the GSOC timeline https://developers.google.com/open-source/gsoc/timeline. I do note that Django's own timeline mentions April 3rd being the deadline, but I'm not entirely

Adding custom join support to Django

Someone has again brought up the lack of custom join support in django - specifically LEFT OUTER joins: https://code.djangoproject.com/ticket/29262 I figure it's probably something that we'd like the ORM to support but I don't think we've ever really landed on a design that's palatable. I'd

Re: Gsoc 2018

Hi there, I don't think the rules for Google Summer of Code allow for "projects" to be documentation only. The extra promo materials would also count as documentation I believe. The relevant rule would be 1.26: https://summerofcode.withgoogle.com/rules/ "Project” means an open source coding

Re: Channels - Groups and discovery

ng them > low maintenance, and also in letting people solve > dependency/versioning/schema upgrade issues in the way that fits them best. > > Andrew > > On Sun, Mar 25, 2018 at 4:08 PM, Josh Smeaton <josh.s...@gmail.com > > wrote: > >> I see - some kind

Re: Channels - Groups and discovery

urrent design pattern something > will complain if it's not working right (even though that thing is on the > receiving side not the sending side). > > Andrew > > On Sat, Mar 24, 2018 at 4:31 AM, Josh Smeaton <josh.s...@gmail.com > > wrote: > >> I've finally had the c

Channels - Groups and discovery

I've finally had the chance to use channels for a project (hack day multiplayer game - hope to release and blog about it some time soon), and I wanted to document some of the rough edges I hit and ask some questions about them. Specifically though, I find the mapping of payload.type to a

Re: GSoC 2018

the django project wants, and is not something we'd sponsor as part of GSoC. On Saturday, 17 March 2018 07:48:46 UTC+11, Manasvi Saxena wrote: > > Hello Sir, > > On Saturday, March 17, 2018 at 1:57:00 AM UTC+5:30, Josh Smeaton wrote: >> >> I'm confused by your propos

Re: [RFC]GSoC 2018 Test framework improvement

Hi Billy, This plan sounds more like a plan for a plan. If you're serious about wanting to participate in GSoC, then you need to have **specific** ideas and goals. By this, I mean your proposal should be able to be picked up by anyone and implemented. You're missing any actual feature

Re: GSoC 2018

I'm confused by your proposal. You state one of the drawbacks with current templating is the readability issues for frontend developers that have templating logic defined within the template. But isn't your proposal to replace html templates with one defined in python? How does this make it

Re: Add Alias or annotations without group-by support?

2018 14:01:41 UTC+11, Cristiano Coelho wrote: > > It wouldn't work if you also want to order by the annotated value. > > El viernes, 9 de marzo de 2018, 8:27:36 (UTC-3), Josh Smeaton escribió: >> >> Would teaching filter() and friends to use expressions directly solve >

Re: Add Alias or annotations without group-by support?

Would teaching filter() and friends to use expressions directly solve your issue? You suggested using `alias` upthread, but that's only really required so you can refer to it later? Unless you wanted to refer to the field more than once, having each queryset method respect expressions should

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

:04 PM UTC+1, Josh Smeaton wrote: >> >> Or, since this isn't a template tag (facepalm) >> > > Which raises a perfectly valid point: If we were to change this, we will > also need to come up with a new name for the "|safe"-filter. > -- You received this mes

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

Or, since this isn't a template tag (facepalm) trusted_html(m.content) trust_html(m.content) On Friday, 23 February 2018 07:46:45 UTC+11, Josh Smeaton wrote: > > Yes I'm not a fan of the *dangerously...* names either. I'm still > somewhat wary of *trust_html* which is a *verb* and co

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

vey the gravity of what this actually does. >> However I'm unsure on the `dangerously_trust_html` name. It wouldn't be >> dangerous to trust the literal "Some Content", for example. >> >> Perhaps it could be something a bit more explicit. `no_escape(stri

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018 21:08:31 UTC+11, Florian Apolloner wrote: > > Yeah, I am also worried about the churn for no gain in my eyes. If users > overuse mark_safe, they will overuse dangerously_trust_html too… > > On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote: >> >

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

I agree that the names are misleading and we should probably provide better names. I'm wary of deprecating the old names because it'll create a lot of churn (some of which would be the right thing to do). Maybe we could just alias and warn when using the old name, leaving a decision on

Re: Purpose of constant_time_compare?

I don't doubt that timing attacks can work in practise, but the link you've posted is not this. From the commit message: > There have not been any reports of attempted exploit in the wild. (The vulnerability was discovered through code review.) On Friday, 9 February 2018 09:27:03 UTC+11, Anssi

Re: PR 9583 - Ticket 28643

I think having Left/Right is the right way to go. If there are opportunities to use slicing syntax, then they would resolve internally to those Expressions I would think. But that can be done separately, and have greater scope such as ArrayField in Simons example. On Friday, 19 January 2018

Re: Security middleware for django for insecure (http) connections

HTTPS is enough. Despite that, how would you handle the **client** doing decryption and encryption? I don't think this is an idea you should pursue, especially if your expertise is not in security. On Tuesday, 16 January 2018 10:03:00 UTC+11, Vishwas Mittal wrote: > > Hello everyone, > > I am a

Re: Fellow Report — January 12, 2018

Welcome, and nice work! I've seen some of the reviews you've made and you're straight into the deep end. On Saturday, 13 January 2018 04:01:06 UTC+11, Carlton Gibson wrote: > > Hi all, > > With help from Tim, Aymeric and Frank, I got started on the fellowship > this week. > (Thank you all!) >

Re: Should ModelField.choices accept a callable?

Migrations are mainly for tracking database changes. Model attributes not SQL related are pushed into the migrations also, presumably for the purposes of data migrations (maybe post-hoc justification, only a few people would actually know). Providing a callable still provides access to the

Should ModelField.choices accept a callable?

https://code.djangoproject.com/ticket/22837 was closed as invalid. It concerns itself with migrations being detected when model field choices (which may be dynamic) change. The workaround suggested is to pass a callable to choices with a link to https://code.djangoproject.com/ticket/13181.

Re: Change Local Memory Cache to Use LRU #28977

>> penalty which the LRU-eviction policy will almost certainly improve >> compared with the current random-eviction policy. >> >> Grant >> >> >> On Mon, Jan 8, 2018 at 2:25 PM, Josh Smeaton <josh.s...@gmail.com >> > wrote: >> >>>

Re: Change Local Memory Cache to Use LRU #28977

ck >> >> >> +1 to adding an option to disable the check as well. If you're using a >> LocMemCache in production, you probably don't care about compatibility with >> memcached, because you'll be using it for different types of data. >> >> On 5 January 2018 at

Re: Change Local Memory Cache to Use LRU #28977

To lend some weight to this, I've implemented an LRU loc mem cache and have done some benchmarking. There are some graphs in the readme: https://github.com/kogan/django-lrucache-backend - which I've written a little about

Re: Sealing or locking QuerySets -- a suggestion to prevent surprise N+1 queries.

I wasn't aware of this new feature Shai, thanks for pointing it out! For this particular case I'd prefer locking to be bound to a particular queryset rather than the database as a whole. I would also expect it to fail loudly when accessing a non-fetched related object (book.author), which can

Re: GLOBAL_PERMS

> > > - I dislike the seetings approach of GLOBAL_PERMS and would rather see > users writing explicit data migrations. > I don't favour either setting or migration based perms, but if you're going to go with migration based, then please also consider adding a first class permission type,

Re: Improving Backward Compatibility

the recent releases. > That's one feature per week or fortnight. We'd likely deprecate fewer > features if we had to reach consensus on django-developers every time. > > Best regards, > > -- > Aymeric. > > > > On 7 Dec 2017, at 04:09, Josh Smeaton <josh.smea...

Re: Improving Backward Compatibility

Following on from Collin, another ticket that generated a large amount of code churn for little perceived benefit was https://code.djangoproject.com/ticket/21127 (enforce on_delete). I know there are many in the community that rail against any and all changes (I had an argument with such a

Re: Additional PostgreSQL-specific functions

Hey Joey, I think you can create a new ticket for this function. If there is a way to approximate or implement this function in all 4 supported backends then that would be preferred. If it can only really be implemented in postgres, then document in the ticket why, and you can add the new

Re: Feature request: get_first_or_404

>From my experiences, all projects I've worked on have implemented get_first_or_none and get_first_or_404, and usually slightly differently. I think these shortcuts would make sense for Django. Interested to hear how common the usage would be from others on the list though. -- You received

Re: models.CalculatedField feature

Introducing an `as_python` to the expression API would probably work. It'd involve a lot of work to implement for all supportable expression types. Considering there are many 3rd party / user code expressions in the wild without as_python, we'd need to find a way to fail gracefully. However,

Re: Using server side cursors for values and values_list

I can't think of any reasons why not to do this off the top of my head. Have you looked into the code? Is there any technical reason you can see that might prevent chunked fetching from working there? On Saturday, 18 November 2017 03:27:13 UTC+11, Dražen Odobašić wrote: > > Hi, > > at the

Re: [off topic] Re: models.CalculatedField feature

Re-reading your reply, I think I've misunderstood your intent there (I didn't realise who the author was). Please disregard my previous reply. On Sunday, 19 November 2017 09:59:44 UTC+11, Josh Smeaton wrote: > > Until you want to aggregate or filter on that calculation, and p

  1   2   3   4   >