Re: Modify get_or_create() to use field lookups parameters for values

I don't think this is possible to do generally. What would count__gt=1 or pub_date__month=12 do? On Friday, June 6, 2014 3:50:08 PM UTC-6, Patrick Bregman wrote: > > Hi all, > > First of, I'm new to this list so please tell me if there's something that > can be done better. It's the best way to

Re: Support for function application in ORDER BY

> However, I think having some special case code in filter(), annotate() and anything else that takes expressions would be OK I strongly disagree with this. Expressions are context insensitive at the moment, which means they can be used anywhere. If we start externalising behaviour based on

Re: Proposal: variable argument lists for templatetags, in templates.

On Mon, Jun 9, 2014 at 3:38 PM, Przemek Czerkas wrote: > Hi, > > In this ticket https://code.djangoproject.com/ticket/13956 (Indefinite > args for simpletags and inclusion tags) a support for *args and **kwargs > for simple_tag, inclusion_tag and assignment_tag was added. > >

Re: Support for function application in ORDER BY

On Monday, 9 June 2014 21:28:51 UTC+1, Tim Martin wrote: > > > On Monday, 9 June 2014 20:44:08 UTC+1, Tim Martin wrote: >> >> >> I'll go ahead and try to implement this using __neg__() to invert the >> ordering. >> >> > It's still pretty rough, but there's some code in >

Re: Support for function application in ORDER BY

On Monday, 9 June 2014 20:44:08 UTC+1, Tim Martin wrote: > > > I'll go ahead and try to implement this using __neg__() to invert the > ordering. > > It's still pretty rough, but there's some code in https://github.com/timmartin/django/tree/order_by_expressions that appears to work. In

Re: Support for function application in ORDER BY

oh, nevermind, I misread the syntax spec for the order by clause On Mon, Jun 9, 2014 at 5:07 PM, Michael Manfre wrote: > Each expression must be able to define it's own ordering because order_by > allows you to define a sort based upon multiple expressions. > > > On Mon, Jun

Re: Support for function application in ORDER BY

Each expression must be able to define it's own ordering because order_by allows you to define a sort based upon multiple expressions. On Mon, Jun 9, 2014 at 4:00 PM, Daniel Moisset wrote: > I see everyone trying to put the direction (ascending vs decending) inside >

Re: Support for function application in ORDER BY

I see everyone trying to put the direction (ascending vs decending) inside the expression, while it's actually a property of the ordering clause. Wouldn't it make more sense and avoid ambiguities to do: qs.order_by(..., descending=True) ? Then you can add functions (and even a __neg__ operator

Re: Support for function application in ORDER BY

My concern about the filter(foobar_lt=-F('baz')) issue is that it violates the principle of least surprise: it will be accepted silently and do something that nobody could expect unless they know a bit about the internals. However, I think having some special case code in filter(), annotate()

Re: Support for function application in ORDER BY

The parens definitely would work for __neg__, and as for the output_type problem, it's only an issue when mixing field types - but that can be solved by applying a matching output_type to one of the inner expressions. If a wrapping type isn't needed for neg, I won't introduce one to slightly

Re: Support for function application in ORDER BY

Could we use just F() for this, that is the examples would be: -F(F('field')+F('other')) F(F('field')+5, output_type=IntegerField()) As Marc said in another post plain parentheses should be enough for the first case. - Anssi On 06/09/2014 01:19 PM, Josh Smeaton wrote: If __neg__ is the

Re: Support for function application in ORDER BY

For this example: Model.objects.all().order_by( -Wrap(F('field')+F('other')) ) does just the brackets not work? -(f + g) should do f + g (returning some object) and then negate the result. This doesn't solve your output type issue. If it doesn't python's wrong ;) Marc On 9 June 2014 11:19,

Re: Support for function application in ORDER BY

If __neg__ is the preferred method of applying ordering then I think we should prevent __neg__ from being used in the mathematical sense in the other methods (filter, annotate etc). There hasn't been a need for negating an expression/F() object before, and negation would only work with certain

Re: Support for function application in ORDER BY

Using __neg__ for ordering seems like a good approach to me. I don't like F('-field') that much, if -F('field') works, then F('-field') is duplicate API for the exact same thing. The only problem with -F('field') is that there might be situations where ORDER BY -field ASC gives different

Modify get_or_create() to use field lookups parameters for values

Hi all, First of, I'm new to this list so please tell me if there's something that can be done better. It's the best way to learn for me ;) Recently I've been doing some reworking of an old (think Django 1.1 or 1.2) webapp of mine into the latest and greatest of Django. In the process I

Proposal: variable argument lists for templatetags, in templates.

Hi, In this ticket https://code.djangoproject.com/ticket/13956 (Indefinite args for simpletags and inclusion tags) a support for *args and **kwargs for simple_tag, inclusion_tag and assignment_tag was added. I think that one piece is still missing. How about allowing to pass *args/**kwargs to

Re: Support for function application in ORDER BY

Agreed. It's worth noting that we could have a `Desc` operator for awkward edge cases where __neg__ doesn't work well, and the default implementation of __neg__ just returns Desc(self). I've not completely considered all the possible implications here, just throwing the idea around. On 9 June