Re: Selected projects for Google Summer of Code 2020

[Ahmad A. Hussein]

I'm honestly ecstatic to have been accepted! It's something that I wanted 
to do since last year when I read about Sage's project after I started 
using Django.

I'll definitely start a blog to document the entire journey and I think 
it'll help with keeping track of my own progress. Thanks for the suggestion 
Sage.

I'll make a thread on the forums to discuss my current plans/preparations 
or any issue, and I'll be sure to link to the PR as relevant and discuss 
specific details there. 

Looking forward to working with Tom and Adam!


Regards,
Ahmad


On Wednesday, May 6, 2020 at 5:52:49 PM UTC+2, Adam Johnson wrote:
>
> Congratulations Kacper and Ahmad! 
>
> Thanks to my fellow mentors for their work so far helping filtering the 
> applications. And especially Carlton for keeping us organized.
>
> Yes the forum is a great place to keep the conversation.
>
> Looking forward to mentoring Ahmad,
>
> Adam
>
> On Wed, 6 May 2020 at 12:27, Kacper Szmigiel  > wrote:
>
>> Hello all!
>>
>> TBH I'm still shocked that I got accepted!  I don't even know how to 
>> express my satisfaction. I would like to thank you for your trust, and 
>> promise to do my best.
>>
>> About the communication channels - I will adapt to whatever suits you 
>> best. I got used to writing emails, but I can switch to forum, no problem.
>>
>> I'm also about to start vlogging about GSoC in the near future. I was 
>> planning to start doing so since a while, and this seems to be a good 
>> opportunity :D At this point I'm collecting equipment and discussing the 
>> details with my friend who is a video editor.
>>
>> I've already contacted Nikita Sobolev and started going through Mypy 
>> documentation. I think we'll establish a plan and timeline of my work next 
>> week.
>>
>> I also have to ask you to keep in mind that I will be taking my exam 
>> session at Uni in June, so I will probably do most of the work in July and 
>> September. I informed my lecturers and University authorities about getting 
>> accepted into GSoC, so maybe they'll make it easier for me to pass this 
>> semester, I hope to know the answer in a few days.
>>
>> Kind regards,
>> Kacper Szmigiel
>>
>>
>> śr., 6 maj 2020 o 11:45 Sage M. Abdullah > 
>> napisał(a):
>>
>>> Thanks, Carlton, for the briefing!
>>>
>>> I agree it's a good idea to utilize the forum for discussions. Aside 
>>> from the forum and GitHub, I'd suggest Ahmad and Kacper start a blog if you 
>>> haven't already, and write about your GSoC Journey there. I'm sure folks 
>>> would enjoy reading how you learn and implement stuff along the way. You 
>>> can also use it as a portfolio in the future. As Carlton said, we had a lot 
>>> of applications, so I think getting selected is quite an achievement. Make 
>>> the most of it for your future endeavors.
>>>
>>> You can use a static site generator like Jekyll or Hugo and use GitHub 
>>> pages to get it up and running quickly. Starting a blog is just a 
>>> suggestion, it's okay if you don't feel like it :)
>>>
>>> I was also a GSoC student with Django just last year so I'm still quite 
>>> new to a lot of things as well, but I'll try to help the best I can.
>>>
>>> So, congrats Ahmad and Kacper, looking forward to working with you!
>>>
>>> Regards,
>>> Sage
>>>
>>>
>>> On Wednesday, 6 May 2020 13:46:26 UTC+7, Carlton Gibson wrote:

 Hi all. 

 We had lots of applications for GSoC, and lots of folks to act as 
 mentors, so I want to 
 thank everyone there.

 Django was accepted into GSoC. We were granted two slots. Thus for 
 2020, 
 two student proposals were selected:

 * Kacper Szmigiel, an undergraduate student at Technical University of 
 Lodz in Poland, will work on a refactor of the mypy plugin plugin that is 
 part of [django-stubs][0]. His primary mentors are Nikita Sobolev, and 
 Artem Malyshev, maintainers of django-stubs. 

 [0]: https://github.com/typeddjango/django-stubs

 * Ahmad A. Hussein, an undergraduate student German University in 
 Cairo, will work to extend the parallel test runner to Windows, macOS, and 
 add Oracle support. His primary mentors are Tom Forbes and Adam Johnson. 

 Additional mentors are Shai Berger, Simon Charette, Sage Abdullah, 
 David Smith, Mariusz Felisiak, and Carlton Gibson.
 (I allocated us to the projects for the application phase but we can 
 adjust.)

 My plan/hope/thought is to use the Forum[1] as the primary 
 communication channel. It works well for discussions. 
 If anyone else would like to follow-along, then that's the place. 

 [1]: https://forum.djangoproject.com

 We can post more occasional updates to the list here.

 I'd like to welcome Ahmad and Kacper — we're looking forward to working 
 with you!

 Kind Regards,

 Carlton



 -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Djan

Re: Selected projects for Google Summer of Code 2020

[Adam Johnson]

Congratulations Kacper and Ahmad!

Thanks to my fellow mentors for their work so far helping filtering the
applications. And especially Carlton for keeping us organized.

Yes the forum is a great place to keep the conversation.

Looking forward to mentoring Ahmad,

Adam

On Wed, 6 May 2020 at 12:27, Kacper Szmigiel 
wrote:

> Hello all!
>
> TBH I'm still shocked that I got accepted!  I don't even know how to
> express my satisfaction. I would like to thank you for your trust, and
> promise to do my best.
>
> About the communication channels - I will adapt to whatever suits you
> best. I got used to writing emails, but I can switch to forum, no problem.
>
> I'm also about to start vlogging about GSoC in the near future. I was
> planning to start doing so since a while, and this seems to be a good
> opportunity :D At this point I'm collecting equipment and discussing the
> details with my friend who is a video editor.
>
> I've already contacted Nikita Sobolev and started going through Mypy
> documentation. I think we'll establish a plan and timeline of my work next
> week.
>
> I also have to ask you to keep in mind that I will be taking my exam
> session at Uni in June, so I will probably do most of the work in July and
> September. I informed my lecturers and University authorities about getting
> accepted into GSoC, so maybe they'll make it easier for me to pass this
> semester, I hope to know the answer in a few days.
>
> Kind regards,
> Kacper Szmigiel
>
>
> śr., 6 maj 2020 o 11:45 Sage M. Abdullah  napisał(a):
>
>> Thanks, Carlton, for the briefing!
>>
>> I agree it's a good idea to utilize the forum for discussions. Aside from
>> the forum and GitHub, I'd suggest Ahmad and Kacper start a blog if you
>> haven't already, and write about your GSoC Journey there. I'm sure folks
>> would enjoy reading how you learn and implement stuff along the way. You
>> can also use it as a portfolio in the future. As Carlton said, we had a lot
>> of applications, so I think getting selected is quite an achievement. Make
>> the most of it for your future endeavors.
>>
>> You can use a static site generator like Jekyll or Hugo and use GitHub
>> pages to get it up and running quickly. Starting a blog is just a
>> suggestion, it's okay if you don't feel like it :)
>>
>> I was also a GSoC student with Django just last year so I'm still quite
>> new to a lot of things as well, but I'll try to help the best I can.
>>
>> So, congrats Ahmad and Kacper, looking forward to working with you!
>>
>> Regards,
>> Sage
>>
>>
>> On Wednesday, 6 May 2020 13:46:26 UTC+7, Carlton Gibson wrote:
>>>
>>> Hi all.
>>>
>>> We had lots of applications for GSoC, and lots of folks to act as
>>> mentors, so I want to
>>> thank everyone there.
>>>
>>> Django was accepted into GSoC. We were granted two slots. Thus for 2020,
>>> two student proposals were selected:
>>>
>>> * Kacper Szmigiel, an undergraduate student at Technical University of
>>> Lodz in Poland, will work on a refactor of the mypy plugin plugin that is
>>> part of [django-stubs][0]. His primary mentors are Nikita Sobolev, and
>>> Artem Malyshev, maintainers of django-stubs.
>>>
>>> [0]: https://github.com/typeddjango/django-stubs
>>>
>>> * Ahmad A. Hussein, an undergraduate student German University in Cairo,
>>> will work to extend the parallel test runner to Windows, macOS, and add
>>> Oracle support. His primary mentors are Tom Forbes and Adam Johnson.
>>>
>>> Additional mentors are Shai Berger, Simon Charette, Sage Abdullah, David
>>> Smith, Mariusz Felisiak, and Carlton Gibson.
>>> (I allocated us to the projects for the application phase but we can
>>> adjust.)
>>>
>>> My plan/hope/thought is to use the Forum[1] as the primary communication
>>> channel. It works well for discussions.
>>> If anyone else would like to follow-along, then that's the place.
>>>
>>> [1]: https://forum.djangoproject.com
>>>
>>> We can post more occasional updates to the list here.
>>>
>>> I'd like to welcome Ahmad and Kacper — we're looking forward to working
>>> with you!
>>>
>>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/07b2ec6e-dfff-4272-b3e9-9b38ff5876da%40googlegroups.com
>> 
>> .
>>
> --
> 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 view this discuss

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Adam Johnson]

