I'd like to solve this with a way to add methods to QuerySets. This would be useful for those who want get_or_none() or other similar shortcut methods which Django doesn't provide. But more importantly this would let third party apps to provide queryset methods.

If this was possible, then one could do something like this:

@register_qs_method
def get_or_none(self, *args, **kwargs):
    try:
         return self.get(*args, **kwargs)
    except ObjectDoesNotExist:
         return None

I don't know how ugly the magic needed for this would be. Quickly thinking the @register_qs_method doesn't need to do much else than assignment to QuerySet.__dict__. How to add the same method to dynamically created managers might be harder.

 - Anssi

On 03/26/2014 01:40 AM, Russell Keith-Magee wrote:

On Thu, Mar 20, 2014 at 9:31 PM, Florian Apolloner <f.apollo...@gmail.com <mailto:f.apollo...@gmail.com>> wrote:

    On Thursday, March 20, 2014 2:01:25 PM UTC+1, Cal Leeming
    [Simplicity Media Ltd] wrote:

        I'll give it a couple more days for a BDFL to gives the thumbs
        up/down.


    Well, we don't have BDFLs anymore and Shai already said he is -0
    on it, count me in with a relatively strong -0 too. I'd be a bit
    more open to it if you could a better name. That said I generally
    agree with Shai about the validation, eg this should be handled by
    the database constraints already -- otherwise selecting via get
    doesn't make much sense imo.

Count me as a -0 as well. I simply don't see the problem with catching exceptions. Changing the name doesn't modify my objections.

I'm probably a true neutral 0 on a django.shortcuts method mirroring get_object_or_404 (which, BTW, is what the way-back-in-2007 thread was proposing). I still don't see the point, but at least it's in a shortcuts module, and clearly labelled as such, not a method on a manager duplicating existing functionality.

Yours,
Russ Magee %-)

--
You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com <mailto:django-developers+unsubscr...@googlegroups.com>. To post to this group, send email to django-developers@googlegroups.com <mailto:django-developers@googlegroups.com>.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84_rYfpfSGicAKFDrLdtTKW9q1tr%2BM03xXx_qRCi4usTEw%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CAJxq84_rYfpfSGicAKFDrLdtTKW9q1tr%2BM03xXx_qRCi4usTEw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/53328F22.7000606%40thl.fi.
For more options, visit https://groups.google.com/d/optout.

Reply via email to