Just to ping this again (since I think it's super-convenient and don't want it to get lost), I've created ticket 5741 with a patch and doc changes. The patch would look the same for the queryset-refactor branch as it stands now, too.
http://code.djangoproject.com/ticket/5741 Dan On Aug 23, 2:09 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > On 8/22/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > So - I would suggest holding off for a week or two (to let the dust > > settle on the refactor), and then poke this issue again. For the > > record, I think the general idea has merit, we just need to finess > > some details. > > Yeah, we should wait until the query.py refactoring is done, but I'm > +1 on this change. It's a pain to have to wrap things in try/excepts > all of the time. > > Of the options Rob pointed out, I prefer the last -- giving the get() > method an optional "default" parameter, instead of creating new > methods like get_or_default() or get_or_none(). We can easily get > around the fact that it clashes with fields named "default" -- if you > have a field named "default" and want to do an exact lookup, just use > "default__exact" instead of "default". That seems like a reasonable > solution. > > This would be backwards-incompatible for anybody who currently has a > field named "default" and does an exact lookup. But I think that's OK, > as long as we document it and get the word out. > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
