Re: [Django] #13089: Support Negative Indexing on QuerySets
Django
-------------------------------------+-------------------------------------
Reporter: adamnelson | Owner: nobody
Type: Uncategorized | Status: closed
Component: Database layer | Version: master
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: feature | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by a.mamish@…):
* ui_ux: => 0
* type: => Uncategorized
* severity: => Normal
* easy: => 0
Comment:
I think this is more important than many think. It's a Python idiom that
gets lost in translation. You are emulating lists with the sets and their
indexing, it's only natural to support negative indexing as the language
does. It surprised me when I started using Django that this didn't work,
and I was so happy to be able to do that with Python while typing it too!
--
Ticket URL: <https://code.djangoproject.com/ticket/13089#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: adamnelson | Owner: nobody
Type: Uncategorized | Status: closed
Component: Database layer | Version: master
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: feature | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by anonymous):
bump
--
Ticket URL: <https://code.djangoproject.com/ticket/13089#comment:6>
Django
-------------------------------------+-------------------------------------
Reporter: adamnelson | Owner: nobody
Type: Uncategorized | Status: closed
Component: Database layer | Version: master
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: feature | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by anonymous):
Is there any justification for the design decision? I don't really see how
halfway supporting indexing (unless there's some good DB-related reason
for it) is good design.
--
Ticket URL: <https://code.djangoproject.com/ticket/13089#comment:7>
Django
-------------------------------------+-------------------------------------
Reporter: adamnelson | Owner: nobody
Type: Uncategorized | Status: closed
Component: Database layer | Version: master
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: feature | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by loic84):
FWIW I'm +1 on this.
I don't like when we stop halfway when emulating a python idiom; either we
use our own unrelated API or we comply with the basic expectations that
come with the idiom.
In any case, if you care about this, you need to post to the ML; closed
tickets receive very little attention so they aren't a good place to
debate this kind of decisions.
--
Ticket URL: <https://code.djangoproject.com/ticket/13089#comment:8>
Django
-------------------------------------+-------------------------------------
Reporter: adamnelson | Owner: nobody
Type: Uncategorized | Status: closed
Component: Database layer | Version: master
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: feature | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by django@…):
Replying to [comment:8 loic84]:
> FWIW I'm +1 on this.
>
> I don't like when we stop halfway when emulating a python idiom; either
we use our own unrelated API or we comply with the basic expectations that
come with the idiom.
>
In short: querysets are not == lists.
The problem with saying the python negative indexing idiom should be
supported is that negative indexing applies nicely to sets, lists, dicts
etc where you know the length of the set, list, dict etc.
AFAIK, you can't negative index a generator without first exhausting the
generator ... that would be a similar (but not identical) analogy to
negative indexing a queryset (ie you have to retrieve the whole queryset
before you can know the size).
I realise that the ORM could invert the sort and then re-write the slice
for you.
--
Ticket URL: <https://code.djangoproject.com/ticket/13089#comment:9>
Django
-------------------------------------+-------------------------------------
Reporter: adamnelson | Owner: nobody
Type: Uncategorized | Status: closed
Component: Database layer | Version: master
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: feature | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by loic84):
Replying to [comment:9 django@…]:
> AFAIK, you can't negative index a generator without first exhausting the
generator ... that would be a similar (but not identical) analogy to
negative indexing a queryset (ie you have to retrieve the whole queryset
before you can know the size).
Negative indexing could be implemented without performance issues, just
look at the implementation of `QuerySet.__getitem__()`.
The fancy slicing operations like `[::2]` which don't translate well to
SQL are the real problem, I don't think we need to support those.
--
Ticket URL: <https://code.djangoproject.com/ticket/13089#comment:10>
Django
-------------------------------------+-------------------------------------
Reporter: adamnelson | Owner: nobody
Type: Uncategorized | Status: closed
Component: Database layer | Version: master
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: feature | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: loic@… (added)
* has_patch: 0 => 1
Comment:
POC https://github.com/loic/django/compare/ticket13089
--
Ticket URL: <https://code.djangoproject.com/ticket/13089#comment:11>
Django
-------------------------------------+-------------------------------------
Reporter: adamnelson | Owner: nobody
Type: Uncategorized | Status: closed
Component: Database layer | Version: master
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: feature | Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by anonymous):
+1
violates principle of least surprise
--
Ticket URL: <https://code.djangoproject.com/ticket/13089#comment:12>
Django
-------------------------------------+-------------------------------------
Reporter: adamnelson | Owner: nobody
Type: Uncategorized | Status: closed
Component: Database layer | Version: master
(models, ORM) |
Keywords: feature | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by yscumc):
+1
I was surprised by this and had to use `qs[len(qs)-1]` as a workaround.
--
Ticket URL: <https://code.djangoproject.com/ticket/13089#comment:13>
Django
-------------------------------------+-------------------------------------
Type: Uncategorized | Status: closed
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: feature | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Florian Verdet):
It's even more surprising for {{{values_list()}}} -- especially for
{{{values_list( 'field', flat=True)}}}, since it has {{{list}}} in its
name...
--
Ticket URL: <https://code.djangoproject.com/ticket/13089#comment:14>
Django
-------------------------------------+-------------------------------------
Reporter: Adam Nelson | Owner: nobody
Type: Uncategorized | Status: closed
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: feature | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Daniel Hahler):
Just for reference: it was discussed on the mailing list at
https://groups.google.com/d/msg/django-
developers/x86iWFnZiik/wyeI5woWkVYJ.
--
Ticket URL: <https://code.djangoproject.com/ticket/13089#comment:15>