On Sep 7, 10:12 am, Bruno Desthuilliers <bruno. 42.desthuilli...@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! -- http://mail.python.org/mailman/listinfo/python-list
