Count me as -1 too, it doesn't seem worth it to me to save the 3 characters
'pk='. It would increase complexity of implementation and complexity of
comprehension ("two ways to do it").

On Wed, 31 Oct 2018 at 23:00, Ian Foote <i...@feete.org> wrote:

> I'm not in favour of this, it's too implicit for my liking and I don't
> think any gains outweigh the increased complexity of implementation.
>
> Ian
>
> On Wed, 31 Oct 2018 at 19:04, charettes <charett...@gmail.com> wrote:
>
>> My main concern with allowing extra args and kwargs to be mixed with the
>> proposed
>> pk arg notation is that it would allow lookups such as
>>
>> get(Q(is_active=True), pk)
>>
>> Simon
>>
>> Le mercredi 31 octobre 2018 14:53:35 UTC-4, Antwan a écrit :
>>>
>>> *I'm not convinced this would be as useful for `filter()` though as I
>>> don't*
>>> *recall wanting to retrieve a set of objects matching a value I know
>>> will*
>>> *be unique.*
>>>
>>> The .filter() could be used for update
>>>
>>> e.g.:
>>> Mymodel.objects.filter(1).update(key=value)
>>>
>>> This is also bringing consistency in the code, but I agree this could be
>>> misleading.
>>> The .get() is the main purpose.
>>>
>>> *Something to keep in mind as well is whether or not we want to allow*
>>> *this to be coupled with extra args and kwargs.*
>>>
>>> Currently only kwargs are supposed to be used with get/filter. The only
>>> args that can be used currently are Q() objects (and couples but I think
>>> it's an issue).
>>> This proposed design suggestion is to also allow scalar values (strings,
>>> int, etc) too.
>>>
>>>
>>> On Wednesday, 31 October 2018 18:12:53 UTC, charettes wrote:
>>>>
>>>> As I've mentioned on the ticket I've been wishing get(pk) could
>>>> translate
>>>> to get(pk=pk) for a while but I never got to suggest it. Probably
>>>> because I
>>>> didn't feel like adding (pk=...) was really that long. I'd note that
>>>> most of the
>>>> times I wished this existed was when doing some object manipulations
>>>> through a Django shell.
>>>>
>>>> I'm not convinced this would be as useful for `filter()` though as I
>>>> don't
>>>> recall wanting to retrieve a set of objects matching a value I know will
>>>> be unique.
>>>>
>>>> Something to keep in mind as well is whether or not we want to allow
>>>> this to be coupled with extra args and kwargs.
>>>>
>>>> e.g.
>>>>
>>>>     Book.objects.get(isbn, author__name='Daniel Roy Greenfeld')
>>>>
>>>> I'd be in favor of preventing pk and kwarg or Q args mixing.
>>>>
>>>> Count me +1 for the get() case and -1 for the filter() one.
>>>>
>>>> Simon
>>>>
>>>> Le mercredi 31 octobre 2018 13:13:34 UTC-4, Antwan a écrit :
>>>>>
>>>>> Hi,
>>>>> I'm creating this topic to see if there is interest to implement
>>>>> positional arguments in queryset filtering.
>>>>>
>>>>> Current situation
>>>>>
>>>>> Currently the only way to use positional arguments to filter can be
>>>>> either:
>>>>>
>>>>>    - Passing a single or multiple Q objects:
>>>>>
>>>>>    MyClass.objects.filter(Q(key=value))
>>>>>    MyClass.objects.filter(Q(key=value), Q(other_key=value))
>>>>>
>>>>>
>>>>>
>>>>>    - Passing a couple is also working (not sure if this is a happy
>>>>>    accident, should it be removed?)
>>>>>
>>>>>    MyClass.objects.filter((key, value))
>>>>>
>>>>>
>>>>>
>>>>>    - Combination of both is also proven to work
>>>>>
>>>>>    MyClass.objects.filter((key, value), Q(other_key=value))
>>>>>
>>>>>
>>>>>
>>>>> Suggestion
>>>>>
>>>>> This feature suggestion is to leverage the case when a non-Q / non
>>>>> couple object is passed, so it implicitly interpreted as the value for the
>>>>> model's pk.
>>>>>
>>>>> This could ease/simplify code by omitting pk when this is the only
>>>>> filter used:
>>>>>
>>>>>
>>>>> MyClass.objects.get(value)
>>>>> # Translates into: MyClass.objects.get(pk=value)
>>>>>
>>>>>
>>>>> or
>>>>>
>>>>>
>>>>> MyClass.objects.filter(value)
>>>>> # Translates into: MyClass.objects.filter(pk=value)
>>>>>
>>>>>
>>>>> or
>>>>>
>>>>>
>>>>> MyClass.objects.filter(Q(value))
>>>>> # Translates into: MyClass.objects.filter(Q(pk=value))
>>>>>
>>>>>
>>>>> Do you think it's worth it? It could be leveraged to simplify many
>>>>> situations.
>>>>> I'd be happy to proceed to the development myself if this is something
>>>>> gathering interest.
>>>>>
>>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/a29eed0a-687a-4964-aec3-a25eeeb6f441%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/a29eed0a-687a-4964-aec3-a25eeeb6f441%40googlegroups.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 (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFv-zfLVpgrSdiFp1w0-9jLsDUG%2BrA7Fo7L89kWREVeYDCnM3w%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAFv-zfLVpgrSdiFp1w0-9jLsDUG%2BrA7Fo7L89kWREVeYDCnM3w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0ZRdc11qCY-JiRwUuuTDDkM0yCxN8%3DmGx5LDR9iNiAmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
  • I... Antwan
    • ... charettes
      • ... Antwan
        • ... charettes
          • ... Ian Foote
            • ... Adam Johnson
              • ... 'Ivan Anishchuk' via Django developers (Contributions to Django itself)
                • ... 'Ivan Anishchuk' via Django developers (Contributions to Django itself)
      • ... Josh Smeaton
        • ... Tom Forbes
          • ... James Bennett
            • ... ludovic coues
    • ... Daniel Chimeno
      • ... C. Kirby
        • ... Collin Anderson

Reply via email to