Re: Proposal: Track used headers and use that information to automatically populate Vary header.

[Dan Davis]

On Fri, Jan 25, 2019 at 8:27 PM James Bennett  wrote:

> My immediate thought here is: if people already aren't taking the time to
> patch using the existing mechanism, they also aren't going to take the time
> to opt out of patching. So what you're proposing is effectively still "any
> accessed header patches Vary". And that seems like it's as bad as the
> problem it's trying to solve.
>

The people who do take the time to patch the Vary header probably can
easily adapt to the new mechanism, its the people who don't take the time
to do this that we can help with such a feature.

-- 
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/CAFzonYafego8WvaQNss46%3DeeSsdvxFKa%2B-F-4-Dzj7guz5Kqmw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Track used headers and use that information to automatically populate Vary header.

[James Bennett]

On Fri, Jan 25, 2019 at 9:39 AM Linus Lewandowski <
linus.lewandow...@netguru.co> wrote:

> True, probably a way to access headers without marking them as used would
> be required - maybe something like request.headers.get(XYZ,
> vary_response=False).
>
> However, right now people are commonly forgetting to patch Vary, which
> leads to problems with caching. This way - this won't happen ever again;
> but in some cases, we might make caching less efficient than possible,
> because somebody used request.headers[XYZ] and not request.headers.get(XYZ,
> vary_response=False). Given these two cases - I feel that working correctly
> is more important than perfectly-efficient caching - but opinions here may
> differ.
>

My immediate thought here is: if people already aren't taking the time to
patch using the existing mechanism, they also aren't going to take the time
to opt out of patching. So what you're proposing is effectively still "any
accessed header patches Vary". And that seems like it's as bad as the
problem it's trying to solve.

-- 
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/CAL13Cg-m7QgGbvFvX89Sd5UMz1HgTmKOiU8sdBZ_zoRRNNuk_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Track used headers and use that information to automatically populate Vary header.

[Dan Davis]

I would like this - Django is a framework with batteries, and my
development group tells me "Django is too hard".  This is because they
don't understand HTTP; mostly they understand HTML/CSS and SQL, with maybe
some easy jquery level of SQL. So, this kind of solution would fit well for
my developers. The young engineers all love that we switched to Django,
however, so any such solution should be opt-out.

On Fri, Jan 25, 2019 at 10:56 AM Adam Johnson  wrote:

> Accessing the value of a header doesn't necessarily mean that the response
> varies based up on, for example it might simply be accessed for storage in
> informational logs. Additionally, Request.headers is not the only way to
> access the values now, Request.META has not been removed. I don't believe
> any of Django's internal header lookups have been changed to use
> Request.headers and it's unlike third party packages or applications will
> ever all be moved.
>
> Anyway I'm pretty sure you can write such a middleware yourself, replacing
> Request.headers with a proxy object (and maybe Request.META too), then
> adding 'Vary' on the way out based upon accessed keys, at least as a proof
> of concept. If it gets some usage that would prove it could be valuable to
> add to Django itself.
>
>
>
> On Fri, 25 Jan 2019 at 14:46, Linus Lewandowski <
> linus.lewandow...@netguru.pl> wrote:
>
>> Right now, it's hard to report Vary header correctly. Headers might get
>> accessed in many different places, like middlewares, subroutines (which
>> can't use patch_vary_headers as they don't have access to the response
>> object), etc - and all those cases should be reflected in the Vary header,
>> or something might get cached incorrectly.
>>
>> However, thanks to the newly added request.headers property (see
>> https://code.djangoproject.com/ticket/20147 and
>> https://github.com/django/django/commit/4fc35a9c3efdc9154efce28cb23cb84f8834517e),
>> we now have a single place which is used to access request headers. We can
>> track which ones were accessed, and then set Vary header automatically, for
>> example in a middleware.
>>
>> What do you think about:
>> 1) adding some code to track accessed headers in request.headers,
>> 2) adding a new middleware (or expanding an existing one), that sets the
>> Vary header based on 1),
>> 3) deprecating patch_vary_headers function
>> and vary_on_headers/vary_on_cookie decorators and recommending to use
>> request.headers instead?
>>
>> Thanks,
>> Linus
>>
>> PS. This is a follow-up to the
>> https://code.djangoproject.com/ticket/28533 ticket.
>>
>> --
>> 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/81484ff1-552e-4103-9fa8-8a3348512b84%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Adam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM3uDHaDywYFa6fM_-jJw8j81yoTP9%3DyLO2Rx2JDOk45jw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFzonYZV_oh4aotsZ9Suz6DQOx4-TMAZGrfdZshsnr%2BiUM6t9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Track used headers and use that information to automatically populate Vary header.

[Florian Apolloner]

