Re: The behavior of QueryDict.get(_key_, _default=None_)

[Philip Lee]

so maybe we should add to the documentation of 
https://docs.djangoproject.com/en/2.0/ref/request-response/#django.http.QueryDict
*If want to get multiple values for the same key, use 
QueryDict.getlist(key, default=None) instead of QueryDict.get(key, 
default=None)*

add example to 
https://docs.djangoproject.com/en/2.0/ref/request-response/#django.http.QueryDict.getlist
*>>> q = QueryDict('a=1&a=2&c=3')*
*>>> q.get('a')*
*'3'*
*>>> q.getlist('a')*
*['1', '2', '3']*


-- 
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/d7cf3d32-752b-4da7-8079-fc8d22e36a71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The behavior of QueryDict.get(_key_, _default=None_)

[Florian Apolloner]

On Thursday, July 19, 2018 at 8:52:56 AM UTC+2, Carlton Gibson wrote:
>
> The usual case is to need a single value from the query string, so `[]` 
> and `get()` both return scalars. 
> `getList()` exists specifically for the case where you do want multiple 
> values. 
>

I'd like to expand on this, because the current behaviour has even more 
important aspects. The query string is supplied by the user and as such is 
completely untrusted data. If `.get` were to change to return lists if 
there are lists, this would mean that the user could control the data 
structures in the view. This is not something we'd ever want.

Aside from that it is technically impossible to change the behaviour of get 
to return lists: What would ?some_param=1 result in? Would it all of a 
sudden be a list with one item? Since there is no difference between a 
scalar value and a one item list in terms of query strings, this has to 
stay the decision of the developer. They are the only ones knowing how the 
data should look like and can handle it accordingly.

Cheers,
Florian

-- 
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/4e15b2a8-895e-4c43-9b61-5dce2759d23c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins resources

[Matt Cooper]

I have a reasonable build definition set up on VSTS here:
https://mattc-demo.visualstudio.com/python-ci-testing/_build/index?&path=\&definitionId=8&_a=completed

In order to test against the different databases, I need to wait for our
containerized builds stuff that's coming out shortly. Other than that
(major) gap, I'd love to hear if I've missed anything important. The build
script is here .


On Thu, Jul 12, 2018 at 10:36 AM Matt Cooper  wrote:

> Thanks! I'll keep in on list as long as no one feels spammed :) And I'm
> very glad you asked about support -- it's been on our minds a lot lately.
>
> I did some more digging on the ForcedTimeZone test. No issues on your end!
> That test gets skipped, and the test runner emits `datetime.datetime.min`.
> This confuses the uploader. There's agreement over on NUnit
>  for their implementation to
> start emitting the current time instead of DateTime.Min, and I've raised
> an issue 
> with the xmlrunner folks to make the same change. I'm also going to see if
> I can track down the right person to be more liberal in what the uploader
> accepts.
>
> On Thu, Jul 12, 2018 at 9:40 AM Carlton Gibson 
> wrote:
>
>> Hi Matt,
>>
>> The settings files from the django-box project are here:
>> https://github.com/django/django-box/tree/master/roles/djangodata/files
>> If you look in each, you'll see they basically just redefine the
>> connection details for the 'default' and 'other' DB.
>> (There's not much more to it really.)
>>
>> You can see supported Python versions here:
>> https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-can-i-use-with-django
>> For master it's now just Python 3.5-3.7.
>>
>> > tests.timezones.ForcedTimeZoneDatabase generates output with an invalid
>> timestamp...
>>
>> Not sure what that's about, but if you think there's an issue our end
>> open a ticket at https://code.djangoproject.com.
>>
>> > ... what issues you faced ...
>>
>> None in particular. My observation was more from a UX perspective. VSTS
>> is all built around the idea you host on visualstudio.com
>> but if you don't do that whole areas are blank (and a bit
>> superfluous/confusing). It seems to have changed a bit, I see. :)
>>
>> Finally:
>>
>> > I'm confident we can put something together in terms of resources for
>> the DSF...
>>
>> Great! Of course we don't have to talk about it now. (It was more a
>> speculative ask..  :-)
>>
>> I think we're OK to discuss here if it's not too noisy. Otherwise do hit
>> me off-list.
>> (Is there no VSTS messaging...? You could create an issue on your GitHub
>> clone and @mention me. :-)
>>
>> Kind Regards,
>>
>> Carlton
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/oDgv_Ztgd4s/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/5f1b112b-212e-413f-aa8d-e97553b7538d%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/CAGtApQVnfySqiT2Bd6SgN%3DnR_B2PgRbVmAwN8%2B_rrfpdVw7KOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re:Re: The behavior of QueryDict.get(_key_, _default=None_)

[Zhao Lee]

I have to confess I don’t know much about web development .

I used to expect QueryDict.get(_key_, _default=None_) to return data type that 
client side offered, for example , if client side send {'wordPos':(2,3)} , I 
expect get('wordPos') to return it, whereas the current behavior is far from 
explanation , even using getlist('wordPos'), it just returns ['2','3'], then I 
have to do additional work to convert it back to its first shape, just found 
this inconvenient, so I made this post.
BTW, why integers were converted to strings after the transmission?







在2018年07月19 20时44分, "Florian Apolloner"写道:


On Thursday, July 19, 2018 at 8:52:56 AM UTC+2, Carlton Gibson wrote:
The usual case is to need a single value from the query string, so `[]` and 
`get()` both return scalars. 
`getList()` exists specifically for the case where you do want multiple values. 


