Malcolm Tredinnick <[EMAIL PROTECTED]>
writes:
> On Fri, 2007-02-09 at 21:14 -0500, David Abrahams wrote:
>> _.foo >= 6 returns an expression tree, an object that represents
>> the comparison of the foo field with 6. This technique is well-known
>> among advanced C++ programmers but has also been seen in the Python
>> world (http://thread.gmane.org/gmane.comp.python.numeric.general/4081,
>> although I've heard of other instances). Here's enough of a sketch to
>> represent the above expression. Obviously you'd need more along the
>> same lines to be able to handle everything:
>
> OK, I'd hadn't made the leap that that was why you were introducing the
> initial '_' and using attribute access. I understand the concept -- just
> the right neurons weren't connected. Thanks for the clarification.
Yerwelcome.
> I'm -1 on this for the reasons Russell mentioned and because it adds
> extra complexity to the queries (you have this bonus "_."
> everywhere).
>From my POV, '__' is a "bonus" and 'gte' is definitely extra
complexity. I have to remember this unholy syntax and try to
understand how it maps onto logic (with this mapping not even
_completely_ defined anywhere except code AFAIK). If that isn't
complexity, I don't know what is. IMO, if you think foo__bar__gte=6
is not complex (especially with the meaning it has) then you've been
using that syntax too long to understand how it looks to a newcomer.
Sorry, I just don't see how this adds any complexity for the user
(except maybe for the very simplest queries, if 3 seems like a large
number and you're counting characters).
> Plus we can't use _
I repeat: I wasn't suggesting the framework supply '_'. I was
suggesting that the framework supply 'field'. In the context where
you want to do queries, you can
from ... import field as _
or, for any xxx you like,
from ... import field as xxx
or just,
from ... import field
and it would still be a vastly more-expressive interface.
> because it's already used by Python's shell and by our i18n
> framework (which is a small problem in itself). Three uses for the
> same variable is right out.
I'd be really, really surprised if there weren't other variable names
that are re-used in three different contexts. :)
--
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
-~----------~----~----~----~------~----~------~--~---