While reading this thread https://code.djangoproject.com/ticket/19649 came 
to mind. I think most (if not all) from there basically is the same issue, 
even though that one just concerns itself with the Cookie header.

I do not agree that request.headers is __now__ the single place for 
accessing headers, that still seems to be request.META. So in that sense 
every argument for fixing this should probably not rely on request.headers, 
at least not as long as we still have headers in request.META.

Cheers,
Florian

On Friday, January 25, 2019 at 6:39:43 PM UTC+1, Linus Lewandowski wrote:
>
> > Accessing the value of a header doesn't necessarily mean that the 
> response varies based up on, for example it might simply be accessed for 
> storage in informational logs.
>
> True, probably a way to access headers without marking them as used would 
> be required - maybe something like request.headers.get(XYZ, 
> vary_response=False).
>
> However, right now people are commonly forgetting to patch Vary, which 
> leads to problems with caching. This way - this won't happen ever again; 
> but in some cases, we might make caching less efficient than possible, 
> because somebody used request.headers[XYZ] and not request.headers.get(XYZ, 
> vary_response=False). Given these two cases - I feel that working correctly 
> is more important than perfectly-efficient caching - but opinions here may 
> differ.
>
> > Additionally, Request.headers is not the only way to access the values 
> now, Request.META has not been removed. I don't believe any of Django's 
> internal header lookups have been changed to use Request.headers and it's 
> unlike third party packages or applications will ever all be moved.
>
> It's not, but we can assume that all this code uses patch_vary_headers 
> correctly, so we don't need to track it here. It's mostly about new code, 
> that's going to be written with request.headers, so that it will work 
> correctly without worrying about the Vary header.
>
> > Anyway I'm pretty sure you can write such a middleware yourself, 
> replacing Request.headers with a proxy object (and maybe Request.META too), 
> then adding 'Vary' on the way out based upon accessed keys, at least as a 
> proof of concept. If it gets some usage that would prove it could be 
> valuable to add to Django itself.
>
> I guess it isn't something that people are going to be looking for, it's 
> always easier to add that another patch_vary_headers invocation than to add 
> a new package, so the usage won't be high; but I'll probably do so, at 
> least for my own usage. I'm already using it in one project, and I need it 
> in others.
>
> On Fri, Jan 25, 2019 at 4:56 PM Adam Johnson > 
> wrote:
>
>>
>> On Fri, 25 Jan 2019 at 14:46, Linus Lewandowski > > wrote:
>>
>>> Right now, it's hard to report Vary header correctly. Headers might get 
>>> accessed in many different places, like middlewares, subroutines (which 
>>> can't use patch_vary_headers as they don't have access to the response 
>>> object), etc - and all those cases should be reflected in the Vary header, 
>>> or something might get cached incorrectly.
>>>
>>> However, thanks to the newly added request.headers property (see 
>>> https://code.djangoproject.com/ticket/20147 and 
>>> https://github.com/django/django/commit/4fc35a9c3efdc9154efce28cb23cb84f8834517e),
>>>  
>>> we now have a single place which is used to access request headers. We can 
>>> track which ones were accessed, and then set Vary header automatically, for 
>>> example in a middleware.
>>>
>>> What do you think about:
>>> 1) adding some code to track accessed headers in request.headers,
>>> 2) adding a new middleware (or expanding an existing one), that sets the 
>>> Vary header based on 1),
>>> 3) deprecating patch_vary_headers function 
>>> and vary_on_headers/vary_on_cookie decorators and recommending to use 
>>> request.headers instead?
>>>
>>> Thanks,
>>> Linus
>>>
>>> PS. This is a follow-up to the 
>>> https://code.djangoproject.com/ticket/28533 ticket.
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-develop...@googlegroups.com .
>>> To post to this group, send email to django-d...@googlegroups.com 
>>> .
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/81484ff1-552e-4103-9fa8-8a3348512b84%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>> Adam
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers 

Re: Proposal: Track used headers and use that information to automatically populate Vary header.

[Linus Lewandowski]

> Accessing the value of a header doesn't necessarily mean that the
response varies based up on, for example it might simply be accessed for
storage in informational logs.

True, probably a way to access headers without marking them as used would
be required - maybe something like request.headers.get(XYZ,
vary_response=False).

However, right now people are commonly forgetting to patch Vary, which
leads to problems with caching. This way - this won't happen ever again;
but in some cases, we might make caching less efficient than possible,
because somebody used request.headers[XYZ] and not request.headers.get(XYZ,
vary_response=False). Given these two cases - I feel that working correctly
is more important than perfectly-efficient caching - but opinions here may
differ.

> Additionally, Request.headers is not the only way to access the values
now, Request.META has not been removed. I don't believe any of Django's
internal header lookups have been changed to use Request.headers and it's
unlike third party packages or applications will ever all be moved.

