On Thu, Mar 27, 2014 at 1:10 AM, Russell Keith-Magee < [email protected]> wrote:
> > On Wed, Mar 26, 2014 at 8:19 PM, Cal Leeming [Simplicity Media Ltd] < > [email protected]> 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? >> > > first() was primarily added as an analog for latest(). > > Personally, I see a significant difference between first()/latest() and > get_or_none(). > Personally, I would not class this as being significantly different enough to justify get_or_none() being less worthy. > > first()/latest() is a specific, common query that has been optimized: list > all, order by X, give me the first one. > > get_or_none() is a second version of an existing query: get(), but with a > different return value. To me, this is duplication of an API, not a > different query. > I do see where you are coming from with the "duplication of an existing API" argument, though in my personal opinion I would argue it's a common enough use case to justify inclusion. > > In my ideal world, the get(default=None) approach would be what we would > do; but, as others have pointed out, default is a valid column name, so > this option isn't available to us. > I would be a strong -1 on using any keyword argument on the existing .get() to specify the default, whatever the name. > We already have a shortcut for get_object_or_404; a matching > get_object_or_none makes sense to me, and puts the API where it make sense > to me - as a shortcut for someone who is repeating the "catch DoesNotExist" > pattern regularly and wants an easier way. > For me, using shortcuts doesn't feel nice on the eyes at all, and I would continue to use the mixin rather than shortcuts, though this is a difference of opinion in taste. Another alternative would be to add GetOrNoneMixin to the official docs, similar to dictfetchall() [1]. If the argument of "duplication of an existing API" is going to be the nail in the coffin, my next proposal would be for the aforementioned docs patch instead. [1] https://docs.djangoproject.com/en/dev/topics/db/sql/#executing-custom-sql-directly > > 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_281FRq4eJ6mxjBfWREi_50naTg%2B6mcvLBKSozeQwjYw%40mail.gmail.com<https://groups.google.com/d/msgid/django-developers/CAJxq84_281FRq4eJ6mxjBfWREi_50naTg%2B6mcvLBKSozeQwjYw%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 [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/CAHKQagFEo%2Bn-rYdUzwwB5oyXjw04T6f3K4vWLDFysjB5P%3DaTpA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
