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
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'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 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
> 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
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():
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
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
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
11 matches
Mail list logo