It's not, but we can assume that all this code uses patch_vary_headers
correctly, so we don't need to track it here. It's mostly about new code,
that's going to be written with request.headers, so that it will work
correctly without worrying about the Vary header.

> Anyway I'm pretty sure you can write such a middleware yourself,
replacing Request.headers with a proxy object (and maybe Request.META too),
then adding 'Vary' on the way out based upon accessed keys, at least as a
proof of concept. If it gets some usage that would prove it could be
valuable to add to Django itself.

I guess it isn't something that people are going to be looking for, it's
always easier to add that another patch_vary_headers invocation than to add
a new package, so the usage won't be high; but I'll probably do so, at
least for my own usage. I'm already using it in one project, and I need it
in others.

On Fri, Jan 25, 2019 at 4:56 PM Adam Johnson  wrote:

>
> On Fri, 25 Jan 2019 at 14:46, Linus Lewandowski <
> linus.lewandow...@netguru.pl> wrote:
>
>> Right now, it's hard to report Vary header correctly. Headers might get
>> accessed in many different places, like middlewares, subroutines (which
>> can't use patch_vary_headers as they don't have access to the response
>> object), etc - and all those cases should be reflected in the Vary header,
>> or something might get cached incorrectly.
>>
>> However, thanks to the newly added request.headers property (see
>> https://code.djangoproject.com/ticket/20147 and
>> https://github.com/django/django/commit/4fc35a9c3efdc9154efce28cb23cb84f8834517e),
>> we now have a single place which is used to access request headers. We can
>> track which ones were accessed, and then set Vary header automatically, for
>> example in a middleware.
>>
>> What do you think about:
>> 1) adding some code to track accessed headers in request.headers,
>> 2) adding a new middleware (or expanding an existing one), that sets the
>> Vary header based on 1),
>> 3) deprecating patch_vary_headers function
>> and vary_on_headers/vary_on_cookie decorators and recommending to use
>> request.headers instead?
>>
>> Thanks,
>> Linus
>>
>> PS. This is a follow-up to the
>> https://code.djangoproject.com/ticket/28533 ticket.
>>
>> --
>> 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/81484ff1-552e-4103-9fa8-8a3348512b84%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Adam
>
> --
> 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/LlQtbOm_YWw/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/CAMyDDM3uDHaDywYFa6fM_-jJw8j81yoTP9%3DyLO2Rx2JDOk45jw%40mail.gmail.com
> 

Re: revisiting the Python version support policy

[Joe Tennies]

I just want to recap what I'm hearing.

After listening to the arguments, it doesn't sound like many seasoned
developers/Django users would need the 3.5 support to remain for
development purposes. Therefore, their needs don't seem to need to be
considered.
Larger organizations may have issues with Enterprise/LTS Linux distros not
having that version of Python by default for deploying. This is not a top
concern, but it is at least a slight concern.
Beginning and unseasoned Django users can be easily confused by choices.
This has been the focus of much of this discussion. This seems to be a
pretty major concern. Is there a way that we deal with this? I have some
suggestions below.

I am not sure that that last issue can be as easily solved by technical
solutions as much as social/documentation solutions. Therefore, I'm going
to point out some things that I'm noticing.

First, the main Django webpage only mentions the very latest release. I
think that this should be updated to more prominently show the latest LTS
release. It should also show all currently supported releases underneath it.

Secondly, should we be suggesting that beginners stick to the latest LTS
version? I think this makes sense as there should be better documentation
and people will not have to deal as much with just general churn. This
leads into "how would a beginner get the latest LTS version?" Let's assume
they understand pip. Is there a way for them to get pinned to the latest
Django LTS release? Should Django have a package in pypi named django-lts
that is just a dummy package that has a dependency of django>=1.11.0,<2.0?
Would this break on a pip update that would update all packages? I'm trying
to think of any scenarios where someone could jump off an LTS accidentally
without doing something completely wrong.

Thirdly, if we do push people towards the LTS releases, should
docs.djangoproject.com default to the latest LTS version instead of the
latest release (whether LTS or not)?

Fourthly, I think the documentation should more clearly state what version
of Python it supports. I'm looking at the 2.1 documentation (current thing
a beginner would see), and I don't see it. It's not on the first half of
the main page, nor the install instructions. I do see a suggestion for
"lastest version" (which may not be supported yet if right after a new
Python release -- too new) or "use OS's package manager (which we just
stated would not be new enough if using a more stable distro -- too old).