>
> +1 request.data
>
> We shouldn’t be POSTists, there is also PUT and PATCH.
>

Would just like to point out - that's not the proposal. The proposal is to
rename the existing request.POST to request.form_data, which is based on
parsing application/x-www-form-urlencoded data from request.body. Browsers
only send such data in the body on POST.

On Wed, 6 May 2020 at 16:16, Fran Hrženjak  wrote:

> +1 request.query_params
>
> If request.method == "POST":
> thing = request.GET.get("thing")
>
> That’s just silly.
>
>
>
> +1 request.data
>
> We shouldn’t be POSTists, there is also PUT and PATCH.
>
> And apparently GET requests can also have a body:
> https://stackoverflow.com/questions/978061/http-get-with-request-body
>
>
>
> +1 No combining
>
> Because.
>
>
>
> +1 For 27 years deprecation cycle.
>
> But in reality vast majority of codebases will only need a simple search
> and replace, no? (Famous last words I guess...)
>
>
>
>
> On Wed, 6 May 2020 at 16:08, אורי  wrote:
>
>> Hi,
>>
>> I also prefer lowercase names since uppercase is usually reserved for
>> constants in Python. The names of the requests ("GET" / "POST") can be used
>> in strings to check the request method (uppercase). But there is no sense
>> in using uppercase names for variables.
>> אורי
>> u...@speedy.net
>>
>>
>> On Wed, May 6, 2020 at 12:26 AM Adam Johnson  wrote:
>>
>>> request.GET and request.POST are misleadingly named:
>>>
>>>- GET contains the URL parameters and is therefore available
>>>whatever the request method. This often confuses beginners and 
>>> “returners”
>>>alike.
>>>- POST contains form data on POST requests, but not other kinds of
>>>data from POST requests. It can confuse users who are posting JSON or 
>>> other
>>>formats.
>>>
>>> Additionally both names can lead users to think e.g. "if request.GET:"
>>> means "if this is a GET request", which is not true.
>>>
>>> I believe the CAPITALIZED naming style was inherited from PHP's global
>>> variables $_GET, $_POST, $_FILES etc. (
>>> https://www.php.net/manual/en/reserved.variables.get.php ). It stands
>>> out as unpythonic, since these are instance variables and not module-level
>>> constants (as per PEP8
>>> https://www.python.org/dev/peps/pep-0008/#constants ).
>>>
>>> I therefore propose these renames:
>>>
>>>- request.GET -> request.query_params (to match Django Rest
>>>Framework - see below)
>>>- request.POST -> request.form_data
>>>- request.FILES -> request.files
>>>- request.COOKIES -> request.cookies
>>>- request.META -> request.meta
>>>
>>> Since these are very core attributes and the change would cause a huge
>>> amount of churn, I propose not deprecating the old aliases immediately, but
>>> leaving them in with a documentation note that they "may be deprecated."
>>> Perhaps they can be like url() or ifequal which came up on the mailing list
>>> recently - put through the normal deprecation path after a few releases
>>> with such a note.
>>>
>>> Django Rest Framework already aliases GET as request.query_params in its
>>> request wrapper:
>>> https://www.django-rest-framework.org/api-guide/requests/#query_params
>>> . Therefore the name request.query_params should not be surprising. DRF
>>> also provides request.data which combines request.POST and request.FILES,
>>> and flexibly parses from different content types, but I'm not sure that's
>>> feasible to implement in Django core.
>>>
>>> For reference, other Python web frameworks have more "Pythonic" naming:
>>>
>>>- Bottle: request.url_args, request.forms, request.files,
>>>request.cookies, request.environ
>>>- Flask: request.args, request.form, request.files, request.cookies,
>>>request.environ
>>>- Starlette: request.query_params, request.form(),
>>>request.form()[field_name], request.cookies, scope
>>>
>>> One more note for those who might think such core attributes should be
>>> left alone: Django 2.2 added request.headers as a way of accessing headers
>>> by name. This is convenient as it avoids the need to transform the header
>>> to the WSGI environ name. makes the code more readable, and in the process
>>> reduces the potential for bugs. I believe this proposal is in the same vein.
>>>
>>> --
>>> 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 view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/CAMyDDM3%2BUucViDezhkWrFsk6ZsKViWjOgtA5aBm9pnzozdc%2Beg%40mail.gmail.com
>>> 
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contrib

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Fran Hrženjak]

+1 request.query_params

If request.method == "POST":
thing = request.GET.get("thing")

That’s just silly.



+1 request.data

We shouldn’t be POSTists, there is also PUT and PATCH.

And apparently GET requests can also have a body:
https://stackoverflow.com/questions/978061/http-get-with-request-body



+1 No combining

Because.



+1 For 27 years deprecation cycle.

But in reality vast majority of codebases will only need a simple search
and replace, no? (Famous last words I guess...)




On Wed, 6 May 2020 at 16:08, אורי  wrote:

> Hi,
>
> I also prefer lowercase names since uppercase is usually reserved for
> constants in Python. The names of the requests ("GET" / "POST") can be used
> in strings to check the request method (uppercase). But there is no sense
> in using uppercase names for variables.
> אורי
> u...@speedy.net
>
>
> On Wed, May 6, 2020 at 12:26 AM Adam Johnson  wrote:
>
>> request.GET and request.POST are misleadingly named:
>>
>>- GET contains the URL parameters and is therefore available whatever
>>the request method. This often confuses beginners and “returners” alike.
>>- POST contains form data on POST requests, but not other kinds of
>>data from POST requests. It can confuse users who are posting JSON or 
>> other
>>formats.
>>
>> Additionally both names can lead users to think e.g. "if request.GET:"
>> means "if this is a GET request", which is not true.
>>
>> I believe the CAPITALIZED naming style was inherited from PHP's global
>> variables $_GET, $_POST, $_FILES etc. (
>> https://www.php.net/manual/en/reserved.variables.get.php ). It stands
>> out as unpythonic, since these are instance variables and not module-level
>> constants (as per PEP8
>> https://www.python.org/dev/peps/pep-0008/#constants ).
>>
>> I therefore propose these renames:
>>
>>- request.GET -> request.query_params (to match Django Rest Framework
>>- see below)
>>- request.POST -> request.form_data
>>- request.FILES -> request.files
>>- request.COOKIES -> request.cookies
>>- request.META -> request.meta
>>
>> Since these are very core attributes and the change would cause a huge
>> amount of churn, I propose not deprecating the old aliases immediately, but
>> leaving them in with a documentation note that they "may be deprecated."
>> Perhaps they can be like url() or ifequal which came up on the mailing list
>> recently - put through the normal deprecation path after a few releases
>> with such a note.
>>
>> Django Rest Framework already aliases GET as request.query_params in its
>> request wrapper:
>> https://www.django-rest-framework.org/api-guide/requests/#query_params .
>> Therefore the name request.query_params should not be surprising. DRF also
>> provides request.data which combines request.POST and request.FILES, and
>> flexibly parses from different content types, but I'm not sure that's
>> feasible to implement in Django core.
>>
>> For reference, other Python web frameworks have more "Pythonic" naming:
>>
>>- Bottle: request.url_args, request.forms, request.files,
>>request.cookies, request.environ
>>- Flask: request.args, request.form, request.files, request.cookies,
>>request.environ
>>- Starlette: request.query_params, request.form(),
>>request.form()[field_name], request.cookies, scope
>>
>> One more note for those who might think such core attributes should be
>> left alone: Django 2.2 added request.headers as a way of accessing headers
>> by name. This is convenient as it avoids the need to transform the header
>> to the WSGI environ name. makes the code more readable, and in the process
>> reduces the potential for bugs. I believe this proposal is in the same vein.
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAMyDDM3%2BUucViDezhkWrFsk6ZsKViWjOgtA5aBm9pnzozdc%2Beg%40mail.gmail.com
>> 
>> .
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CABD5YeEFsbneB%3DfPKpE90cNukOUAKZejfp4Yo1N712mkmNVQHQ%40mail.gmail.com
> 
> .
>
-- 
LP,
Fran

-- 
You received this me

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[אורי]

Hi,

I also prefer lowercase names since uppercase is usually reserved for
constants in Python. The names of the requests ("GET" / "POST") can be used
in strings to check the request method (uppercase). But there is no sense
in using uppercase names for variables.
אורי
u...@speedy.net


On Wed, May 6, 2020 at 12:26 AM Adam Johnson  wrote:

> request.GET and request.POST are misleadingly named:
>
>- GET contains the URL parameters and is therefore available whatever
>the request method. This often confuses beginners and “returners” alike.
>- POST contains form data on POST requests, but not other kinds of
>data from POST requests. It can confuse users who are posting JSON or other
>formats.
>
> Additionally both names can lead users to think e.g. "if request.GET:"
> means "if this is a GET request", which is not true.
>
> I believe the CAPITALIZED naming style was inherited from PHP's global
> variables $_GET, $_POST, $_FILES etc. (
> https://www.php.net/manual/en/reserved.variables.get.php ). It stands out
> as unpythonic, since these are instance variables and not module-level
> constants (as per PEP8 https://www.python.org/dev/peps/pep-0008/#constants
> ).
>
> I therefore propose these renames:
>
>- request.GET -> request.query_params (to match Django Rest Framework
>- see below)
>- request.POST -> request.form_data
>- request.FILES -> request.files
>- request.COOKIES -> request.cookies
>- request.META -> request.meta
>
> Since these are very core attributes and the change would cause a huge
> amount of churn, I propose not deprecating the old aliases immediately, but
> leaving them in with a documentation note that they "may be deprecated."
> Perhaps they can be like url() or ifequal which came up on the mailing list
> recently - put through the normal deprecation path after a few releases
> with such a note.
>
> Django Rest Framework already aliases GET as request.query_params in its
> request wrapper:
> https://www.django-rest-framework.org/api-guide/requests/#query_params .
> Therefore the name request.query_params should not be surprising. DRF also
> provides request.data which combines request.POST and request.FILES, and
> flexibly parses from different content types, but I'm not sure that's
> feasible to implement in Django core.
>
> For reference, other Python web frameworks have more "Pythonic" naming:
>
>- Bottle: request.url_args, request.forms, request.files,
>request.cookies, request.environ
>- Flask: request.args, request.form, request.files, request.cookies,
>request.environ
>- Starlette: request.query_params, request.form(),
>request.form()[field_name], request.cookies, scope
>
> One more note for those who might think such core attributes should be
> left alone: Django 2.2 added request.headers as a way of accessing headers
> by name. This is convenient as it avoids the need to transform the header
> to the WSGI environ name. makes the code more readable, and in the process
> reduces the potential for bugs. I believe this proposal is in the same vein.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM3%2BUucViDezhkWrFsk6ZsKViWjOgtA5aBm9pnzozdc%2Beg%40mail.gmail.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABD5YeEFsbneB%3DfPKpE90cNukOUAKZejfp4Yo1N712mkmNVQHQ%40mail.gmail.com.

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Riccardo Magliocchetti]

Hello,

On 05/05/20 23:26, Adam Johnson wrote:

request.GET and request.POST are misleadingly named:

- GET contains the URL parameters and is therefore available whatever
the request method. This often confuses beginners and “returners” alike.
- POST contains form data on POST requests, but not other kinds of data
from POST requests. It can confuse users who are posting JSON or other
formats.

[...]>

I therefore propose these renames:

- request.GET -> request.query_params (to match Django Rest Framework -
see below)
- request.POST -> request.form_data
- request.FILES -> request.files
- request.COOKIES -> request.cookies
- request.META -> request.meta


Yes please, query_params to match DRF makes a lot of sense to me!
These days i use mostly DRF views, still have to maintain plain Django code so 
anything reducing the difference is much appreciated



Since these are very core attributes and the change would cause a huge
amount of churn, I propose not deprecating the old aliases immediately, but
leaving them in with a documentation note that they "may be deprecated."
Perhaps they can be like url() or ifequal which came up on the mailing list
recently - put through the normal deprecation path after a few releases
with such a note.


Given these are on most tutorial / book ever published on paper and on the 
internet I'd just make them an alias of the new proposed names and kept for 
quite a few.


Thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/34ff0853-d984-65f3-c63c-71d32015963d%40gmail.com.

Re: Selected projects for Google Summer of Code 2020

[Kacper Szmigiel]

Hello all!

TBH I'm still shocked that I got accepted!  I don't even know how to
express my satisfaction. I would like to thank you for your trust, and
promise to do my best.

About the communication channels - I will adapt to whatever suits you best.
I got used to writing emails, but I can switch to forum, no problem.

I'm also about to start vlogging about GSoC in the near future. I was
planning to start doing so since a while, and this seems to be a good
opportunity :D At this point I'm collecting equipment and discussing the
details with my friend who is a video editor.

I've already contacted Nikita Sobolev and started going through Mypy
documentation. I think we'll establish a plan and timeline of my work next
week.

I also have to ask you to keep in mind that I will be taking my exam
session at Uni in June, so I will probably do most of the work in July and
September. I informed my lecturers and University authorities about getting
accepted into GSoC, so maybe they'll make it easier for me to pass this
semester, I hope to know the answer in a few days.

Kind regards,
Kacper Szmigiel


śr., 6 maj 2020 o 11:45 Sage M. Abdullah  napisał(a):

> Thanks, Carlton, for the briefing!
>
> I agree it's a good idea to utilize the forum for discussions. Aside from
> the forum and GitHub, I'd suggest Ahmad and Kacper start a blog if you
> haven't already, and write about your GSoC Journey there. I'm sure folks
> would enjoy reading how you learn and implement stuff along the way. You
> can also use it as a portfolio in the future. As Carlton said, we had a lot
> of applications, so I think getting selected is quite an achievement. Make
> the most of it for your future endeavors.
>
> You can use a static site generator like Jekyll or Hugo and use GitHub
> pages to get it up and running quickly. Starting a blog is just a
> suggestion, it's okay if you don't feel like it :)
>
> I was also a GSoC student with Django just last year so I'm still quite
> new to a lot of things as well, but I'll try to help the best I can.
>
> So, congrats Ahmad and Kacper, looking forward to working with you!
>
> Regards,
> Sage
>
>
> On Wednesday, 6 May 2020 13:46:26 UTC+7, Carlton Gibson wrote:
>>
>> Hi all.
>>
>> We had lots of applications for GSoC, and lots of folks to act as
>> mentors, so I want to
>> thank everyone there.
>>
>> Django was accepted into GSoC. We were granted two slots. Thus for 2020,
>> two student proposals were selected:
>>
>> * Kacper Szmigiel, an undergraduate student at Technical University of
>> Lodz in Poland, will work on a refactor of the mypy plugin plugin that is
>> part of [django-stubs][0]. His primary mentors are Nikita Sobolev, and
>> Artem Malyshev, maintainers of django-stubs.
>>
>> [0]: https://github.com/typeddjango/django-stubs
>>
>> * Ahmad A. Hussein, an undergraduate student German University in Cairo,
>> will work to extend the parallel test runner to Windows, macOS, and add
>> Oracle support. His primary mentors are Tom Forbes and Adam Johnson.
>>
>> Additional mentors are Shai Berger, Simon Charette, Sage Abdullah, David
>> Smith, Mariusz Felisiak, and Carlton Gibson.
>> (I allocated us to the projects for the application phase but we can
>> adjust.)
>>
>> My plan/hope/thought is to use the Forum[1] as the primary communication
>> channel. It works well for discussions.
>> If anyone else would like to follow-along, then that's the place.
>>
>> [1]: https://forum.djangoproject.com
>>
>> We can post more occasional updates to the list here.
>>
>> I'd like to welcome Ahmad and Kacper — we're looking forward to working
>> with you!
>>
>> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/07b2ec6e-dfff-4272-b3e9-9b38ff5876da%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFfZ%2Bb5PELu6u0XBsF2jxoTRUsVp8P3%3DbYFRKC5U-v6ubVFOLA%40mail.gmail.com.

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Ryan Hiebert]

I can agree that there might be better things to do, but this falls into
the category of warts for me, so I'm +1. Having the name be pythonic is a
plus, but avoiding a beginner footgun is better.

And I believe the conventions used did indeed come from PHP. There even
used to be a parallel to `$_REQUEST`.
https://code.djangoproject.com/ticket/18659

On Wed, May 6, 2020, 04:07 Tom Carrick  wrote:

> > This often confuses beginners and “returners” alike.
>
> I'm neither a beginner nor returner and I still have to remind myself that
> request.POST doesn't contain my JSON data.
>
> I think it's a positive change. I agree there are things that would
> provide a better ROI, but people have to be willing to do them. I also
> think there's no harm in tackling things with a lower ROI.
>
> Tom
>
> On Wed, 6 May 2020 at 10:49, Steven Mapes  wrote:
>
>> Ah yes that's true, totally forgot about *request.body*  just then even
>> though I was using it a few days ago. So yes renaming it would help in that
>> regard as I do remember seeing a few S/O question where it's confused
>> people in the past.
>>
>> *Mr Steven Mapes*
>> Software Development and Solutions
>> E: st...@jigsawtech.co.uk
>> P: 07974220046
>> W: https://uk.linkedin.com/in/stevemapes/
>> [image: Twitter] 
>>
>> This E-Mail and its contents are confidential, protected by law and
>> legally privileged. Only access by the addressee is authorised. Any
>> liability (in negligence, contract or otherwise) arising from any third
>> party taking any action or refraining from taking any action on the basis
>> of any of the information contained in this E-Mail is hereby excluded to
>> the fullest extent of the law. In the event that you are not the addressee,
>> please notify the sender immediately. Do not discuss, disclose the contents
>> to any person or store or copy the information in any medium or use it for
>> any purpose whatsoever.
>> On May 6 2020, at 9:43 am, Adam Johnson  wrote:
>>
>> I always took the capitalisation of GET &co to come from HTTP
>>  — I'd say that's where PHP
>> took it from too but 🤷‍♀️
>>
>>
>> Yes GET and POST are capitalized in HTTP, but then COOKIES is not
>> (Set-Cookie / Cookies headers), and FILES and META aren't direct references
>> to anything in HTTP.
>>
>> Also I'm not sure it's a particularly good argument. Capitalization
>> inside Python should be based upon the conventions of Python, not the
>> conventions of the system the code talks to. For example, we have SELECT
>> ... FOR UPDATE in SQL, but .select_for_update() in the ORM.
>>
>>
>> Hmmm. I have to say I think there are areas where we could get a better
>> ROI on our time than this.
>>
>>
>> I think if we took the amount of time spent by users due to the confusion
>> of GET/POST, divided by the amount of time to make the code and docs
>> changes, it would come out with a relatively good ratio.
>>
>> My inspiration (or "the final straw") for making this proposal was a
>> recent forum question with confusion on the meaning of POST:
>> https://forum.djangoproject.com/t/ajax-post-to-view-not-displaying-content/2034
>>  .
>> I'm pretty sure I saw another one in the past month but can't find it But
>> it's an issue I've seen repeatedly. I know I've even spent time figuring
>> out how I'd get the query params during a POST request.
>>
>> please do not use *request.form_data* as that is also misleading as you
>> can POST many more sources than form data such as with APIs. post_data
>> would be much clearer.
>>
>>
>> Steven - I think you're confused by the current name. request.POST *only*
>> contains POST'd form data. It does not contain other POST'd data, such as
>> JSON bodies. So perahps that's another point for the name change?
>>
>> On Wed, 6 May 2020 at 09:29, Steven Mapes  wrote:
>>
>> Combined them would be very very bad and you would have the same problems
>> as with $_REQUEST in PHP where you have to decide which one wins as you can
>> make a POST to a URL with querystring where one of the parameters uses the
>> same name as a element of the POST and but where the value is different.
>> It's bad practice but it's valid
>>
>>
>> On Wednesday, 6 May 2020 08:00:56 UTC+1, Jure Erznožnik wrote:
>>
>> I agree. If anything, I've always had issues with GET & POST being
>> different entities in the first place, but never with their names. I would
>> really like to see an entity combining both of them. THAT one, maybe the
>> preferred way of doing so, would be lowercase, but RAW representations of
>> incoming data, I for one like them being upper case. Always makes me think
>> twice before playing with them.
>>
>> The content negotiation thingy is also something I would like to see more
>> time invested in: I have a project where I have to hack & slash DRF's
>> implementation in order to get what I want, but perhaps I'm tackling the
>> issue incorrectly. But that's beside the point. People will always

Re: Selected projects for Google Summer of Code 2020

[Sage M. Abdullah]

Thanks, Carlton, for the briefing!

I agree it's a good idea to utilize the forum for discussions. Aside from 
the forum and GitHub, I'd suggest Ahmad and Kacper start a blog if you 
haven't already, and write about your GSoC Journey there. I'm sure folks 
would enjoy reading how you learn and implement stuff along the way. You 
can also use it as a portfolio in the future. As Carlton said, we had a lot 
of applications, so I think getting selected is quite an achievement. Make 
the most of it for your future endeavors.

You can use a static site generator like Jekyll or Hugo and use GitHub 
pages to get it up and running quickly. Starting a blog is just a 
suggestion, it's okay if you don't feel like it :)

