"Russell Keith-Magee"
<[EMAIL PROTECTED]> writes:
> On 2/10/07, David Abrahams <[EMAIL PROTECTED]> wrote:
>>
>> Use natural operators for filtering, excluding, and attribute
>> access.
>
>> How about it?
>
> Some immediate problems:
>
> - Your syntax works for < > <= >= and ==; but what about all the other
> Django query operators? How do you come up with a clean representation
> for startswith?
Easy. I showed at least one such example already, which I refine below:
Entry.objects.filter(
_.headline.startswith('What')
^^^^^^^^^^^^^^^^^^^
, _.pub_date<datetime.now()
, _.pub_date>=datetime(2005, 1, 1))
> istartswith?
Entry.objects.filter(_.headline.istartswith=='will')
> range?
Entry.objects.filter(_.pub_date.range(start_date, end_date))
or
Entry.objects.filter(_.pub_date.range==(start_date, end_date))
or
Entry.objects.filter(_.pub_date >= start_date & _.pub_date < end_date)
Yes, because evaluation is lazy the latter can be made just as
efficient as if 'range' were used explicitly.
> month?
Entry.objects.filter(_.pub_date.month==12)
> - I'm not a huge fan of the _. syntax.
Read my examples again:
# use something else if you don't like _
from django.models import field as _
^^^^^^^^^^^^^^^^^
'_' is not imposed by the library; if you don't like it, just use the
library supplied object 'field', or any other identifier you find
appropriate:
Entry.objects.filter(field.pub_date.month==12)
^^^^^
> Leaving aside the clash with the existing usage of _ as a shortcut
> for the i18n gettext function,
It's not a clash; that's what namespaces are for. I sure hope that no
one module could reserve a one-character name for use in all other
modules. Certainly '_' is too useful in various contexts to reserve
it for i18n.
If you're really determined to have both available as globals in an
entire module, you could make your own '_' that accomodates both
functions, since I'm not using the _(...) syntax.
> I don't see how the degenerate case
> of filter(name=value) is improved by making it filter(_.name=value)?
Actually
filter(_.name==value)
^^
First of all, the syntax leaves room for backward compatibility, so if
you want to keep writing
filter(name=value)
you can. The big advantage to my suggestion for the really simple
cases is just that it's consistent with a syntax that makes sense even
for the more complicated ones. It's also more consistent with Python,
where '=' is not an equality operator.
> - We've had this discussion before, about a year ago, when we were
> doing the magic removal branch. Check the django-dev archives. There
> are a lot of blog posts around that time talking about 'reinventing
> SQL'. The consensus at the end was that there is a lot of Django code
> out there that is using the existing syntax, and
Like I said, you can preserve backward compatibility.
> the existing syntax works, so there isn't a great need to change it.
It didn't, and doesn't, work for me. Let me repeat and clarify the
reasons to add this extension:
* less arcane
* much less error-prone, because
- python constrains the syntax to something reasonable
- the syntax for the query uses familiar Python operators in
familiar ways
* much easier give good error messages when the user does make a
mistake (because you don't have to parse a misspelled string
and guess what the user really meant).
* terser for all but the most trivial queries
* much more expressive
>From my point of view the gain in expressiveness is 100% worth it and
if I have to do any more serious model manipulation with Django and
it's not implemented yet, I'll do it myself. Expressive interfaces
lead to code that is more often correct the first time and easier to
read and maintain.
Let me also point out that if "the existing syntax works so there
isn't a great need" had been followed from the beginning, Django
wouldn't exist. The core benefit of Django is that it is easy to
express your intentions simply and clearly. To the degree that's
true, it's possible to develop sites quickly. In other words, rapid
development and all the other benefits of django follow from
expressiveness.
> - We are just starting a v1.0 push, so massively changing the query
> syntax really isn't on the cards.
OK. Well, it's easy enough to build a non-intrusive extension that
allows:
objects(Entry).filter(_.pub_date.month==12)
which is nearly as expressive. However, it is not as easy for such an
extension to give good error messages, so there are reasons to build
the functionality into the django core.
> In short - thanks for your contribution, but I don't think you're
> going to get much traction with this idea.
:) I've heard (and overcome) that before
> However, you have obviously been bitten by a bad error message - I
> would suggest that a good course of action would be to raise a ticket
> with your specific example so that the error reporting of that part of
> the query engine can be fixed up.
Done.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