That ends my thoughts on the unseasoned Django user, but I had a potential
concern that I hadn't heard brought up. Is there any added effort as far as
deploying to a non-system version of Python? I have an odd deployment on
Dreamhost that uses passenger to deploy my Django apps. I have to do a
weird passenger_wsgi.py file as mentioned in
https://help.dreamhost.com/hc/en-us/articles/360002341572-How-to-create-a-Django-2-project-using-virtualenv
that changes the Python interpreter on the fly. Does that affect something
like mod_wsgi, uwsgi, gunicorn, or some other wsgi runner? I mean if it
would come down to recompiling Apache or some such, that would put a fair
amount of burden on someone to deploy. If it stays generally separate then
it's fine.

Assuming the deployment issue is "only in rare/corner cases" or less, I
think the grand majority of the concerns could be fixed through
documentation and website updates.





On Fri, Jan 25, 2019 at 9:04 AM Tim Graham  wrote:

> Can you explain more about what they struggled with? Maybe there's other
> ways to solve those problems.
>
> On Friday, January 25, 2019 at 9:43:37 AM UTC-5, Tom Forbes wrote:
>>
>> This message really resonated with me, especially after helping a few
>> beginners get started with Python and watching them struggle with exactly
>> this kind of thing.
>>
>> I'd be +1 on following Python. Looking through the diff there is not a
>> huge amount of things to remove and IMO none of them are really holding us
>> back or all that serious. We've fixed some issues with mangling cached
>> property names, some workarounds for ModuleNotFoundError/ImportError and an
>> issue with sqlite3 on 3.5.
>>
>> On 24 January 2019 at 20:33:42, Carlton Gibson (carlton...@gmail.com)
>> wrote:
>>
>> To be honest, I'm surprised there's even one person who comes within a
>> 1000 miles of this list who's using Python 3.5. :)
>>
>> My reason for thinking we should follow Python's supported versions is
>> users, and particularly beginning users, who have got they-don't-know
>> version and find a tutorial just what... no sorry need... `pip3 install
>> Django` to work, and give them the version of Django that corresponds to
>> what they see when they visit docs.djangoproject.com.
>>
>> I don't agree this is theoretical at all.
>>
>> It's not just Debian. (Which doesn't fit my mental model here really...)
>>
>> It's all those few-years-old computers out there.
>>
>> It's for example Raspbian, which as of this month is still 

Re: revisiting the Python version support policy

[Florian Apolloner]

FWIW, most of my problems with python version dependencies went away when I 
started to use a custom build on our servers. Allows easy upgrades and a 
good environment for our programs.