I was also a GSoC student with Django just last year so I'm still quite new 
to a lot of things as well, but I'll try to help the best I can.

So, congrats Ahmad and Kacper, looking forward to working with you!

Regards,
Sage


On Wednesday, 6 May 2020 13:46:26 UTC+7, Carlton Gibson wrote:
>
> Hi all. 
>
> We had lots of applications for GSoC, and lots of folks to act as mentors, 
> so I want to 
> thank everyone there.
>
> Django was accepted into GSoC. We were granted two slots. Thus for 2020, 
> two student proposals were selected:
>
> * Kacper Szmigiel, an undergraduate student at Technical University of 
> Lodz in Poland, will work on a refactor of the mypy plugin plugin that is 
> part of [django-stubs][0]. His primary mentors are Nikita Sobolev, and 
> Artem Malyshev, maintainers of django-stubs. 
>
> [0]: https://github.com/typeddjango/django-stubs
>
> * Ahmad A. Hussein, an undergraduate student German University in Cairo, 
> will work to extend the parallel test runner to Windows, macOS, and add 
> Oracle support. His primary mentors are Tom Forbes and Adam Johnson. 
>
> Additional mentors are Shai Berger, Simon Charette, Sage Abdullah, David 
> Smith, Mariusz Felisiak, and Carlton Gibson.
> (I allocated us to the projects for the application phase but we can 
> adjust.)
>
> My plan/hope/thought is to use the Forum[1] as the primary communication 
> channel. It works well for discussions. 
> If anyone else would like to follow-along, then that's the place. 
>
> [1]: https://forum.djangoproject.com
>
> We can post more occasional updates to the list here.
>
> I'd like to welcome Ahmad and Kacper — we're looking forward to working 
> with you!
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/07b2ec6e-dfff-4272-b3e9-9b38ff5876da%40googlegroups.com.

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Tom Carrick]

