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

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 le

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

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 Go

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

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 djan

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

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

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

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 prolif

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

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

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

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 tra

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

(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

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

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)

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

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

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

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

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

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()` th

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

*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 c

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

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 manipulation