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