> This often confuses beginners and “returners” alike.

I'm neither a beginner nor returner and I still have to remind myself that
request.POST doesn't contain my JSON data.

I think it's a positive change. I agree there are things that would provide
a better ROI, but people have to be willing to do them. I also think
there's no harm in tackling things with a lower ROI.

Tom

On Wed, 6 May 2020 at 10:49, Steven Mapes  wrote:

> Ah yes that's true, totally forgot about *request.body*  just then even
> though I was using it a few days ago. So yes renaming it would help in that
> regard as I do remember seeing a few S/O question where it's confused
> people in the past.
>
> *Mr Steven Mapes*
> Software Development and Solutions
> E: st...@jigsawtech.co.uk
> P: 07974220046
> W: https://uk.linkedin.com/in/stevemapes/
> [image: Twitter] 
>
> This E-Mail and its contents are confidential, protected by law and
> legally privileged. Only access by the addressee is authorised. Any
> liability (in negligence, contract or otherwise) arising from any third
> party taking any action or refraining from taking any action on the basis
> of any of the information contained in this E-Mail is hereby excluded to
> the fullest extent of the law. In the event that you are not the addressee,
> please notify the sender immediately. Do not discuss, disclose the contents
> to any person or store or copy the information in any medium or use it for
> any purpose whatsoever.
> On May 6 2020, at 9:43 am, Adam Johnson  wrote:
>
> I always took the capitalisation of GET &co to come from HTTP
>  — I'd say that's where PHP
> took it from too but 🤷‍♀️
>
>
> Yes GET and POST are capitalized in HTTP, but then COOKIES is not
> (Set-Cookie / Cookies headers), and FILES and META aren't direct references
> to anything in HTTP.
>
> Also I'm not sure it's a particularly good argument. Capitalization inside
> Python should be based upon the conventions of Python, not the conventions
> of the system the code talks to. For example, we have SELECT ... FOR UPDATE
> in SQL, but .select_for_update() in the ORM.
>
>
> Hmmm. I have to say I think there are areas where we could get a better
> ROI on our time than this.
>
>
> I think if we took the amount of time spent by users due to the confusion
> of GET/POST, divided by the amount of time to make the code and docs
> changes, it would come out with a relatively good ratio.
>
> My inspiration (or "the final straw") for making this proposal was a
> recent forum question with confusion on the meaning of POST:
> https://forum.djangoproject.com/t/ajax-post-to-view-not-displaying-content/2034
>  .
> I'm pretty sure I saw another one in the past month but can't find it But
> it's an issue I've seen repeatedly. I know I've even spent time figuring
> out how I'd get the query params during a POST request.
>
> please do not use *request.form_data* as that is also misleading as you
> can POST many more sources than form data such as with APIs. post_data
> would be much clearer.
>
>
> Steven - I think you're confused by the current name. request.POST *only*
> contains POST'd form data. It does not contain other POST'd data, such as
> JSON bodies. So perahps that's another point for the name change?
>
> On Wed, 6 May 2020 at 09:29, Steven Mapes  wrote:
>
> Combined them would be very very bad and you would have the same problems
> as with $_REQUEST in PHP where you have to decide which one wins as you can
> make a POST to a URL with querystring where one of the parameters uses the
> same name as a element of the POST and but where the value is different.
> It's bad practice but it's valid
>
>
> On Wednesday, 6 May 2020 08:00:56 UTC+1, Jure Erznožnik wrote:
>
> I agree. If anything, I've always had issues with GET & POST being
> different entities in the first place, but never with their names. I would
> really like to see an entity combining both of them. THAT one, maybe the
> preferred way of doing so, would be lowercase, but RAW representations of
> incoming data, I for one like them being upper case. Always makes me think
> twice before playing with them.
>
> The content negotiation thingy is also something I would like to see more
> time invested in: I have a project where I have to hack & slash DRF's
> implementation in order to get what I want, but perhaps I'm tackling the
> issue incorrectly. But that's beside the point. People will always try to
> do stuff framework developers didn't think of. What's important is to give
> them a platform where they can do so easily.
>
> LP,
> Jure
>
> On 06/05/2020 08:08, Carlton Gibson wrote:
>
> Hmmm. I have to say I think there are areas where we could get a better
> ROI on our time than this.
>
> I always took the capitalisation of GET &co to come from HTTP
>  — I'd say that's where PHP
> took it from too but 🤷‍♀️
> That they're a bit "unpythonic" (Meh