I'd like to expand on this, because the current behaviour has even more 
important aspects. The query string is supplied by the user and as such is 
completely untrusted data. If `.get` were to change to return lists if there 
are lists, this would mean that the user could control the data structures in 
the view. This is not something we'd ever want.


Aside from that it is technically impossible to change the behaviour of get to 
return lists: What would ?some_param=1 result in? Would it all of a sudden be a 
list with one item? Since there is no difference between a scalar value and a 
one item list in terms of query strings, this has to stay the decision of the 
developer. They are the only ones knowing how the data should look like and can 
handle it accordingly.



Cheers,
Florian


--
You received this message because you are subscribed to a topic in the Google 
Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/django-developers/snBepnO5AjY/unsubscribe.
To unsubscribe from this group and all its topics, 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/4e15b2a8-895e-4c43-9b61-5dce2759d23c%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/47f81b86.5f.164b581f067.Coremail.redstone-cold%40163.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: The behavior of QueryDict.get(_key_, _default=None_)

[Collin Anderson]

Using your example, the client is sending this string:

?wordPos=2&wordPos=3

It's not an array like ?wordPos=2,3

On Thu, Jul 19, 2018 at 10:27 PM Zhao Lee  wrote:

> I have to confess I don’t know much about web development .
>
> I used to expect QueryDict.get(_key_, _default=None_) to return data type
> that client side offered, for example , if client side send
> {'wordPos':(2,3)} , I expect get('wordPos') to return it, whereas the
> current behavior is far from explanation , even using getlist('wordPos'),
> it just returns ['2','3'], then I have to do additional work to convert
> it back to its first shape, just found this inconvenient, so I made this
> post.
> BTW, why integers were converted to strings after the transmission?
>
>
>
> 在2018年07月19 20时44分, "Florian Apolloner"写道:
>
>
> On Thursday, July 19, 2018 at 8:52:56 AM UTC+2, Carlton Gibson wrote:
>>
>> The usual case is to need a single value from the query string, so `[]`
>> and `get()` both return scalars.
>> `getList()` exists specifically for the case where you do want multiple
>> values.
>>
>
> I'd like to expand on this, because the current behaviour has even more
> important aspects. The query string is supplied by the user and as such is
> completely untrusted data. If `.get` were to change to return lists if
> there are lists, this would mean that the user could control the data
> structures in the view. This is not something we'd ever want.
>
> Aside from that it is technically impossible to change the behaviour of
> get to return lists: What would ?some_param=1 result in? Would it all of a
> sudden be a list with one item? Since there is no difference between a
> scalar value and a one item list in terms of query strings, this has to
> stay the decision of the developer. They are the only ones knowing how the
> data should look like and can handle it accordingly.
>
> Cheers,
> Florian
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/snBepnO5AjY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/4e15b2a8-895e-4c43-9b61-5dce2759d23c%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/47f81b86.5f.164b581f067.Coremail.redstone-cold%40163.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/CAFO84S7i7YOrqmWamGo5vwr8RW0L6EBuvdsBEAh-0LjDwNtNEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: The behavior of QueryDict.get(_key_, _default=None_)

[Collin Anderson]

You might want to try json encoding your data if you want to preserve
integers, lists, etc.

On Thu, Jul 19, 2018 at 10:54 PM Collin Anderson 
wrote:

> Using your example, the client is sending this string:
>
> ?wordPos=2&wordPos=3
>
> It's not an array like ?wordPos=2,3
>
> On Thu, Jul 19, 2018 at 10:27 PM Zhao Lee  wrote:
>
>> I have to confess I don’t know much about web development .
>>
>> I used to expect QueryDict.get(_key_, _default=None_) to return data
>> type that client side offered, for example , if client side send
>> {'wordPos':(2,3)} , I expect get('wordPos') to return it, whereas the
>> current behavior is far from explanation , even using getlist('wordPos'),
>> it just returns ['2','3'], then I have to do additional work to convert
>> it back to its first shape, just found this inconvenient, so I made this
>> post.
>> BTW, why integers were converted to strings after the transmission?
>>
>>
>>
>> 在2018年07月19 20时44分, "Florian Apolloner"写道:
>>
>>
>> On Thursday, July 19, 2018 at 8:52:56 AM UTC+2, Carlton Gibson wrote:
>>>
>>> The usual case is to need a single value from the query string, so `[]`
>>> and `get()` both return scalars.
>>> `getList()` exists specifically for the case where you do want multiple
>>> values.
>>>
>>
>> I'd like to expand on this, because the current behaviour has even more
>> important aspects. The query string is supplied by the user and as such is
>> completely untrusted data. If `.get` were to change to return lists if
>> there are lists, this would mean that the user could control the data
>> structures in the view. This is not something we'd ever want.
>>
>> Aside from that it is technically impossible to change the behaviour of
>> get to return lists: What would ?some_param=1 result in? Would it all of a
>> sudden be a list with one item? Since there is no difference between a
>> scalar value and a one item list in terms of query strings, this has to
>> stay the decision of the developer. They are the only ones knowing how the
>> data should look like and can handle it accordingly.
>>
>> Cheers,
>> Florian
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers  (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/snBepnO5AjY/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/4e15b2a8-895e-4c43-9b61-5dce2759d23c%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/47f81b86.5f.164b581f067.Coremail.redstone-cold%40163.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/CAFO84S5yuyc7qEQ6F5G3kO%2Bu4OzNzqGhtVDQWu2mkqBfj7P5mQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.