On Friday, January 25, 2019 at 4:01:28 PM UTC+1, Dan Davis wrote:
>
> My employer is still using CPython 3.4.6 on the servers, and CPython 3.5.1 
> on the desktop.   I've been instrumental in developing a plan to move 
> forward.  I know of one established company and one start-up, by name, 
> where they are still using CPython 2.7 (and a horrendously old version of 
> Django), because it is hard to upgrade.   As long as Django has a LTS 
> version, such as 1.11, and soon 2.2, I think forcing an upgrade is OK.  
>  But it is good to be aware of what's out there.
>
> On Fri, Jan 25, 2019 at 9:43 AM Tom Forbes > 
> wrote:
>
>> This message really resonated with me, especially after helping a few 
>> beginners get started with Python and watching them struggle with exactly 
>> this kind of thing.
>>
>> I'd be +1 on following Python. Looking through the diff there is not a 
>> huge amount of things to remove and IMO none of them are really holding us 
>> back or all that serious. We've fixed some issues with mangling cached 
>> property names, some workarounds for ModuleNotFoundError/ImportError and an 
>> issue with sqlite3 on 3.5.
>>
>> On 24 January 2019 at 20:33:42, Carlton Gibson (carlton...@gmail.com 
>> ) wrote:
>>
>> To be honest, I'm surprised there's even one person who comes within a 
>> 1000 miles of this list who's using Python 3.5. :) 
>>
>> My reason for thinking we should follow Python's supported versions is 
>> users, and particularly beginning users, who have got they-don't-know 
>> version and find a tutorial just what... no sorry need... `pip3 install 
>> Django` to work, and give them the version of Django that corresponds to 
>> what they see when they visit docs.djangoproject.com. 
>>
>> I don't agree this is theoretical at all. 
>>
>> It's not just Debian. (Which doesn't fit my mental model here really...)
>>
>> It's all those few-years-old computers out there. 
>>
>> It's for example Raspbian, which as of this month is still shipping 
>> Python 3.5. 
>>
>> So my boy, who's 10, says, 
>>
>> - What would you use? 
>> - Well I'd use Django (obviously) 
>> - Can I use that?
>> - Yeah... 
>>
>> If we do drop Python 3.5 I have to say, "Well, no. But you can use this 
>> old one." That's not as cool.
>> But there will be people who are more seriously affected. 
>>
>> > Who is saying, "I want to use the latest version of Django, but I want 
>> to use a really old version of Python."
>>
>> No one is saying this. The notion of versions doesn't come into it. We're 
>> well beyond the barrier-to-entry before we get there. 
>> I (just my opinion on this) think we mistake our audience if we forget 
>> this.  
>> (For this reason I don't think the deployment issue is the relevant one. 
>> It's about people learning to programme, not professionals.) 
>>
>> We can't support everything forever, and I'm as keen as anyone to push 
>> forward, but following Python is (for me) the thing we should do. 
>> I think Django's position in the Python eco-system requires it. 
>>
>> Of course if we don't, things are easier for us, yes. 
>>
>> Again, just my opinion. 
>> C. 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/19e099cf-6087-4efd-9138-d338f12bbf2c%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAFNZOJPdaWYJ9LCPZsG9dE66ka%2B8M_8Y4_%2BzMwFNz4er1pXi8w%40mail.gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are 

Re: Proposal: Track used headers and use that information to automatically populate Vary header.

[Adam Johnson]

Accessing the value of a header doesn't necessarily mean that the response
varies based up on, for example it might simply be accessed for storage in
informational logs. Additionally, Request.headers is not the only way to
access the values now, Request.META has not been removed. I don't believe
any of Django's internal header lookups have been changed to use
Request.headers and it's unlike third party packages or applications will
ever all be moved.

Anyway I'm pretty sure you can write such a middleware yourself, replacing
Request.headers with a proxy object (and maybe Request.META too), then
adding 'Vary' on the way out based upon accessed keys, at least as a proof
of concept. If it gets some usage that would prove it could be valuable to
add to Django itself.



On Fri, 25 Jan 2019 at 14:46, Linus Lewandowski <
linus.lewandow...@netguru.pl> wrote:

> Right now, it's hard to report Vary header correctly. Headers might get
> accessed in many different places, like middlewares, subroutines (which
> can't use patch_vary_headers as they don't have access to the response
> object), etc - and all those cases should be reflected in the Vary header,
> or something might get cached incorrectly.
>
> However, thanks to the newly added request.headers property (see
> https://code.djangoproject.com/ticket/20147 and
> https://github.com/django/django/commit/4fc35a9c3efdc9154efce28cb23cb84f8834517e),
> we now have a single place which is used to access request headers. We can
> track which ones were accessed, and then set Vary header automatically, for
> example in a middleware.
>
> What do you think about:
> 1) adding some code to track accessed headers in request.headers,
> 2) adding a new middleware (or expanding an existing one), that sets the
> Vary header based on 1),
> 3) deprecating patch_vary_headers function
> and vary_on_headers/vary_on_cookie decorators and recommending to use
> request.headers instead?
>
> Thanks,
> Linus
>
> PS. This is a follow-up to the https://code.djangoproject.com/ticket/28533
> ticket.
>
> --
> 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/81484ff1-552e-4103-9fa8-8a3348512b84%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3uDHaDywYFa6fM_-jJw8j81yoTP9%3DyLO2Rx2JDOk45jw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

[Tim Graham]

Can you explain more about what they struggled with? Maybe there's other 
ways to solve those problems.