Re: Removing url() ?

[Alasdair Nicol]

Hi,

On Tuesday, 5 May 2020 21:39:35 UTC+1, James Bennett wrote:
>
>
> There's also no reason why url() in particular should be given special 
> treatment that other deprecated features or APIs don't get. Some other 
> old-time bits went far more quickly: render_to_response(), for example, got 
> the standard deprecation cycle, and was removed for good in 3.0. The old 
> django.core.urlresolvers module went away in 2.0. We've also long since 
> gotten rid of the patterns() helper in favor of just defining URLs as a 
> standard Python list. All of those were "useless code churn" -- the 
> previous functions/modules worked just fine, after all. But they're all 
> gone, and if you run on a supported Django version you've either dealt with 
> those changes or (in the case of render_to_response()) will deal with them 
> sometime in the near future.
>
>
render_to_response was superseded by render in 1.3, but it wasn't removed 
until Django 3.0. The discussion on deprecating it is here [1].

In retrospect I think we should have removed it sooner, because I saw many 
beginners getting CSRF errors when they used render_to_response without 
context_instance=RequestContext(request). 

I'm in favour of removing url() in 4.0. I think it's less likely to catch 
out users than render_to_response, but I do see beginners doing things like 
url('', ...). If we remove url() then some of that will be avoided. 
Hopefully we won't see too many occurrences of path(r'(?P\d+)', ...)' 
instead.

Cheers,
Alasdair

[1]: https://groups.google.com/d/msg/django-developers/-SeUjUbOfKQ/p6IMnJxuDQAJ

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fe1446f4-21b9-45b5-8b9d-089f97302a5a%40googlegroups.com.

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Steven Mapes]

