Re: Ideas for a new DEP on long-term Django API compatibility

[Dave Burkholder]

> I love where Django is headed. I love all of those breaking changes that 
have to happen so we're not perpetually stuck with decisions from 2005.

+100 to this!!

Django user since 1.6 running on python2.6. Upgraded to 1.7 and python3.4 
at the same time, and _that_ migration was hard. Everything since then has 
been a cakewalk. 

Mega-props to the caretakers of Django. Carry on...!



On Monday, August 19, 2019 at 11:51:33 AM UTC-4, Patryk Zawadzki wrote:
>
> As someone who has spent over 12 years working with Django, I'd like to 
> offer an opposite point of view:
>
> I love where Django is headed. I love all of those breaking changes that 
> have to happen so we're not perpetually stuck with decisions from 2005.
>
> What I truly miss is strong static typing support that would tell that 
> when my code is not going to work before I even begin to test it. With 
> static types and tools like mypy and pyright upgrading dependencies is 
> usually a matter of a single afternoon.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6b6f6b14-c3cc-4ba9-9d77-92ecaab23e11%40googlegroups.com.

Re: Ideas for a new DEP on long-term Django API compatibility

[Pascal Chambon]

Hello,

Just for the record, we spent a good time discussion this change (to bring
> inheritance of Admin Actions in line with Python’s expected inheritance
> rules). We reviewed the entire history of the feature. We explored an
> alternative approach, which would have maintained BC. We put the discussion
> to the mailing list, where further people reviewed it, and we came to a
> decision, as a group, without any objections being raised.


That's good and reassuring news; if so, that's precisely another occurrence
of "those reasons really need to be very good, and spelled out and
explained". Most Django users will never see farther than the release
notes, so if abrupt in-places changes occur without a rationale behind, it
*appears* reckless (whetever really happened in the background). If release
notes are considered too long already, wouldn't html tooltips/collapsibles
be useful, so that one may know more about the rational behind changes?

Tech debt is a very real thing.  Keeping it under control is vital to the
> pace of improvement and updates for any project, large, middling or small.
> Any project requires maintanence at minimum, just like owning a car or
> house.  If you buy a car and run it every day for five years, only filling
> up the gas tank and adding a splash of oil now and then,  you don't have
> any excuse to be upset at the mechanic or manufacturer for the size of the
> repair bill when things start breaking.  At least with software, its alot
> easier to get fixes out than with hardware.  You make a persuasive argument
> and have great passion, but the overall goal of enabling out of date and
> unsupported releases to remain around longer than they should be makes me
> feel really uncomfortable.  A spftware project is not buy once and forget,
> neither is a car.  And your package seems to encourage that lax practice to
> a level that I would be highly resistant at working at a company if I
> couldn't persuade management to prioritize keeping up to date and tech debt
> at a manageable level.
>

We agree on the necessity of updating code, and indeed DCP was never meant
to encourage slacking but to solve external dependency conflicts. The
latter - and the additional costs involved in solving them - are precisely
used by management to refrain from upgrading codebases.

As we're getting to the end of useful arguments here, I'd like to ask you
> to step back for a minute and take a calm look at what you're writing.
> Imagine you were receiving such messages rather than sending them. Would
> you want to spend more time collaborating with the person addressing you
> that way and to receive more such messages? Perhaps this is another reason
> why you aren't getting as much support as you'd hope.
>

My initial article, as well as most of this ML discussion, is not small
feature/bugfix request, but a rant on the whole deprecation process. The
aim is to raise awarenesss, to shake minds, to push points as deep as
possible, and to not let any falsehood or diversion slip by. As thus, it
uses all kinds of strong words, of emphases, of rhetorical figures, of
denounciations, to deliver the argumentation. I guess a rant will always
look aggressive, even if it only states the most scientific facts.

So I'm sorry if it sounded insulting, but personally I don't mind facing
adamant insistence, blunt statements, criticisms of any current state of
affairs (whatever the amount of effort one might have put into getting
there), and heated discussions, as long as they don't turn into ad hominem
attacks; in the excepts that you pointed out, I was mainly stating my frank
opinion on the (visibly incomplete) evidence that I was shown, and I would
only have sounded hypocritical by masking the seriousness these issues have
for me. Maybe some feel that Django as already having admirable commitment
regarding API stability, alas some other languages and frameworks have set
the bar much higher (farther than semantic versioning), and *they* are to
be used as references (although too extended compatibility is considered
harmful by some here).