On Friday, January 25, 2019 at 9:43:37 AM UTC-5, Tom Forbes wrote:
>
> This message really resonated with me, especially after helping a few 
> beginners get started with Python and watching them struggle with exactly 
> this kind of thing.
>
> I'd be +1 on following Python. Looking through the diff there is not a 
> huge amount of things to remove and IMO none of them are really holding us 
> back or all that serious. We've fixed some issues with mangling cached 
> property names, some workarounds for ModuleNotFoundError/ImportError and an 
> issue with sqlite3 on 3.5.
>
> On 24 January 2019 at 20:33:42, Carlton Gibson (carlton...@gmail.com 
> ) wrote:
>
> To be honest, I'm surprised there's even one person who comes within a 
> 1000 miles of this list who's using Python 3.5. :) 
>
> My reason for thinking we should follow Python's supported versions is 
> users, and particularly beginning users, who have got they-don't-know 
> version and find a tutorial just what... no sorry need... `pip3 install 
> Django` to work, and give them the version of Django that corresponds to 
> what they see when they visit docs.djangoproject.com. 
>
> I don't agree this is theoretical at all. 
>
> It's not just Debian. (Which doesn't fit my mental model here really...)
>
> It's all those few-years-old computers out there. 
>
> It's for example Raspbian, which as of this month is still shipping Python 
> 3.5. 
>
> So my boy, who's 10, says, 
>
> - What would you use? 
> - Well I'd use Django (obviously) 
> - Can I use that?
> - Yeah... 
>
> If we do drop Python 3.5 I have to say, "Well, no. But you can use this 
> old one." That's not as cool.
> But there will be people who are more seriously affected. 
>
> > Who is saying, "I want to use the latest version of Django, but I want 
> to use a really old version of Python."
>
> No one is saying this. The notion of versions doesn't come into it. We're 
> well beyond the barrier-to-entry before we get there. 
> I (just my opinion on this) think we mistake our audience if we forget 
> this.  
> (For this reason I don't think the deployment issue is the relevant one. 
> It's about people learning to programme, not professionals.) 
>
> We can't support everything forever, and I'm as keen as anyone to push 
> forward, but following Python is (for me) the thing we should do. 
> I think Django's position in the Python eco-system requires it. 
>
> Of course if we don't, things are easier for us, yes. 
>
> Again, just my opinion. 
> C. 
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-develop...@googlegroups.com .
> To post to this group, send email to django-d...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/19e099cf-6087-4efd-9138-d338f12bbf2c%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/c25bb851-f334-48d4-bdd4-470c0ff10e2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Proposal: Track used headers and use that information to automatically populate Vary header.

[Linus Lewandowski]

Right now, it's hard to report Vary header correctly. Headers might get 
accessed in many different places, like middlewares, subroutines (which 
can't use patch_vary_headers as they don't have access to the response 
object), etc - and all those cases should be reflected in the Vary header, 
or something might get cached incorrectly.

However, thanks to the newly added request.headers property (see 
https://code.djangoproject.com/ticket/20147 and 
https://github.com/django/django/commit/4fc35a9c3efdc9154efce28cb23cb84f8834517e),
 
we now have a single place which is used to access request headers. We can 
track which ones were accessed, and then set Vary header automatically, for 
example in a middleware.

What do you think about:
1) adding some code to track accessed headers in request.headers,
2) adding a new middleware (or expanding an existing one), that sets the 
Vary header based on 1),
3) deprecating patch_vary_headers function 
and vary_on_headers/vary_on_cookie decorators and recommending to use 
request.headers instead?

Thanks,
Linus

PS. This is a follow-up to the https://code.djangoproject.com/ticket/28533 
ticket.

-- 
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/81484ff1-552e-4103-9fa8-8a3348512b84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

[Dan Davis]

My employer is still using CPython 3.4.6 on the servers, and CPython 3.5.1
on the desktop.   I've been instrumental in developing a plan to move
forward.  I know of one established company and one start-up, by name,
where they are still using CPython 2.7 (and a horrendously old version of
Django), because it is hard to upgrade.   As long as Django has a LTS
version, such as 1.11, and soon 2.2, I think forcing an upgrade is OK.
 But it is good to be aware of what's out there.

On Fri, Jan 25, 2019 at 9:43 AM Tom Forbes  wrote:

> This message really resonated with me, especially after helping a few
> beginners get started with Python and watching them struggle with exactly
> this kind of thing.
>
> I'd be +1 on following Python. Looking through the diff there is not a
> huge amount of things to remove and IMO none of them are really holding us
> back or all that serious. We've fixed some issues with mangling cached
> property names, some workarounds for ModuleNotFoundError/ImportError and an
> issue with sqlite3 on 3.5.
>
> On 24 January 2019 at 20:33:42, Carlton Gibson (carlton.gib...@gmail.com)
> wrote:
>
> To be honest, I'm surprised there's even one person who comes within a
> 1000 miles of this list who's using Python 3.5. :)
>
> My reason for thinking we should follow Python's supported versions is
> users, and particularly beginning users, who have got they-don't-know
> version and find a tutorial just what... no sorry need... `pip3 install
> Django` to work, and give them the version of Django that corresponds to
> what they see when they visit docs.djangoproject.com.
>
> I don't agree this is theoretical at all.
>
> It's not just Debian. (Which doesn't fit my mental model here really...)
>
> It's all those few-years-old computers out there.
>
> It's for example Raspbian, which as of this month is still shipping Python
> 3.5.
>
> So my boy, who's 10, says,
>
> - What would you use?
> - Well I'd use Django (obviously)
> - Can I use that?
> - Yeah...
>
> If we do drop Python 3.5 I have to say, "Well, no. But you can use this
> old one." That's not as cool.
> But there will be people who are more seriously affected.
>
> > Who is saying, "I want to use the latest version of Django, but I want
> to use a really old version of Python."
>
> No one is saying this. The notion of versions doesn't come into it. We're
> well beyond the barrier-to-entry before we get there.
> I (just my opinion on this) think we mistake our audience if we forget
> this.
> (For this reason I don't think the deployment issue is the relevant one.
> It's about people learning to programme, not professionals.)
>
> We can't support everything forever, and I'm as keen as anyone to push
> forward, but following Python is (for me) the thing we should do.
> I think Django's position in the Python eco-system requires it.
>
> Of course if we don't, things are easier for us, yes.
>
> Again, just my opinion.
> C.
> --
> 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/19e099cf-6087-4efd-9138-d338f12bbf2c%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/CAFNZOJPdaWYJ9LCPZsG9dE66ka%2B8M_8Y4_%2BzMwFNz4er1pXi8w%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web 

Re: revisiting the Python version support policy

[Tim Graham]

`pip install Django` gives the latest version of Django that's compatible 
for the current version of Python. Yes, users will have to switch versions 
at docs.djangoproject.com and they'll be in the same situation at 
docs.python.org if they're using Python 3.5. For learning Django, I'd think 
the latest LTS should be just fine. I get the sense that many intro to 
Django books are  updated at each LTS release.

At this point, I don't see much consensus so I think the default course of 
action would be to stick with the current policy unless someone wants to 
ask the technical board to vote upon the new proposal.

For what it's worth, there's a new test failure after a recent patch due to 
non-deterministic dict ordering in Python 3.5 which demonstrates the sort 
of minor annoyances that take time away from making useful improvements to 
Django.

On Thursday, January 24, 2019 at 3:33:33 PM UTC-5, Carlton Gibson wrote:
>
> To be honest, I'm surprised there's even one person who comes within a 
> 1000 miles of this list who's using Python 3.5. :)
>
> My reason for thinking we should follow Python's supported versions is 
> users, and particularly beginning users, who have got they-don't-know 
> version and find a tutorial just what... no sorry need... `pip3 install 
> Django` to work, and give them the version of Django that corresponds to 
> what they see when they visit docs.djangoproject.com. 
>
> I don't agree this is theoretical at all. 
>
> It's not just Debian. (Which doesn't fit my mental model here really...)
>
> It's all those few-years-old computers out there. 
>
> It's for example Raspbian, which as of this month is still shipping Python 
> 3.5. 
>
> So my boy, who's 10, says, 
>
> - What would you use? 
> - Well I'd use Django (obviously) 
> - Can I use that?
> - Yeah... 
>
> If we do drop Python 3.5 I have to say, "Well, no. But you can use this 
> old one." That's not as cool.
> But there will be people who are more seriously affected. 
>
> > Who is saying, "I want to use the latest version of Django, but I want 
> to use a really old version of Python."
>
> No one is saying this. The notion of versions doesn't come into it. We're 
> well beyond the barrier-to-entry before we get there. 
> I (just my opinion on this) think we mistake our audience if we forget 
> this.  
> (For this reason I don't think the deployment issue is the relevant one. 
> It's about people learning to programme, not professionals.) 
>
> We can't support everything forever, and I'm as keen as anyone to push 
> forward, but following Python is (for me) the thing we should do. 
> I think Django's position in the Python eco-system requires it. 
>
> Of course if we don't, things are easier for us, yes. 
>
> Again, just my opinion. 
> C. 
>

-- 
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/33e013be-48ab-4dfe-9c92-f8047538654e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

[Tom Forbes]

This message really resonated with me, especially after helping a few
beginners get started with Python and watching them struggle with exactly
this kind of thing.

I'd be +1 on following Python. Looking through the diff there is not a huge
amount of things to remove and IMO none of them are really holding us back
or all that serious. We've fixed some issues with mangling cached property
names, some workarounds for ModuleNotFoundError/ImportError and an issue
with sqlite3 on 3.5.

On 24 January 2019 at 20:33:42, Carlton Gibson (carlton.gib...@gmail.com)
wrote:

To be honest, I'm surprised there's even one person who comes within a 1000
miles of this list who's using Python 3.5. :)

My reason for thinking we should follow Python's supported versions is
users, and particularly beginning users, who have got they-don't-know
version and find a tutorial just what... no sorry need... `pip3 install
Django` to work, and give them the version of Django that corresponds to
what they see when they visit docs.djangoproject.com.

I don't agree this is theoretical at all.

It's not just Debian. (Which doesn't fit my mental model here really...)

It's all those few-years-old computers out there.

It's for example Raspbian, which as of this month is still shipping Python
3.5.

So my boy, who's 10, says,

- What would you use?
- Well I'd use Django (obviously)
- Can I use that?
- Yeah...

If we do drop Python 3.5 I have to say, "Well, no. But you can use this old
one." That's not as cool.
But there will be people who are more seriously affected.

> Who is saying, "I want to use the latest version of Django, but I want to
use a really old version of Python."