Ah yes that's true, totally forgot about request.body just then even though I 
was using it a few days ago. So yes renaming it would help in that regard as I 
do remember seeing a few S/O question where it's confused people in the past.

Mr Steven Mapes
Software Development and Solutions

E: st...@jigsawtech.co.uk (mailto:st...@jigsawtech.co.uk)
P: 07974220046 (tel:07974220046)
W: https://uk.linkedin.com/in/stevemapes/

This E-Mail and its contents are confidential, protected by law and legally 
privileged. Only access by the addressee is authorised. Any liability (in 
negligence, contract or otherwise) arising from any third party taking any 
action or refraining from taking any action on the basis of any of the 
information contained in this E-Mail is hereby excluded to the fullest extent 
of the law. In the event that you are not the addressee, please notify the 
sender immediately. Do not discuss, disclose the contents to any person or 
store or copy the information in any medium or use it for any purpose 
whatsoever.

On May 6 2020, at 9:43 am, Adam Johnson  wrote:
> > I always took the capitalisation of GET &co to come from HTTP 
> > (https://tools.ietf.org/html/rfc2616#page-36) — I'd say that's where PHP 
> > took it from too but 🤷‍♀️
> >
>
>
> Yes GET and POST are capitalized in HTTP, but then COOKIES is not (Set-Cookie 
> / Cookies headers), and FILES and META aren't direct references to anything 
> in HTTP.
>
> Also I'm not sure it's a particularly good argument. Capitalization inside 
> Python should be based upon the conventions of Python, not the conventions of 
> the system the code talks to. For example, we have SELECT ... FOR UPDATE in 
> SQL, but .select_for_update() in the ORM.
>
> > Hmmm. I have to say I think there are areas where we could get a better ROI 
> > on our time than this.
>
>
> I think if we took the amount of time spent by users due to the confusion of 
> GET/POST, divided by the amount of time to make the code and docs changes, it 
> would come out with a relatively good ratio.
>
> My inspiration (or "the final straw") for making this proposal was a recent 
> forum question with confusion on the meaning of POST: 
> https://forum.djangoproject.com/t/ajax-post-to-view-not-displaying-content/2034
>  . I'm pretty sure I saw another one in the past month but can't find it But 
> it's an issue I've seen repeatedly. I know I've even spent time figuring out 
> how I'd get the query params during a POST request.
>
> > please do not use request.form_data as that is also misleading as you can 
> > POST many more sources than form data such as with APIs. post_data would be 
> > much clearer.
>
> Steven - I think you're confused by the current name. request.POST *only* 
> contains POST'd form data. It does not contain other POST'd data, such as 
> JSON bodies. So perahps that's another point for the name change?
> On Wed, 6 May 2020 at 09:29, Steven Mapes  (mailto:st...@jigsawtech.co.uk)> wrote:
> > Combined them would be very very bad and you would have the same problems 
> > as with $_REQUEST in PHP where you have to decide which one wins as you can 
> > make a POST to a URL with querystring where one of the parameters uses the 
> > same name as a element of the POST and but where the value is different. 
> > It's bad practice but it's valid
> >
> >
> > On Wednesday, 6 May 2020 08:00:56 UTC+1, Jure Erznožnik wrote:
> > > I agree. If anything, I've always had issues with GET & POST being 
> > > different entities in the first place, but never with their names. I 
> > > would really like to see an entity combining both of them. THAT one, 
> > > maybe the preferred way of doing so, would be lowercase, but RAW 
> > > representations of incoming data, I for one like them being upper case. 
> > > Always makes me think twice before playing with them.
> > >
> > >
> > > The content negotiation thingy is also something I would like to see more 
> > > time invested in: I have a project where I have to hack & slash DRF's 
> > > implementation in order to get what I want, but perhaps I'm tackling the 
> > > issue incorrectly. But that's beside the point. People will always try to 
> > > do stuff framework developers didn't think of. What's important is to 
> > > give them a platform where they can do so easily.
> > > LP,
> > > Jure
> > >
> > >
> > > On 06/05/2020 08:08, Carlton Gibson wrote:
> > > > Hmmm. I have to say I think there are areas where we could get a better 
> > > > ROI on our time than this.
> > > >
> > > >
> > > > I always took the capitalisation of GET &co to come from HTTP 
> > > > (https://tools.ietf.org/html/rfc2616#page-36) — I'd say that's where 
> > > > PHP took it from too but 🤷‍♀️
> > > > That they're a bit "unpythonic" (Meh™) is OK: they serve to remind that 
> > > > request was ultimately mapped from an HTTP request, and most of that is 
> > > > still available if you care to dig.
> > > >
> > > >
> > > > 
> > > >
> > > > Then request.form_data -> Oh, where's my form data

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Adam Johnson]

>
> I always took the capitalisation of GET &co to come from HTTP
>  — I'd say that's where PHP
> took it from too but 🤷‍♀️
>

Yes GET and POST are capitalized in HTTP, but then COOKIES is not
(Set-Cookie / Cookies headers), and FILES and META aren't direct references
to anything in HTTP.

Also I'm not sure it's a particularly good argument. Capitalization inside
Python should be based upon the conventions of Python, not the conventions
of the system the code talks to. For example, we have SELECT ... FOR UPDATE
in SQL, but .select_for_update() in the ORM.


> Hmmm. I have to say I think there are areas where we could get a better
> ROI on our time than this.
>

I think if we took the amount of time spent by users due to the confusion
of GET/POST, divided by the amount of time to make the code and docs
changes, it would come out with a relatively good ratio.

My inspiration (or "the final straw") for making this proposal was a recent
forum question with confusion on the meaning of POST:
https://forum.djangoproject.com/t/ajax-post-to-view-not-displaying-content/2034
. I'm pretty sure I saw another one in the past month but can't find it But
it's an issue I've seen repeatedly. I know I've even spent time figuring
out how I'd get the query params during a POST request.

please do not use *request.form_data* as that is also misleading as you can
> POST many more sources than form data such as with APIs. post_data would be
> much clearer.


Steven - I think you're confused by the current name. request.POST *only*
contains POST'd form data. It does not contain other POST'd data, such as
JSON bodies. So perahps that's another point for the name change?

On Wed, 6 May 2020 at 09:29, Steven Mapes  wrote:

> Combined them would be very very bad and you would have the same problems
> as with $_REQUEST in PHP where you have to decide which one wins as you can
> make a POST to a URL with querystring where one of the parameters uses the
> same name as a element of the POST and but where the value is different.
> It's bad practice but it's valid
>
>
> On Wednesday, 6 May 2020 08:00:56 UTC+1, Jure Erznožnik wrote:
>>
>> I agree. If anything, I've always had issues with GET & POST being
>> different entities in the first place, but never with their names. I would
>> really like to see an entity combining both of them. THAT one, maybe the
>> preferred way of doing so, would be lowercase, but RAW representations of
>> incoming data, I for one like them being upper case. Always makes me think
>> twice before playing with them.
>>
>> The content negotiation thingy is also something I would like to see more
>> time invested in: I have a project where I have to hack & slash DRF's
>> implementation in order to get what I want, but perhaps I'm tackling the
>> issue incorrectly. But that's beside the point. People will always try to
>> do stuff framework developers didn't think of. What's important is to give
>> them a platform where they can do so easily.
>>
>> LP,
>> Jure
>> On 06/05/2020 08:08, Carlton Gibson wrote:
>>
>> Hmmm. I have to say I think there are areas where we could get a better
>> ROI on our time than this.
>>
>> I always took the capitalisation of GET &co to come from HTTP
>>  — I'd say that's where PHP
>> took it from too but 🤷‍♀️
>> That they're a bit "unpythonic" (Meh™) is OK: they serve to remind that
>> request was ultimately mapped from an HTTP request, and most of that is
>> still available if you care to dig.
>>
>> 
>>
>> Then request.form_data -> Oh, where's my form data, if not in
>> "form_data"? Well it's in "query_params"... Hmmm
>> That's no better learning experience. Folks still have to learn how HTTP
>> maps to request properties.
>>
>> > ... better ROI...
>>
>> There's lots we might take from DRF. The one that's come up before, and
>> which for work was began, but only began, was content negotiation.
>> I'd rather see work/energy/effort spent there.
>>
>> Maybe we'd have different names if we began today. But this would be very
>> disruptive.
>> We've just had a discussion re url() suggesting that "deprecated but not
>> really" is an error on our part, and having two ways to do things
>> definitely isn't "pythonic".
>> So I'm inclined towards the range between -1 and -0 — but I haven't had
>> my coffee yet. 😝
>>
>> 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-d...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/bc60e809-6390-44fc-a07a-ed6e0f9eef86%40googlegroups.com
>> 
>> .

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Steven Mapes]