Surely some of my words could have been better chosen ("punishing" shall be
understood as "putting at a disadvantage", and "little version" as "minor
version"), my bad, like some of yours ("throwing your toys" sounds
condescending, though I couldn't care less); but I feel that politeness
euphemisms and tone policing destroy the productiveness of crucial
controversies like this one, instead of helping them. I'd rather be called
names, but not see already-debunked untruths reappear in the conversation
("current behavior [...] *can't be fixed* without a hard compatibility
break", "*always* take the time to create deprecation paths"...); this
intellectual scrambling is what makes *me* stomach-sick, much more than old
unmaintained packages.

For example, Luke was open to amending the deprecation policy to better
> reflect reality. You should have suggested some concrete changes, erring on
> the

Discussing potential QuerySet.subquery interface

['Alexandr Aktsipetrov' via Django developers (Contributions to Django itself)]

Hi,

I've been thinking what is the best way to address #28333
 - it is desirable to be able
to filter by Window expression in ORM. But that requires using subqueries
in sql. The ticket itself proposes doing so implicitly and keeping the
usual filter interface:

qs.annotate(row=Window(expression=RowNumber())).filter(row__gt=1)

But that raises the question - how the expression below should be
interpreted?

qs.annotate(row=Window(expression=RowNumber())).filter(row__gt=1, id__gt=1)

Should id__gt go to the inner or the outer query? More generally, is it OK
for a queryset to be dependent on the order of .filter() calls? I feel this
would be quite surprising. So it's probably better to make this operation
more explicit.

It was suggested by Anssi Kääriäinen in #24462
 to add .subquery() method to
querysets. This seems like yet another use case!

But I tried to implement it, and almost immediately found an ambiguous
case:

 qs.values('id').subquery().filter(other_field=...)

We can't just apply filter to the outer query - it doesn't have other_field
anymore due to values() call. What to do? Reject such an attempt? Apply
values() only to the outer query, not the inner one? Apply filter() to the
inner one (this is probably the most surprising...)? Something else?

No doubt there are many more tricky questions about semantics of such a
method. But I'd like to start this discussion somewhere. :)

So, a few questions:

   1. Do you agree that adding QuerySet.subquery is worthwhile?
   2. Do you agree it is the best way to solve #28333
   ?
   3. How should it behave, in the specific case above or maybe more
   generally?

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAO0xAt4kfZEKnDA38kx%3DujgMV3vrRpoptFAJLu_a1XtmMOUSDw%40mail.gmail.com.

Re: Discussing potential QuerySet.subquery interface

[charettes]

Hello Alexandr,

I agree with Anssi and you that adding a method to perform a subquery 
pushdown would be useful.

FWIW #24462 and #28333 are not the only tickets where that was proposed as 
a solution.
Searching for "subquery" and "pushdown" should bring a few other tickets.

There are also internal cases where the ORM performs automatically (e.g. in 
sql.Query.get_aggregation)
so it might be worth trying to refactor these to use a common 
Query.as_subquery (better name welcome) first.
There's an existing ticket to unify the handling of subqueries[0] that 
should be a good introduction to the
changes require to add this method[0].

Regarding 3. I think we should simple raise a FieldError in this particular 
case to require other_field to
be included in the .values(). We've tried automatically selecting fields in 
the past when they were missing
and it lead to unexpected behavior[1]. Since this would be a new API we'd 
have the luxury on being really
strict on supported use case at first at lax the requirements later on if 
we deem it appropriate.

I would assume a .subquery() that isn't preceded by a .values() would 
result in a SELECT * FROM (...)?

Cheers,
Simon

[0] https://code.djangoproject.com/ticket/20127
[1] https://code.djangoproject.com/ticket/14357

Le mardi 20 août 2019 14:08:03 UTC-4, Alexandr Aktsipetrov a écrit :
>
> Hi,
>
> I've been thinking what is the best way to address #28333 
>  - it is desirable to be 
> able to filter by Window expression in ORM. But that requires using 
> subqueries in sql. The ticket itself proposes doing so implicitly and 
> keeping the usual filter interface:
>
> qs.annotate(row=Window(expression=RowNumber())).filter(row__gt=1)  
>
> But that raises the question - how the expression below should be 
> interpreted?
>
> qs.annotate(row=Window(expression=RowNumber())).filter(row__gt=1, id__gt=1)  
>
> Should id__gt go to the inner or the outer query? More generally, is it OK 
> for a queryset to be dependent on the order of .filter() calls? I feel this 
> would be quite surprising. So it's probably better to make this operation 
> more explicit.
>
> It was suggested by Anssi Kääriäinen in #24462 
>  to add .subquery() method 
> to querysets. This seems like yet another use case!
>
> But I tried to implement it, and almost immediately found an ambiguous 
> case: 
>
>  qs.values('id').subquery().filter(other_field=...)
>
> We can't just apply filter to the outer query - it doesn't have 
> other_field anymore due to values() call. What to do? Reject such an 
> attempt? Apply values() only to the outer query, not the inner one? Apply 
> filter() to the inner one (this is probably the most surprising...)? 
> Something else?
>
> No doubt there are many more tricky questions about semantics of such a 
> method. But I'd like to start this discussion somewhere. :)
>
> So, a few questions:
>
>1. Do you agree that adding QuerySet.subquery is worthwhile?
>2. Do you agree it is the best way to solve #28333 
>?
>3. How should it behave, in the specific case above or maybe more 
>generally? 
>
> Thanks.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b2a77caa-f5b4-4b33-83af-02da01bec1c9%40googlegroups.com.

Re: Discussing potential QuerySet.subquery interface

['Alexandr Aktsipetrov' via Django developers (Contributions to Django itself)]

Hello Simon,

thanks for the links.

I would assume a .subquery() that isn't preceded by a .values() would
> result in a SELECT * FROM (...)?
>

Maybe from implementation perspective it would be easier to copy all fields
explicitly.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAO0xAt7YPH4sP4rvwiZ%3D4fnDacGkf19Ut1pHH%3DvOa8gN0gXRpQ%40mail.gmail.com.