On Sun, 2007-12-02 at 23:28 -0600, Adrian Holovaty wrote:
> On Dec 2, 2007 8:31 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-11-30 at 20:00 -0800, [EMAIL PROTECTED] wrote:
> > > To clarify, code such as the following can be a little confusing:
> > >
> > > p = MyModel.objects.filter(foo__id = self.id).order_by('-timestamp')[:
> > > 1]
> > > if p:
> > > return p[0]
> > >
> > > To a python developer who is unfamiliar with django's magic limiting
> > > syntax, the slice there looks unnecessary.
> > >
> > > Writing objects.filter(...).order_by(...).limit(1) would be clearer
> > > and significantly less error prone.
> >
> > No it wouldn't. It would be differently error-prone.
>
> Frankly, I have found the slicing syntax hard to understand and
> error-prone myself. I think one of the reasons it seems magic is that
> it's one of the *rare* cases in which we use a Python
> "magic-syntax-ism" (like operator overloading, for instance) in the
> framework, plus the fact that, what, *every* other piece of QuerySet
> functionality uses a method. It seems bolted on.
>
> I'd be +1 on adding a distinct limit() method, and keeping the legacy
> list method for masochists who actually enjoy coding in that way.
Adding limit() -- which will also require an offset() method -- is just
as error prone and is less intuitive than the current system (which
conforms to normal Python behaviour). All over the world conversations
such as the following will occur:
Jim:
I want to select the third, fourth and fifth items from
this queryset. What's the best way to do that? I always
forget the syntax.
Jane:
I think you limit() your queryset to five items and then
offset() to the third and it will work. You could also
offset() first to item three and then limit() to three.
Jim:
Really, don't limit() and offset() commute?
Jane:
Well, all the other queryset methods apply
incrementally, so these two should as well, shouldn't
they? In the latter case you first apply the offset,
which restricts the result set and *then* limit it
further. offset(3).limit(5) would give you items three
through seven, wouldn't it?
Jim:
But it's deliberately written as a leaky abstraction of
the SQL extensions called limit and offset. So why
doesn't it behave the same as they do? Maybe that's the
way it works. We're going to have to look it up
again. :-(
I guess it's not possible to have both, so the Django
developers just chose arbitrarily. That sucks... it's
impossible to use logic to understand this. They should
be called chop_first() and interval() then.
Jane:
Yeah, what we really need is a way to specify both at
once. A method that takes the lower and upper bound.
That would remove the ambiguity. Maybe you could leave
out one or the other. We could call it ... *thinks for a
bit* ... __getitem__()!
Jim:
Agreed. We're really taking a subsection of a sequence
here, right? Leaky abstractions aside, Django is
fundamentally presenting a Python view of the data and
only using the database as a persistence mechanism.
Slicing is the normal way to extract sections from
sequences in Python. Wonder why they didn't do that?
Ancient John (older programmer, who's been around the company
for years):
They used to do that. Then Google cut off the oxygen to
the django-developers group and people stopped thinking
clearly. Confusion spread throughout the land.
Apparently the current method is deemed superior because
it keeps people talking to each other and doesn't let
familiarity and standard patterns settle in. It's called
social engineering: you have to be more social to get
stuff done.
This is all very disappointing.
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
