Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

I'll drop it. Someone else can chime in if they want. Just to be clear, the work you all do on Django is much appreciated :) Thanks, Dave On Thursday, July 14, 2022 at 6:53:41 PM UTC-5 James Bennett wrote: > On Thu, Jul 14, 2022 at 4:09 PM Dave Gaeddert wrote: > >> Yeah, I hope I'm not coming

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

On Thu, Jul 14, 2022 at 4:09 PM Dave Gaeddert wrote: > Yeah, I hope I'm not coming off as being too pushy, but I'm just curious > why that is. Mariusz or Adam, did what I said about it being *more* than > just an alias for `filter().first()` make sense or am I missing something? > (Different beha

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

> I'm not the first to suggest adding an additional shortcut, e.g. django.shortcuts.get_object_or_none which would work similarly to get_object_or_404 Personally I'm not a fan of it being in "shortcuts". It makes sense to me that the 404 ones are there because they are only useful in a request

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

Hi I believe the main objection is against adding additional API to querysets. get_object_or_404 only converts DoesNotExist into a 404 exception and doesn't handle MultipleObjectsReturned. I'm not the first to suggest adding an additional shortcut, e.g. django.shortcuts.get_object_or_none which w

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

Fair enough. To me, the `get_or_none` behavior with multiple results would still be to raise an exception (so it is just like `get` in that sense). And that’s the reason I personally don’t just see it as a shortcut for `filter().first()` — I have (as I’m sure others have) made the mistake befor

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

I'm also against adding get_or_none(), for the same reasons. Adding a method to shortcut something that can already be done doesn't seem worth it to me. On Sat, Jul 9, 2022 at 1:56 PM Mariusz Felisiak wrote: > I'm against it because it's already easily achievable and it's debatable > how it shou

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

I'm against it because it's already easily achievable and it's debatable how it should behave with many results. IMO any new method would be confusing and in the case of unique filtering `get_or_none(unique_filters)` would be an alias for `.filter(unique_filters).first()`. To me, this is duplic

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

Hey Mariusz, thanks for the link — I found some other threads but not that one. Would you mind saying why you're personally against it (`get_or_none` specifically)? At least how I read that thread, there was more debate about how to add it than whether to add it at all, and then Cal sort of "ga

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

Hi, Adding `get_or_none()` was discussed several times and was always rejected. This thread has a nice summary. Personally, I'm still against it. Best, Mariusz -- You received this message because you are subscr

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

I'm new to this... anybody know how the best way to push this forward? Or who can make a decision on whether something could/should be added to Django? I see some other tickets/discussions about basically the same thing: https://code.djangoproject.com/ticket/17546 A lot has changed in 10+ years.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

> To begin with - thats the place I dont like .get() at all. The fact that > it might end up with multiple objects is a nuisance, but we cannot do > much about it for API compat reasons > ... For what it's worth, I agree with what you're saying here too. Having a `unique_or_none` (and maybe `uniq

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

Well from my own habits to use .get() only for unique filtering (>80% on pks only) I also see some benefit of a .get_or_none() variant - it would stop writing those exception handler wrappers over and over halfway during project realization. A ready-to-go official way would reduce that to a con

RE: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

developers@googlegroups.com [mailto:django-developers@googlegroups.com] On Behalf Of Jörg Breitbart Sent: Friday, June 24, 2022 11:56 AM To: django-developers@googlegroups.com Subject: Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first() @Dave Gaeddert Since you mentioned it - wha

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

@Dave Gaeddert Since you mentioned it - what should a get_or_none method do about multiple objects? Still raise? Silently "cast" to None (imho semantically wrong)? Return the underlying queryset (or any other "multiple objects container thingy")? The problem with .get() is - it may end in 3 d

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

I'll lob in my 2 cents that I actually think `get_or_none` would be great to have, in the same way that I imagine people think `get_or_create` is useful. You can try/catch yourself in both cases (example is basically the exact same https://docs.djangoproject.com/en/4.0/ref/models/querysets/#get

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

I somewhat second what Adrian wrote: - try-except handling seems to be the most idiomatic way to me - a flag altering API behavior as .get(..., raises=False) might come handy, and to avoid naming collisions in arguments this could also be shaped as a separate get_or_none() method - but: I somew

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

I don't like get() and catching exceptions. What I usually do is something like this: foo_list = Foo.objects.filter(x=x) if (len(foo_list) == 1): foo = foo_list[0] And if I need else, I can assign None or whatever. The advantage in this way is that you don't get an exc

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

A common idiom is also ``` try: foo = Foo.objects.get(x="foo") except Foo.DoesNotExist: foo = None ``` which is pretty pythonic IMO, but I wouldn't be opposed to a keyword-only argument on `get` that returns `None` if not found ``` foo = Foo.objects.get(x="foo", strict=False) # or foo =

Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

It is a common idiom to use `.filter(<...>).first()` as a replacement for `.get(<...>)` when `None` is wanted instead of an exception when no match is found. That works, but wouldn't the intention be more clear if that could be written as something like .checked(False).get(<...>) -- You recei