The Samurai Principle

Phlip phlip2005 at gmail.com
Tue Sep 7 13:20:35 EDT 2010


On Sep 7, 10:12 am, Bruno Desthuilliers <bruno.
42.desthuilli... at websiteburo.invalid> wrote:
> Phlip a écrit :
>
> > Back to the topic, I tend to do this:
>
> >   for record in Model.objects.filter(pk=42):
> >      return record
>
> >   return sentinel
>
> WTF alert here...

I don't see how anyone could WTF that. Are you pretending to be a newb
who doesn't understanding it? F'em.

> > Having lots of short methods helps, because return provides both
> > control-flow and a result value. But it abuses 'for' to mean 'if'. I
> > feel _reeeeally_ guilty about that!
> > But I miss this, from (cough) RoR:
>
> >   record = Model.find(42) || sentinel
>
> > Django should provide this:
>
> >   record = Model.objects.get(pk=42, _if_does_not_exist=sentinel)
>
> queryset.get can be used with multiple conditions - it's not necessarily
>   restricted to pk lookups. However you name your "_if_does_not_exist"
> kwarg, it will be difficult to garantee that there will never be no
> nameclash with any possible valid model lookup argument...

it can also be another method - .if_does_not_exist(sentinel). With a
less sucky name.

I would guess that Django provides some basic rules for avoiding name
collisions. Nobody should call a field "pk__in", but if they do, they
are screwed! But that's not important right now.

> But if you feel like you found the correct name, you can of course
> monkeypatch queryset !-)

K now I gotta learn to add a new method to an existing class!



More information about the Python-list mailing list