On Fri, 5 Jun 2020 13:58:47 +0200
Johan Schiff wrote:
> I still think the wrong call was made here [...]
> *(Assuming queryset should be evaluated is probably correct in
> most cases, but sometimes adds a big performance hit when the code
> goes into production and the dataset grows - code that
(You can reopen https://code.djangoproject.com/ticket/24141 rather than
creating a new ticket.)
On Friday, June 5, 2020 at 9:06:48 AM UTC-4, Aymeric Augustin wrote:
>
> If people agree QuerySet.contains() should be added, how do we move
> forward?
>
>
> Yes, if there's no major new argument in
Have you read past discussions on the mailing list?
For example:
Making Django more PaaS-friendly
https://groups.google.com/d/topic/django-developers/BAGhOKXGj4I/discussion
Searching the archives for "12-factor" yields some other results.
That may help you to craft your proposal.
On Friday,
I have, thank you! I tried to do my research before I wrote this email and
this PR, but there's a ton of context to all those conversations that I'm
sure I'd be missing, so I'm never gonna reach the point of feeling
confident that I have a handle on what's gone before, alas.
On Fri, Jun 5, 2020
I'm interested in reducing the distance from running `startproject` to
having a deployable Django app, having recently had a number of
interactions with junior devs interested in using Django but finding
deployment a nightmare. Some of this is of course on the other side, on the
PaaS of choice,
On Tue, 2 Jun 2020 20:57:54 +0200
Aymeric Augustin wrote:
>
> We're talking about a trade-off between preserving optimisations in
> existing code bases and expertise of advanced users versus doing the
> right thing by default for less experienced users.
I disagree.
The suggestion is to make
Enjoy your week off!
El jueves, 4 de junio de 2020, 12:47:57 (UTC+2), Carlton Gibson escribió:
>
> Hi all.
>
> Short answer is we don't really know, since we never take holidays.
>
> I though am having a much needed week off from tomorrow, to be back on the
> 16th.
>
> Mariusz will need
I'm with Shai, against changing bool() and len() behaviour. I think the
"fetch the whole queryset" behaviour is normally helpful for beginners, who
write things like:
if qs:
for x in qs:
...
# really common for anyone new to Python:
for i in len(qs):
do_something(qs[i])
We have
Hi,
I'm thinking, maybe instead of:
if obj in queryset:
Users should write:
if obj in list(queryset):
Which I understand is already working? Why does the first line (without
list()) should work anyway?
And if users want performance, why not write:
if queryset.filter(pk=obj.pk).exists():
> If people agree QuerySet.contains() should be added, how do we move forward?
Yes, if there's no major new argument in a couple days, we can assume consensus
on adding .contains().
* Create a ticket in Trac. Point to this discussion and to the previous ticket
where .contains() was suggested.
Shai does make a good point about changing a well documented behaviour.
That argument wins me over.
Adding .contains() and updating the documentation goes a long way to make
it easier for developers.
Best case would be that Dajngo does not make assumptions about what the
developer wants, but to
11 matches
Mail list logo