Combined them would be very very bad and you would have the same problems 
as with $_REQUEST in PHP where you have to decide which one wins as you can 
make a POST to a URL with querystring where one of the parameters uses the 
same name as a element of the POST and but where the value is different. 
It's bad practice but it's valid


On Wednesday, 6 May 2020 08:00:56 UTC+1, Jure Erznožnik wrote:
>
> I agree. If anything, I've always had issues with GET & POST being 
> different entities in the first place, but never with their names. I would 
> really like to see an entity combining both of them. THAT one, maybe the 
> preferred way of doing so, would be lowercase, but RAW representations of 
> incoming data, I for one like them being upper case. Always makes me think 
> twice before playing with them.
>
> The content negotiation thingy is also something I would like to see more 
> time invested in: I have a project where I have to hack & slash DRF's 
> implementation in order to get what I want, but perhaps I'm tackling the 
> issue incorrectly. But that's beside the point. People will always try to 
> do stuff framework developers didn't think of. What's important is to give 
> them a platform where they can do so easily.
>
> LP,
> Jure
> On 06/05/2020 08:08, Carlton Gibson wrote:
>
> Hmmm. I have to say I think there are areas where we could get a better 
> ROI on our time than this. 
>
> I always took the capitalisation of GET &co to come from HTTP 
>  — I'd say that's where PHP 
> took it from too but 🤷‍♀️
> That they're a bit "unpythonic" (Meh™) is OK: they serve to remind that 
> request was ultimately mapped from an HTTP request, and most of that is 
> still available if you care to dig. 
>
>  
>
> Then request.form_data -> Oh, where's my form data, if not in "form_data"? 
> Well it's in "query_params"... Hmmm
> That's no better learning experience. Folks still have to learn how HTTP 
> maps to request properties. 
>
> > ... better ROI... 
>
> There's lots we might take from DRF. The one that's come up before, and 
> which for work was began, but only began, was content negotiation. 
> I'd rather see work/energy/effort spent there. 
>
> Maybe we'd have different names if we began today. But this would be very 
> disruptive. 
> We've just had a discussion re url() suggesting that "deprecated but not 
> really" is an error on our part, and having two ways to do things 
> definitely isn't "pythonic". 
> So I'm inclined towards the range between -1 and -0 — but I haven't had my 
> coffee yet. 😝
>
> 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-d...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/bc60e809-6390-44fc-a07a-ed6e0f9eef86%40googlegroups.com
>  
> 
> .
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b23d3b4a-9ff4-42ed-a08b-594f185b8d3b%40googlegroups.com.

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Steven Mapes]

I also thought it was a taken more form HTTP rather than PHP but if this is 
changed please do not use *request.form_data* as that is also misleading as 
you can POST many more sources than form data such as with APIs. post_data 
would be much clearer.

On Tuesday, 5 May 2020 22:26:34 UTC+1, Adam Johnson wrote:
>
> request.GET and request.POST are misleadingly named:
>
>- GET contains the URL parameters and is therefore available whatever 
>the request method. This often confuses beginners and “returners” alike.
>- POST contains form data on POST requests, but not other kinds of 
>data from POST requests. It can confuse users who are posting JSON or 
> other 
>formats.
>
> Additionally both names can lead users to think e.g. "if request.GET:" 
> means "if this is a GET request", which is not true.
>
> I believe the CAPITALIZED naming style was inherited from PHP's global 
> variables $_GET, $_POST, $_FILES etc. ( 
> https://www.php.net/manual/en/reserved.variables.get.php ). It stands out 
> as unpythonic, since these are instance variables and not module-level 
> constants (as per PEP8 https://www.python.org/dev/peps/pep-0008/#constants 
> ).
>
> I therefore propose these renames:
>
>- request.GET -> request.query_params (to match Django Rest Framework 
>- see below)
>- request.POST -> request.form_data
>- request.FILES -> request.files
>- request.COOKIES -> request.cookies
>- request.META -> request.meta
>
> Since these are very core attributes and the change would cause a huge 
> amount of churn, I propose not deprecating the old aliases immediately, but 
> leaving them in with a documentation note that they "may be deprecated." 
> Perhaps they can be like url() or ifequal which came up on the mailing list 
> recently - put through the normal deprecation path after a few releases 
> with such a note.
>
> Django Rest Framework already aliases GET as request.query_params in its 
> request wrapper: 
> https://www.django-rest-framework.org/api-guide/requests/#query_params . 
> Therefore the name request.query_params should not be surprising. DRF also 
> provides request.data which combines request.POST and request.FILES, and 
> flexibly parses from different content types, but I'm not sure that's 
> feasible to implement in Django core.
>
> For reference, other Python web frameworks have more "Pythonic" naming:
>
>- Bottle: request.url_args, request.forms, request.files, 
>request.cookies, request.environ
>- Flask: request.args, request.form, request.files, request.cookies, 
>request.environ
>- Starlette: request.query_params, request.form(), 
>request.form()[field_name], request.cookies, scope
>
> One more note for those who might think such core attributes should be 
> left alone: Django 2.2 added request.headers as a way of accessing headers 
> by name. This is convenient as it avoids the need to transform the header 
> to the WSGI environ name. makes the code more readable, and in the process 
> reduces the potential for bugs. I believe this proposal is in the same vein.
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3c6309ad-1af5-4c57-afa1-0c754143eb2f%40googlegroups.com.

Re: Removing url() ?

[Steven Mapes]

This is the big thing for me which seems to be have been forgotten.

If you need to quickly upgrade a Django project from using url to re_path 
the fastest way with the least amount of code changes is to simply alias 
the import in your urls.py files I.E ```from django.urls import re_path as 
url``` then you won't have to update every individual entry. so I don't see 
this as a big deal and am in favour of completely removing it and continue 
to encourage people to not question why they are using re_path and not path 
anyway which is more secure and fits more common url usage.

Sure if you are going from 1.x up then you have to replace  more but you'll 
be making much larger changes anyway.



On Tuesday, 5 May 2020 19:13:30 UTC+1, James Bennett wrote:
>
> On Tue, May 5, 2020 at 9:45 AM ‫אורי‬‎ > 
> wrote:‬ 
> > My project contains about 100 calls to url() with regex. Can you explain 
> to me what has been changed and why, and how should I change my code to 
> stop using url()? And where is it documented? I checked the documentation 
> and I didn't find an explanation why url() was changed and what are the 
> differences between url() and path() and re_path()? 
>
> There is no difference; django.conf.urls.url() is just an alias for 
> django.urls.re_path(). 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0abf4520-a85a-431d-a6d6-58c98118958d%40googlegroups.com.

Status of 3.1 release blockers.

[Mariusz Felisiak]

Hi y'all,

Time to begin release process for the next major release, Django 3.1!

The 3.1 feature freeze is scheduled (according to 
https://code.djangoproject.com/wiki/Version3.1Roadmap) for May 11. We'll 
probably release the alpha a few days later.

We have a few larger patches we want to finish reviewing:

https://github.com/django/django/pull/12392 - Fixed #12990, Refs #27694 -- 
Added JSONField model field.
https://github.com/django/django/pull/12851 - Fixed #25236 -- Deprecated {% 
ifequal %} and {% ifnotequal %} template tags.
https://github.com/django/django/pull/12159 - Fixed #31034 -- Added a 
navigation sidebar to the admin.

Best,
Mariusz

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/77fd1697-76f2-413a-9242-0cc97eefe696%40googlegroups.com.

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Raffaele Salmaso]

