Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Collin Anderson]

You could probably also just monkey patch like so:

from django.db.models import Manager, QuerySet
Manager.ident = QuerySet.ident = lambda self, pk: self.get(pk=pk)

On Wed, Nov 7, 2018 at 3:33 PM C. Kirby  wrote:

> I bit the bullet and put together a small app to handle this, with maybe
> even less typing. It monkey patches all installed models so you can run
> Model.ident_(pk)
> Can be found at https://github.com/ckirby/django-model-ident
>
> Chaim
>
> --
> 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/4bdacfe9-8fca-4b59-a15d-27553c731d4e%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  (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/CAFO84S5Hkm4D3o%2BAmFgV8YHX2ZKH42hG5QU6UycJpjvS8dp3xw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[C. Kirby]

I bit the bullet and put together a small app to handle this, with maybe 
even less typing. It monkey patches all installed models so you can run 
Model.ident_(pk)
Can be found at https://github.com/ckirby/django-model-ident

Chaim

-- 
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/4bdacfe9-8fca-4b59-a15d-27553c731d4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Daniel Chimeno]

This is something I've also experimented while working with a shell, I 
often mislead the .get(pk), with .get(pk=pk), 
but only at the shell, not in the views or other places (not sure why).
For that, I'm -1 to to include it in the core, and possible the best place 
is a third package app like django-extensions or similar.



-- 
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/d4db960d-1e9a-4321-9e0a-610e78532295%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[ludovic coues]

When experimenting with code in the shell, debugging or troubleshooting, I
personally tend to do a lot of get. I know some object cause issue so I try
to get them to poke them and see what's the problem.

When trying to get them, if I have the id, I always try to type
Model.objects.get(id). Sometimes I correct myself before typing enter but
that's something to remember and amount to a lot of little irritation,
sometimes while trying to solve elusive issues or trying to fix asap some
major issues in prod.


Maybe that feature belong in a third party app. Monkey-patching is a thing.

On Tue, Nov 6, 2018, 08:48 James Bennett  I still don't understand the problem this is solving; is typing "pk=" (or
> "id=") that much of a burden? Or that frequently left out by accident?
>
> As it stands, I agree with Adam that this adds implementation complexity
> (including potential future implementation complexity, as Ivan noted) and
> proliferates different ways to do the same thing, without presenting much
> in the way of concrete arguments for why it's needed. If there's a really
> convincing case to be made for this, I'm open to reading it when it's made,
> but for now I'd be -1 on the whole thing.
>
> --
> 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/CAL13Cg9ocm_LmZSGbQG%3DEB2U0Z%2BOF5eupJFwK3OWbyz46JDj5Q%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  (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/CAEuG%2BTZ6Nm4Hwm_oKBRbdzxztORgD%3DAAsFkZBPXnPULJhC2Egg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[James Bennett]

I still don't understand the problem this is solving; is typing "pk=" (or
"id=") that much of a burden? Or that frequently left out by accident?

As it stands, I agree with Adam that this adds implementation complexity
(including potential future implementation complexity, as Ivan noted) and
proliferates different ways to do the same thing, without presenting much
in the way of concrete arguments for why it's needed. If there's a really
convincing case to be made for this, I'm open to reading it when it's made,
but for now I'd be -1 on the whole thing.

-- 
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/CAL13Cg9ocm_LmZSGbQG%3DEB2U0Z%2BOF5eupJFwK3OWbyz46JDj5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Tom Forbes]

I feel this would be a good addition to just .get(), I’ve wanted this while
working with the shell. Model.objects.get(pk) feels very natural to me, and
the common Model.objects.get(pk=pk) always felt overly verbose.




On 5 November 2018 at 22:37:52, Josh Smeaton (josh.smea...@gmail.com) wrote:

I'm in the same boat as Simon - I've wanted this many times in the last few
months, but only when working at the shell. I'd be +1 for get and -1 for
filter also.

On Thursday, 1 November 2018 05:12:53 UTC+11, 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/ba9128d7-9e49-4269-b3a3-9995a998b491%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  (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/CAFNZOJP8Ny6gYqQ9ssmCHjK_J_uEfe%2BGFTmcy0BA1fPJPEfQig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Josh Smeaton]

I'm in the same boat as Simon - I've wanted this many times in the last few 
months, but only when working at the shell. I'd be +1 for get and -1 for 
filter also.

On Thursday, 1 November 2018 05:12:53 UTC+11, 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/ba9128d7-9e49-4269-b3a3-9995a998b491%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

['Ivan Anishchuk' via Django developers (Contributions to Django itself)]

(Sorry, accidental send.)

Consider adding a custom __call__ method to your manager class that would
only accept values for pk lookup, nothing else. That way you can save four
additional characters (qs(123) vs qs.get(id=123)) and that would be
something I'm not against seeing in django, provided it's convenient enough
and simple enough (not allowing arbitrary stuff that should be passed to
filter() is the key, I think).

It would require further discussion to decide how different such a method
should be from .get() - I can think of a few improvements I could find
useful in shell but some of them might not for will in the current queryset
api.

Ivan.

On Thu, 1 Nov 2018, 19:41 Ivan Anishchuk,  wrote:

> Not closely related, but what about composite keys? I think having such an
> implicit arg interpretation would make it much more complicated to use,
> say, a combination of charfield and integerfield as your key (primary or
> foreign doesn't matter): what does .get(('string', 123)) mean?
> .get(string=123) or .get(field1='string', field2=123)?
>
> Actually, I think passing pairs isn't such a good idea either, but I can
> see some benefits over using dicts or unpacked args. (Assuming Q objects
> are not desired, for whatever reason.)
>
> I'd prefer being sure which fields correspond to which values and about
> their order in the resulting query over saving three bytes on average (id=
> or pk=).
>
> On the other hand, perhaps using a custom manager class would work in your
> case, consider adding a separate method
>
>
> On Thu, 1 Nov 2018, 11:47 Adam Johnson,  wrote:
>
>> 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  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  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?)
>>>
>>>MyCla

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

['Ivan Anishchuk' via Django developers (Contributions to Django itself)]

Not closely related, but what about composite keys? I think having such an
implicit arg interpretation would make it much more complicated to use,
say, a combination of charfield and integerfield as your key (primary or
foreign doesn't matter): what does .get(('string', 123)) mean?
.get(string=123) or .get(field1='string', field2=123)?

Actually, I think passing pairs isn't such a good idea either, but I can
see some benefits over using dicts or unpacked args. (Assuming Q objects
are not desired, for whatever reason.)

I'd prefer being sure which fields correspond to which values and about
their order in the resulting query over saving three bytes on average (id=
or pk=).

On the other hand, perhaps using a custom manager class would work in your
case, consider adding a separate method

On Thu, 1 Nov 2018, 11:47 Adam Johnson,  wrote:

> 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  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  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))
>> # Translat

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Adam Johnson]

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  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  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
>> 
>> .

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Ian Foote]

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  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
> 
> .
> 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

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[charettes]

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.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Antwan]

*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/169297f4-3b10-4677-8197-805acb7ad283%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[charettes]

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/1c33a94d-5bf8-46f6-a9b7-0e0929842acc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Antwan]

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/b30b52f4-479b-4342-885b-2ce78af6f70e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.