No one is saying this. The notion of versions doesn't come into it. We're
well beyond the barrier-to-entry before we get there.
I (just my opinion on this) think we mistake our audience if we forget
this.
(For this reason I don't think the deployment issue is the relevant one.
It's about people learning to programme, not professionals.)

We can't support everything forever, and I'm as keen as anyone to push
forward, but following Python is (for me) the thing we should do.
I think Django's position in the Python eco-system requires it.

Of course if we don't, things are easier for us, yes.

Again, just my opinion.
C.
--
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/19e099cf-6087-4efd-9138-d338f12bbf2c%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/CAFNZOJPdaWYJ9LCPZsG9dE66ka%2B8M_8Y4_%2BzMwFNz4er1pXi8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Automatically initialise the project as git repo

[Adam Johnson]

Agree

Feel free to make a script that does startproject, git init, and anything
else you need.

Did you know startproject supports templates so if you’re really cranking
out projects with a standard format, you can make one for yourself to save
much more time there?

On Fri, 25 Jan 2019 at 12:42, Kye Russell  wrote:

> I am against this. It assumes too much about the user's system and version
> management preferences.
>
> I think there is little to gain given that `git init .` is 10 characters.
>
> On Fri, Jan 25, 2019 at 8:35 PM mihir karbelkar 
> wrote:
>
>> Hi,
>> I have made several projects with Django but every time I create a new
>> project I have to initialize the repo for git. It would be better if the
>> project initialized itself. Maybe we can add this feature in to help make
>> development "even faster to meet goals in record time".
>> I would love to work on this but it will only be my first contribution
>> so If we agree on this I can open probably open an issue and work on it.
>> Also I would like to work for django in GSOC 2019 so any help would be
>> appreciated.
>> Thanks.
>>
>> --
>> 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/657a58db-8129-4490-a14a-9fe32d0b03d9%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/CANK-ykkay%3DYUq%3DPKVVJTWcozApdA6Y0ZDLkvuBNr-HQ4wUsgfw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1Yjsodp2ujUpiP%3DGt8UwejBdvyCLVZyrrmJKbnd69TYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Automatically initialise the project as git repo

[Kye Russell]

I am against this. It assumes too much about the user's system and version
management preferences.

I think there is little to gain given that `git init .` is 10 characters.

On Fri, Jan 25, 2019 at 8:35 PM mihir karbelkar 
wrote:

> Hi,
> I have made several projects with Django but every time I create a new
> project I have to initialize the repo for git. It would be better if the
> project initialized itself. Maybe we can add this feature in to help make
> development "even faster to meet goals in record time".
> I would love to work on this but it will only be my first contribution
> so If we agree on this I can open probably open an issue and work on it.
> Also I would like to work for django in GSOC 2019 so any help would be
> appreciated.
> Thanks.
>
> --
> 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/657a58db-8129-4490-a14a-9fe32d0b03d9%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/CANK-ykkay%3DYUq%3DPKVVJTWcozApdA6Y0ZDLkvuBNr-HQ4wUsgfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Automatically initialise the project as git repo

[mihir karbelkar]

Hi,
I have made several projects with Django but every time I create a new 
project I have to initialize the repo for git. It would be better if the 
project initialized itself. Maybe we can add this feature in to help make 
development "even faster to meet goals in record time".
I would love to work on this but it will only be my first contribution 
so If we agree on this I can open probably open an issue and work on it.
Also I would like to work for django in GSOC 2019 so any help would be 
appreciated.
Thanks.

-- 
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/657a58db-8129-4490-a14a-9fe32d0b03d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2019

[Florian Apolloner]

On Thursday, January 24, 2019 at 4:01:00 PM UTC+1, Adam Johnson wrote:
>
> I'd be happy to help mentor a cross-DB JSONField, it's something I'd like 
> to see done so I can deprecate the one I maintain in Django-MySQL.
>

Not sure if GSOC changed that much, but it seems like somewhat small for a 
GSOC project. 

-- 
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/a8156cf1-2c87-4963-add8-13429b44a8a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2019

[Josh Smeaton]

Other ideas can be found in the DEPS repo 
too: https://github.com/django/deps/pulls

The only one of those 3 that would be GSOC doable (IMO) would be the query 
expression language one.

On Friday, 25 January 2019 01:43:13 UTC+11, Carlton Gibson wrote:
>
> Perhaps it's partly the GSoC doesn't cross the radar until just a few 
> weeks before the deadline... 
>
> I'm happy to help mentor but also Django Core Mentorship is there...
> https://groups.google.com/forum/#!forum/django-core-mentorship
>
>
> One idea for a good project might be adding a cross DB JSONField as per 
> this thread
>
>
> https://groups.google.com/d/topic/django-developers/zfred27yVPg/discussion
>
> * All the supported DBs have native JSON support. 
> * SQLite is the only one where we don't have a Django model field already 
> to work on. 
>* That would be first step as PoC I'd guess. 
> * Then, how can we unify? 
> * And, a migration path (from contrib.postgres) 
>
> I don't know if that's perfect but it strikes me as eminently do-able. 
>

-- 
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/5f9a5198-fd0d-470d-a6a9-81be3c8de87f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.