For me it's a good move (the best would be to have request.data as with
DRF).
I've done this kind of "upgrade" from Django request.{GET,POST} to DRF
request.{query_params,data} and it was quite trivial (search and replace).
At the same time it forced me to check the code for correctnes, and I found
a couple of (unrelated) bugs.
For me I'll add the alias as soon as possible (3.1?), use them in
documentation, and start the deprecation after an LTS release (4.0? 5.0?),
so there would be plenty of time to upgrade.

On Tue, May 5, 2020 at 11:26 PM Adam Johnson  wrote:

> request.GET and request.POST are misleadingly named:
>
>- GET contains the URL parameters and is therefore available whatever
>the request method. This often confuses beginners and “returners” alike.
>- POST contains form data on POST requests, but not other kinds of
>data from POST requests. It can confuse users who are posting JSON or other
>formats.
>
> Additionally both names can lead users to think e.g. "if request.GET:"
> means "if this is a GET request", which is not true.
>
> I believe the CAPITALIZED naming style was inherited from PHP's global
> variables $_GET, $_POST, $_FILES etc. (
> https://www.php.net/manual/en/reserved.variables.get.php ). It stands out
> as unpythonic, since these are instance variables and not module-level
> constants (as per PEP8 https://www.python.org/dev/peps/pep-0008/#constants
> ).
>
> I therefore propose these renames:
>
>- request.GET -> request.query_params (to match Django Rest Framework
>- see below)
>- request.POST -> request.form_data
>- request.FILES -> request.files
>- request.COOKIES -> request.cookies
>- request.META -> request.meta
>
> Since these are very core attributes and the change would cause a huge
> amount of churn, I propose not deprecating the old aliases immediately, but
> leaving them in with a documentation note that they "may be deprecated."
> Perhaps they can be like url() or ifequal which came up on the mailing list
> recently - put through the normal deprecation path after a few releases
> with such a note.
>
> Django Rest Framework already aliases GET as request.query_params in its
> request wrapper:
> https://www.django-rest-framework.org/api-guide/requests/#query_params .
> Therefore the name request.query_params should not be surprising. DRF also
> provides request.data which combines request.POST and request.FILES, and
> flexibly parses from different content types, but I'm not sure that's
> feasible to implement in Django core.
>
> For reference, other Python web frameworks have more "Pythonic" naming:
>
>- Bottle: request.url_args, request.forms, request.files,
>request.cookies, request.environ
>- Flask: request.args, request.form, request.files, request.cookies,
>request.environ
>- Starlette: request.query_params, request.form(),
>request.form()[field_name], request.cookies, scope
>
> One more note for those who might think such core attributes should be
> left alone: Django 2.2 added request.headers as a way of accessing headers
> by name. This is convenient as it avoids the need to transform the header
> to the WSGI environ name. makes the code more readable, and in the process
> reduces the potential for bugs. I believe this proposal is in the same vein.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM3%2BUucViDezhkWrFsk6ZsKViWjOgtA5aBm9pnzozdc%2Beg%40mail.gmail.com
> 
> .
>


-- 
| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABgH4Jvf7J0JOtdnXVGrR1Sg7-Q1q7TbUcGswMvmKKw-AwPd%3Dg%40mail.gmail.com.

Re: Removing url() ?

[אורי]

Thank you, Carlton.
אורי
u...@speedy.net


On Wed, May 6, 2020 at 10:06 AM Carlton Gibson 
wrote:

> Hi Uri.
>
> On 6 May 2020, at 08:32, ⁨אורי⁩ <⁨u...@speedy.net⁩> wrote:
>
> Although I'm not sure why it was deprecated and renamed to re_path().
>
>
> It was part of the effort to simplify the URL routing, as part of Django
> 2.0
>
>
> https://docs.djangoproject.com/en/3.0/releases/2.0/#simplified-url-routing-syntax
>
> Here’s the DEP that led to that:
>
>
> https://github.com/django/deps/blob/master/final/0201-simplified-routing-syntax.rst
>
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3E395185-94A5-4789-A319-0032B57D3F0A%40gmail.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABD5YeH9Vk%2BbEOWN5wk04Jq%3DhM2_iF2P0OWLGZoE5AmA2N4zxw%40mail.gmail.com.

Re: Removing url() ?

[Carlton Gibson]

Hi Uri. 

> On 6 May 2020, at 08:32, ⁨אורי⁩ <⁨u...@speedy.net⁩> wrote:
> 
> Although I'm not sure why it was deprecated and renamed to re_path().

It was part of the effort to simplify the URL routing, as part of Django 2.0

https://docs.djangoproject.com/en/3.0/releases/2.0/#simplified-url-routing-syntax
 


Here’s the DEP that led to that: 

https://github.com/django/deps/blob/master/final/0201-simplified-routing-syntax.rst
 


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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3E395185-94A5-4789-A319-0032B57D3F0A%40gmail.com.

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Jure Erznožnik]

I agree. If anything, I've always had issues with GET & POST being 
different entities in the first place, but never with their names. I 
would really like to see an entity combining both of them. THAT one, 
maybe the preferred way of doing so, would be lowercase, but RAW 
representations of incoming data, I for one like them being upper case. 
Always makes me think twice before playing with them.


The content negotiation thingy is also something I would like to see 
more time invested in: I have a project where I have to hack & slash 
DRF's implementation in order to get what I want, but perhaps I'm 
tackling the issue incorrectly. But that's beside the point. People will 
always try to do stuff framework developers didn't think of. What's 
important is to give them a platform where they can do so easily.


LP,
Jure

On 06/05/2020 08:08, Carlton Gibson wrote:
Hmmm. I have to say I think there are areas where we could get a 
better ROI on our time than this.


I always took the capitalisation of GET &co to come from HTTP 
 — I'd say that's where 
PHP took it from too but 🤷‍♀️
That they're a bit "unpythonic" (Meh™) is OK: they serve to remind 
that request was ultimately mapped from an HTTP request, and most of 
that is still available if you care to dig.




Then request.form_data -> Oh, where's my form data, if not in 
"form_data"? Well it's in "query_params"... Hmmm
That's no better learning experience. Folks still have to learn how 
HTTP maps to request properties.


> ... better ROI...

There's lots we might take from DRF. The one that's come up before, 
and which for work was began, but only began, was content negotiation.

I'd rather see work/energy/effort spent there.

Maybe we'd have different names if we began today. But this would be 
very disruptive.
We've just had a discussion re url() suggesting that "deprecated but 
not really" is an error on our part, and having two ways to do things 
definitely isn't "pythonic".
So I'm inclined towards the range between -1 and -0 — but I haven't 
had my coffee yet. 😝


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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bc60e809-6390-44fc-a07a-ed6e0f9eef86%40googlegroups.com 
.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/34e930da-e775-8a9d-6af3-1ae0ede3dfcd%40gmail.com.