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 

Re: Python string formatting

[Tim Graham]

Another discussion is 
https://groups.google.com/d/topic/django-developers/J9CfWIgrgbY/discussion 
- % vs {} string formatting for public APIs

I haven't seen any practical benefits to prefer format() over %s. I find 
the latter less verbose.

I'm not certain what this argument is (things like 
http://lucumr.pocoo.org/2016/12/29/careful-with-str-format/ I imagine) but 
here's a previous concern that Florian raised regarding f-strings:
"Knowing what certain members of the core team think about those f-strings, 
I think there will be first a big discussion if we will allow them at all 
in Django's codebase. Then there are further things to consider like 
gettext support etc…"
https://groups.google.com/d/msg/django-developers/4rbVKJYm8DI/y9VNRBw0AgAJ

On Wednesday, October 31, 2018 at 6:28:08 PM UTC-4, Tom Forbes wrote:
>
> In my experience f strings are vastly more expressive than .format, but 
> not much better than % based formatting.
>
> If we can make this change after we drop 3.5 I think it will be a lot 
> easier.
>
> On Wed, 31 Oct 2018, 21:09 Adrian Turjak   wrote:
>
>> There was a push to deprecated % formatting but too many people 
>> complained and that never happened.
>>
>> While .format and g-strings are superior, % is here to stay for the 
>> foreseeable future. Too many people still use it (including myself 
>> sometimes).
>>
>> On 1 Nov. 2018 08:14, Carlton Gibson > 
>> wrote:
>>
>> We had a bit of a discussion of this on 
>>
>>
>> Python 2 docs have got this re format(): 
>>
>> > This method of string formatting is the new standard in Python 3, and 
>> should be preferred to the % formatting described in String Formatting 
>> Operations in new code.
>>
>> ​https://docs.python.org/2/library/stdtypes.html#str.format
>>
>> But it's not there for Python 3 (
>> ​https://docs.python.org/3/library/stdtypes.html#str.format) so I'm not 
>> clear what we're meant to think. 
>> (I had thought %-formatting deprecated...) 
>>
>> Anyone know? 
>>
>> Regardless, waiting a bit and moving straight to f-strings (as Simon 
>> suggests) seems sensible. (If we're convinced we do want to change.)
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/e7cf5b0d-cff4-4c6d-a9ec-1af4a82d5a56%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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/6b09193b-a53f-4eb4-9f36-2c7aa11f47cb%40email.android.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/65527cfe-d970-47b4-828c-7f55312d2120%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Python string formatting

[Tom Forbes]

In my experience f strings are vastly more expressive than .format, but not
much better than % based formatting.

If we can make this change after we drop 3.5 I think it will be a lot
easier.

On Wed, 31 Oct 2018, 21:09 Adrian Turjak  There was a push to deprecated % formatting but too many people complained
> and that never happened.
>
> While .format and g-strings are superior, % is here to stay for the
> foreseeable future. Too many people still use it (including myself
> sometimes).
>
> On 1 Nov. 2018 08:14, Carlton Gibson  wrote:
>
> We had a bit of a discussion of this on
>
>
> Python 2 docs have got this re format():
>
> > This method of string formatting is the new standard in Python 3, and
> should be preferred to the % formatting described in String Formatting
> Operations in new code.
>
> ​https://docs.python.org/2/library/stdtypes.html#str.format
>
> But it's not there for Python 3 (
> ​https://docs.python.org/3/library/stdtypes.html#str.format) so I'm not
> clear what we're meant to think.
> (I had thought %-formatting deprecated...)
>
> Anyone know?
>
> Regardless, waiting a bit and moving straight to f-strings (as Simon
> suggests) seems sensible. (If we're convinced we do want to change.)
>
> --
> 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/e7cf5b0d-cff4-4c6d-a9ec-1af4a82d5a56%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/6b09193b-a53f-4eb4-9f36-2c7aa11f47cb%40email.android.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/CAFNZOJOpL%2BLXx2xQhSb6DtGr90UQ-LhA2Y6S8CpZftjVcObmQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Python string formatting

[Adrian Turjak]

There was a push to deprecated % formatting but too many people complained and that never happened.While .format and g-strings are superior, % is here to stay for the foreseeable future. Too many people still use it (including myself sometimes).On 1 Nov. 2018 08:14, Carlton Gibson  wrote:We had a bit of a discussion of this on Python 2 docs have got this re format(): > This method of string formatting is the new standard in Python 3, and should be preferred to the % formatting described in String Formatting Operations in new code.​https://docs.python.org/2/library/stdtypes.html#str.formatBut it's not there for Python 3 (​https://docs.python.org/3/library/stdtypes.html#str.format) so I'm not clear what we're meant to think. (I had thought %-formatting deprecated...) Anyone know? Regardless, waiting a bit and moving straight to f-strings (as Simon suggests) seems sensible. (If we're convinced we do want to change.)



-- 
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/e7cf5b0d-cff4-4c6d-a9ec-1af4a82d5a56%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/6b09193b-a53f-4eb4-9f36-2c7aa11f47cb%40email.android.com.
For more options, visit https://groups.google.com/d/optout.

Re: Python string formatting

[Carlton Gibson]

Sorry, I typed that up and forgot to paste the link 

On Wednesday, 31 October 2018 20:14:14 UTC+1, Carlton Gibson wrote:
>
> We had a bit of a discussion of this on 
>

https://code.djangoproject.com/ticket/29623


-- 
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/54ffdece-7da1-4bd9-baa5-f441cd03f4ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Python string formatting

[Carlton Gibson]

We had a bit of a discussion of this on 


Python 2 docs have got this re format(): 

> This method of string formatting is the new standard in Python 3, and 
should be preferred to the % formatting described in String Formatting 
Operations in new code.

​https://docs.python.org/2/library/stdtypes.html#str.format

But it's not there for Python 3 (
​https://docs.python.org/3/library/stdtypes.html#str.format) so I'm not 
clear what we're meant to think. 
(I had thought %-formatting deprecated...) 

Anyone know? 

Regardless, waiting a bit and moving straight to f-strings (as Simon 
suggests) seems sensible. (If we're convinced we do want to change.)

-- 
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/e7cf5b0d-cff4-4c6d-a9ec-1af4a82d5a56%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]

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.

Re: Python string formatting

[charettes]

I don't have a strong opinion on whether or not we should make the switch 
but
if the consensus is too move forward with this I'd suggest we wait until 
Django
master's branch only supports Python 3.6+.

That would allow us to switch directly to f-strings and avoid doubling the 
already
large diff noise that such a change would generate.

Simon

Le mercredi 31 octobre 2018 13:13:34 UTC-4, manda...@gmail.com a écrit :
>
> Hi,
>
> Long story short, I discovered [1] there is no concensus [2] on which 
> formatting to use in the Django tutorial.
>
> An argument for % (or against the format method) was 
> https://savannah.gnu.org/bugs/?30854 but it has been fixed 5 years ago, 
> its stays an argument against f-strings.
>
> It seemed obvious to me that we should favor the use of ".format()" over 
> "%-formatting" [3], at least for newcomers (in the tutorial), as they are 
> expected to run work up-to-date Python interpreters.
>
> It also make it smoother for them to step on (or convert to to) f-strings 
> from the ".format" mini-language than from the "%s" notation. And for those 
> using 3.6+, using f-string is clearly more readable than .format or % (As 
> long as they don't have to do i18n on those f-strings).
>
> The thread in [1] is 5 years old, so I'm starting a new one to see if we 
> can reach a concensus in 2018—2019 about not driving newcomers to use 
> %-formatting.
>
> What do you think?
>
> [1]: https://github.com/django/django/pull/10590/files
> [2]: 
> https://groups.google.com/forum/#!topic/django-developers/7xiXlz5DUWM/discussion
> [3]: 
> https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting
>

-- 
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/adaaeee3-7460-4a87-b08d-596d20201660%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django admin not working

[oussama boumaad]

Please check urls.py on the root project
It should contain :
urlpatterns = [ Path('admin/', admin.site.urls), ]

On Sat, Oct 20, 2018, 8:37 AM Adam Johnson  wrote:

> This mailing list is for the development of Django itself, not for
> support. Use the django-users mailing list for that, or IRC #django on
> freenode, or a site like Stack Overflow.
>
> On Sat, 20 Oct 2018 at 05:31, Muhammad Tahir 
> wrote:
>
>> Hello everyone,
>> i am following django tutorial (localhost) at following url
>> https://docs.djangoproject.com/en/2.1/intro/tutorial02/
>> when i try to access admin i.e http://127.0.0.1:8000/admin it gives
>> error "A server error occurred. Please contact the administrator."
>> although http://127.0.0.1:8000/polls works fine.
>>
>> Please help..
>>
>> --
>> 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/d7b3fef3-4d1e-4ef3-ad60-48120b53a691%40googlegroups.com
>> 
>> .
>> 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/CAMyDDM1wMd5U88twZbScP_CRpj4uQvs_JeS%2BNdLeOckiB4ugKA%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/CAKYUqcWmYsMnifZjawkmDSKKeG9jfftJqxut2fUzRQbb3wND7g%40mail.gmail.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.

Python string formatting

[mandark . dev]

Hi,

Long story short, I discovered [1] there is no concensus [2] on which 
formatting to use in the Django tutorial.

An argument for % (or against the format method) was 
https://savannah.gnu.org/bugs/?30854 but it has been fixed 5 years ago, its 
stays an argument against f-strings.

It seemed obvious to me that we should favor the use of ".format()" over 
"%-formatting" [3], at least for newcomers (in the tutorial), as they are 
expected to run work up-to-date Python interpreters.

It also make it smoother for them to step on (or convert to to) f-strings 
from the ".format" mini-language than from the "%s" notation. And for those 
using 3.6+, using f-string is clearly more readable than .format or % (As 
long as they don't have to do i18n on those f-strings).

The thread in [1] is 5 years old, so I'm starting a new one to see if we 
can reach a concensus in 2018—2019 about not driving newcomers to use 
%-formatting.

What do you think?

[1]: https://github.com/django/django/pull/10590/files
[2]: 
https://groups.google.com/forum/#!topic/django-developers/7xiXlz5DUWM/discussion
[3]: 
https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting

-- 
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/7d1b83e0-21b5-4a85-97f4-4217a0c7a243%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: seat selecting page .

[Michael Manfre]

This mailing list is for the development of Django itself, not how to use
Django. The mailing list django-users is where you can ask this type of
question, but you will need to make your question a bit more detailed, if
you'd like to get a helpful response.

Regards,
Michael Manfre

On Wed, Oct 31, 2018 at 7:46 AM mainga miyanda 
wrote:

> i'm creating a online movie booking website, and i want to add a seat
> selection site before it records the seats chosen and the bill is
> calculated.
>
> --
> 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/CAPbPLkQVAwe%2BdJ-90VnnnshGHGA8K1VgsRkUpa0f1CDQ-PO%2Bfg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

-- 
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/CAGdCwBsr_%3DWfrcupXTEv-9DVE8v8Ji13A-RP-BWivTCgUR5O6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

seat selecting page .

[mainga miyanda]

i'm creating a online movie booking website, and i want to add a seat
selection site before it records the seats chosen and the bill is
calculated.

-- 
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/CAPbPLkQVAwe%2BdJ-90VnnnshGHGA8K1VgsRkUpa0f1CDQ-PO%2Bfg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Reports -- October 2018

[Carlton Gibson]

Hi all,


Calendar Week 43 -- ending 28 October.


Triaged:

https://code.djangoproject.com/ticket/29889 -- ArrayField cannot contain 
JSONField; causes SQL error (needsinfo)
https://code.djangoproject.com/ticket/29879 -- CSRF AJAX section should 
warn about the CSRF_COOKIE_HTTPONLY setting (Accepted)
https://code.djangoproject.com/ticket/29863 -- Allow 
configuration/customization of sensitive settings sanitization for error 
emails (Duplicate)
https://code.djangoproject.com/ticket/29873 -- Link to access related field 
on the admin tool (needsinfo)
https://code.djangoproject.com/ticket/29874 -- Typo in Writing your 
first Django app, part2. (wontfix)



Reviewed:

https://code.djangoproject.com/ticket/29879 -- CSRF AJAX section should 
warn about the CSRF_COOKIE_HTTPONLY setting
https://github.com/django/django/pull/9272 -- Cleaned-up duplicate 
connection functionality.
https://code.djangoproject.com/ticket/29721 -- Migrations are not applied 
atomically
https://code.djangoproject.com/ticket/15602 -- Using get_readonly_fields 
and StackedInline/TabularInline admin objects doesnt allow creating 
new objects, immutible existing objects
https://code.djangoproject.com/ticket/29830 -- Fixed loss of custom utf-8 
body encoding in mails.
https://code.djangoproject.com/ticket/29877 -- Dive Into Python 3 links in 
documentation no longer valid
https://code.djangoproject.com/ticket/29868 -- Database constraint checks 
are not retained on sqlite
https://code.djangoproject.com/ticket/28184 -- FileField storage param 
should allow a callable




Kind Regards,

Carlton

-- 
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/d46f83f5-744e-4e97-894a-fdb04867f2a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.