Well, I think this kind of feature is in the same category of my request: https://groups.google.com/forum/#!topic/django-developers/N6xazCaJC_E. I haven’t received so many feedbacks though.
It’s all about writing less code to reach the goal. I belive too much abstraction is not a good thing for a framework, but in common cases, like link the above, I think it’s ok. I agree with some guys here, in the case of #get_or_none, manager#first almost always fit the role. So, I’m neutral in regard of that. — []’s Paulo Poiati blog.paulopoiati.com On March 26, 2014 at 12:24:21 PM, Wim Feijen ([email protected]) wrote: Hi Cal, When we proposed to add get_or_none() , we actually ended up adding a first() -method. The primary motives were to have a clearer name and to stay in line with other existing api's. In my opinion, get_or_none is too much a duplicate of first and I am therefore -1 of it being added. For those interested, I will copy the message of BDFL Jacob here: Hi! After thinking a bit, I'm +1 on the idea, and I think `Queryset.first()` is the right name (which implies we should probably have a `last()` for completion). This mirrors the name used by a few other ORM/collection APIs that I think have really nice APIS: * SQLalchemy (http://docs.sqlalchemy.org/en/rel_0_7/orm/query.html#sqlalchemy.orm.query.Query.first) * Storm (http://people.canonical.com/~therve/storm/storm.store.ResultSet.html#first) * Backbone (http://backbonejs.org/#Collection-Underscore-Methods / http://documentcloud.github.com/underscore/#first) If someone produces a patch I'll review it and commit it. Jacob This was written as a response to Anssi's message: For the record, I still do like this idea, specifically .get_or_none(). It seems there is significant support for this idea. I do think this method is Pythonic. There are cases where no match from get() isn't exceptional, and in such cases try-except just feels wrong. The counter argument is that this is API bloat, and this will set an example for more API bloat. In the end this is a decision with almost no technical considerations and a lot of "good taste" considerations. So, this seems like BDFL area. If there are no signs from BDFL that .get_or_none() is acceptable, then lets bury this one. If it is acceptable, then I am willing to do all the work to get this committed. - Anssi The whole thread is here: https://groups.google.com/forum/#!searchin/django-developers/get_or_none$20jacob$20first/django-developers/3RwDxWKPZ_A/KNzxgP8L-V0J Regards, Wim On Wednesday, 26 March 2014 13:19:47 UTC+1, Cal Leeming [Simplicity Media Ltd] wrote: On Tue, Mar 25, 2014 at 11:40 PM, Russell Keith-Magee <[email protected]> wrote: On Thu, Mar 20, 2014 at 9:31 PM, Florian Apolloner <[email protected]> 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. Then why did first() [1] get added? The only difference is that first() adds a reference to [0], but it still saves the equal amount of code and is still there for the same reasons of convenience, no? [1] https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.query.QuerySet.first 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 [email protected]. To post to this group, send email to [email protected]. 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. 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 [email protected]. To post to this group, send email to [email protected]. 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/1ef75fc6-90c2-4d70-9aa0-d2c1cac25c49%40googlegroups.com. 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 [email protected]. To post to this group, send email to [email protected]. 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/etPan.533312bc.737b8ddc.c6%40Paulos-iMac.local. For more options, visit https://groups.google.com/d/optout.
