Re: Extending JSONField serialization

[Michael Manfre]

It should be configurable and I like the kwargs idea. I've also had to
monkey patch JSONField in this way for datetimes.

Regards,
Michael Manfre

On Tue, Jan 5, 2016 at 12:48 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> > On 5 janv. 2016, at 18:37, Tom Christie  wrote:
> >
> >> Should JSONField accept additional kwargs to customize the encoder and
> the decoder?
> >
> > Quick take here:
> >
> > That sounds like a bit too much "cleverness" to me. The most obvious
> issue it'd cause is putting values of one type into the field, but getting
> objects of a different type back. (eg datetime getting coerced into a
> string on the way in, and left as a string on the way out).
>
> Yes, I understand how that could surprise a developer.
>
> A smart deserializer that would attempt to convert some strings back to
> their original type, based on their content, would create the opposite
> risk: a string that matches the format of a date could be accidentally
> returned as a date.
>
> I wouldn’t do this for mission-critical data — but then I wouldn’t store
> it in a JSON field either. Django projects should only use a JSON field for
> data that isn’t worth normalizing into actual fields. Writing a schema to
> map keys to types defeats the point; if you’re writing a schema, just
> express it with traditional model fields.
>
> I don’t think Django should (de)serialize non-native JSON types by
> default, but it should make it possible through public APIs, as this is a
> common requirement. For my use case, logging, the convenience of being able
> to store dates, datetimes and decimals without resorting the heavy guns
> (DRF serializers) helps a lot.
>
> --
> Aymeric.
>
> --
> 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/B995F2B7-E1D1-4F82-8032-E502EA11680A%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>



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

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

Re: Extending JSONField serialization

[Aymeric Augustin]

> On 5 janv. 2016, at 18:37, Tom Christie  wrote:
> 
>> Should JSONField accept additional kwargs to customize the encoder and the 
>> decoder?
> 
> Quick take here:
> 
> That sounds like a bit too much "cleverness" to me. The most obvious issue 
> it'd cause is putting values of one type into the field, but getting objects 
> of a different type back. (eg datetime getting coerced into a string on the 
> way in, and left as a string on the way out).

Yes, I understand how that could surprise a developer.

A smart deserializer that would attempt to convert some strings back to their 
original type, based on their content, would create the opposite risk: a string 
that matches the format of a date could be accidentally returned as a date.

I wouldn’t do this for mission-critical data — but then I wouldn’t store it in 
a JSON field either. Django projects should only use a JSON field for data that 
isn’t worth normalizing into actual fields. Writing a schema to map keys to 
types defeats the point; if you’re writing a schema, just express it with 
traditional model fields.

I don’t think Django should (de)serialize non-native JSON types by default, but 
it should make it possible through public APIs, as this is a common 
requirement. For my use case, logging, the convenience of being able to store 
dates, datetimes and decimals without resorting the heavy guns (DRF 
serializers) helps a lot.

-- 
Aymeric.

-- 
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/B995F2B7-E1D1-4F82-8032-E502EA11680A%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Extending JSONField serialization

[Tom Christie]

> Should JSONField accept additional kwargs to customize the encoder and the 
> decoder?

Quick take here:

That sounds like a bit too much "cleverness" to me. The most obvious issue it'd 
cause is putting values of one type into the field, but getting objects of a 
different type back. (eg datetime getting coerced into a string on the way in, 
and left as a string on the way out).
I'd rather see the field closely map to what the underlying database field 
*actually* provides. 

-- 
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/ff5892dd-a4bd-43c7-af80-1c25260873d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: got glossarium?

[Tim Graham]

I agree the glossary is abandoned and I propose removing it. I don't know 
that there's much value in expanding it. The idea is that you can use 
:term:`model` and have "model" linked to the glossary definition. In my 
opinion, the Django docs are comprehensible without this. A better solution 
in my opinion would be to improve the search results as suggested in the 
other thread, so you can search for a term and get a useful result.

In case readers do find value in expanding it, it looks to me like most of 
the words in your "over50.txt" file in the linked mail are normal English 
words with no special meaning in Django, so I think 600 candidates may be a 
bit exaggerated.

On Tuesday, January 5, 2016 at 11:50:51 AM UTC-5, Doug Epling wrote:
>
> This thread is aimed at the specific issue pertaining to the Django 
> Glossary.
>
> But first, after noticing, by accident, a huge spike of views on my G+ 
> profile I think I should explain.  I don't use G+ much because it seems 
> kind-of goofey to me -- that's just me.  If you want to see the real 
> picture, you can look me up on LinkedIn.com under Douglas Epling.
>
> As a web-services/python-programmer-analyst I will never hold a candle to 
> any of the lot of you in this community.  A while back I tried to make a 
> career change by paying my dues in blood, sweat, and tears (not to mention 
> $) by earning a BS in Computer Science as a middle-aged geek wannabe.  This 
> personal initiative was thwarted by the 'tsunami', as Christine Lagarde 
> called it, of 2008.
>
> I am proud that during those academics and unitl this day, I am a Linux 
> afficianado.  I use a Fedora desktop daily, exclusively.  Richard Stallman 
> is my hero.  And just as I was uncerimoniously being kicked out the door of 
> this enterprise where I'd been testing security features on embedded 
> software of network printers, I discovered Python.
>
> Although not a software developer, I know quality in technology when I see 
> it.  Hint:  Microsoft ain't it.  The millenium edition was my first clue!  
> So, I am drawn to the Django community for the promise of caskets filled 
> with gold coins, rubies, and emeralds ... just kidding; I'm a kidder.
>
> So, the glossary!  Yep, it's still there.  I could swear I saw an 
> invitation in the form of a hyper-link to work on the glossary, although I 
> can't seem to locate that in the documentation at this point.  In fact, it 
> almost appears the glossary is being slowly shunted into obscurity.
>
> Here's the thing:  I have taken the liberty of parsing the text documents 
> comprising the Django documentation. 
>   
> I have identified a lengthy list of candidate terminology for possible 
> inclusion in the glossary.  But problems like this simply can not be solved 
> with the same methods used to develop code.  Can you imagine 600 pull 
> requests to add or modify single terms and their meanings?
>
> If this is too hard, I'm hep!  But what if we established a moin, open to 
> anyone who wants to register, where the glossary can be developed?  And 
> establish some kind of temporal cycle with pull requests for glossary 
> updates.
>
> Yours truly,
>
> PS
>
> A Django v2.0 goal for revised and enhanced documentation was unrealistic, 
> and is hereby revoked.
>

-- 
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/14c06a62-480d-4e62-8877-a73da6dc1530%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

got glossarium?

[Doug Epling]

This thread is aimed at the specific issue pertaining to the Django 
Glossary.

But first, after noticing, by accident, a huge spike of views on my G+ 
profile I think I should explain.  I don't use G+ much because it seems 
kind-of goofey to me -- that's just me.  If you want to see the real 
picture, you can look me up on LinkedIn.com under Douglas Epling.

As a web-services/python-programmer-analyst I will never hold a candle to 
any of the lot of you in this community.  A while back I tried to make a 
career change by paying my dues in blood, sweat, and tears (not to mention 
$) by earning a BS in Computer Science as a middle-aged geek wannabe.  This 
personal initiative was thwarted by the 'tsunami', as Christine Lagarde 
called it, of 2008.

I am proud that during those academics and unitl this day, I am a Linux 
afficianado.  I use a Fedora desktop daily, exclusively.  Richard Stallman 
is my hero.  And just as I was uncerimoniously being kicked out the door of 
this enterprise where I'd been testing security features on embedded 
software of network printers, I discovered Python.

Although not a software developer, I know quality in technology when I see 
it.  Hint:  Microsoft ain't it.  The millenium edition was my first clue!  
So, I am drawn to the Django community for the promise of caskets filled 
with gold coins, rubies, and emeralds ... just kidding; I'm a kidder.

So, the glossary!  Yep, it's still there.  I could swear I saw an 
invitation in the form of a hyper-link to work on the glossary, although I 
can't seem to locate that in the documentation at this point.  In fact, it 
almost appears the glossary is being slowly shunted into obscurity.

Here's the thing:  I have taken the liberty of parsing the text documents 
comprising the Django documentation. 
  
I have identified a lengthy list of candidate terminology for possible 
inclusion in the glossary.  But problems like this simply can not be solved 
with the same methods used to develop code.  Can you imagine 600 pull 
requests to add or modify single terms and their meanings?

If this is too hard, I'm hep!  But what if we established a moin, open to 
anyone who wants to register, where the glossary can be developed?  And 
establish some kind of temporal cycle with pull requests for glossary 
updates.

Yours truly,

PS

A Django v2.0 goal for revised and enhanced documentation was unrealistic, 
and is hereby revoked.

-- 
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/c0b0d6f0-2419-4d2f-9069-40732a259e87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending JSONField serialization

[Tim Graham]

This came up in a ticket a couple days ago: 
https://code.djangoproject.com/ticket/25995

On Tuesday, January 5, 2016 at 11:18:01 AM UTC-5, Aymeric Augustin wrote:
>
> Hello, 
>
> I’m using the JSONField provided by django.contrib.postgres for logging 
> arbitrary data to PostgreSQL. 
>
> For this use case, I’d like my data to be JSON serialized with as little 
> fuss as possible. Unfortunately lots of things (dates, datetimes, decimals, 
> etc.) aren’t natively JSON-serializable and django.contrib.postgres doesn’t 
> seem to provide a way to override the serializer. 
>
> I can wire Django’s JSON encoder, which provides reasonable encoding rules 
> for all data types I need, by monkey-patching JSONField: 
>
>
> # Monkey-patch django.contrib.postgres to use a smarter JSON serializer. 
>
> import json 
>
> from django.contrib.postgres.fields import jsonb 
> from django.core.serializers.json import DjangoJSONEncoder 
>
>
> class DjangoJson(jsonb.Json): 
>
> def dumps(self, obj): 
> return json.dumps(obj, cls=DjangoJSONEncoder) 
>
>
> jsonb.Json = DjangoJson 
>
>
> Is this a common problem? Should JSONField accept additional kwargs to 
> customize the encoder and the decoder? 
>
> Best regards, 
>
> -- 
> Aymeric. 
>
>

-- 
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/191e3419-dc33-43c2-8653-a43494774c93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Extending JSONField serialization

[Aymeric Augustin]

Hello,

I’m using the JSONField provided by django.contrib.postgres for logging 
arbitrary data to PostgreSQL.

For this use case, I’d like my data to be JSON serialized with as little fuss 
as possible. Unfortunately lots of things (dates, datetimes, decimals, etc.) 
aren’t natively JSON-serializable and django.contrib.postgres doesn’t seem to 
provide a way to override the serializer.

I can wire Django’s JSON encoder, which provides reasonable encoding rules for 
all data types I need, by monkey-patching JSONField:


# Monkey-patch django.contrib.postgres to use a smarter JSON serializer.

import json

from django.contrib.postgres.fields import jsonb
from django.core.serializers.json import DjangoJSONEncoder


class DjangoJson(jsonb.Json):

def dumps(self, obj):
return json.dumps(obj, cls=DjangoJSONEncoder)


jsonb.Json = DjangoJson


Is this a common problem? Should JSONField accept additional kwargs to 
customize the encoder and the decoder?

Best regards,

-- 
Aymeric.

-- 
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/78D28A81-5338-4FC8-8D46-46595DF737F5%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: structural & functional review of django documentation

[Tim Allen]

Scot, you've summarized what I've run into as well beautifully. My problem 
has never been with the documentation once I find it - it has been the path 
to finding it. Another frustration is trying to find a part of the 
documentation I know I've seen before a second time. I seem to go round and 
round in link circles for a frustrating amount of time. Taxonomy here is 
important, because of the frequent use and reuse of potential search terms 
throughout the documentation.

Regards,

Tim

On Monday, January 4, 2016 at 2:45:56 AM UTC-5, Scot Hacker wrote:
>
> The written quality of the Django docs has been a selling point for years, 
> but discoverability has never been great. I wanted to add two notes:
>
> 1) The front page of the docs says docs are organized into four sections 
> (Tutorials, Topic Guides, Reference Guides,  How-To Guides). And it's been 
> proposed that we add a fifth docstring-generated API Reference as well. But 
> remember that most people looking to solve a problem under deadline start 
> with search, not taxonomy. Search results do *seem* to be labeled with the 
> section of the docs they come from, but the sections referenced don't 
>  actually correspond to the four sections we say use!  If I search for 
> "forms" I get results that claim to come from "API Reference," "Using 
> Django," "Release Notes," which don't match the names of our four sections. 
>  I propose that A) search results clearly indicate the doc sections that we 
> claim we use for organization; B) Search results be grouped by type (e.g. 
> show all results from Using Django first, followed by all results from API 
> Reference)... or whatever. Or a user could use checkboxes to select which 
> section of the docs they want to search. Or faceted search results so users 
> can quickly toggle or filter the sources of the search results? There are a 
> lot of ways to solve this - just pointing out that our search experiences 
> could be  sharper and more customizable.
>
> 2) I've encountered a number of situations where search didn't help 
> because I didn't yet know enough to search for the right thing. I remember 
> early in my Django experience trying to figure out how to have a "global 
> variable" for my project and that search string not turning up what I 
> needed to know... because what I really should have been searching for was 
> "context processors".* I think we could make strides in search-ability 
> through the indication of a tagging system. Tags could either be controlled 
> through commits, or dynamic (users could tag topics on the fly, and a 
> weighting system would apply to search results). 
>
> * Even today, searching the docs for "context processor" does not take me 
> quickly to a clean example of how to implement a context processor - I 
> really have to dig for this information. 
>
> ./s
>
>

-- 
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/b0f50682-2c4b-42f8-a4b9-33fc3121f315%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for Input: WSGI 2.0

[Aymeric Augustin]

One more thing — while this isn’t a use case I have myself, some people rely on 
the ability to run an application at a sub-part e.g. under 
https://example.com/appname/.

WSGI should normalize the headers involved in that case so that applications 
don’t have custom code for various servers. Django currently contains such 
custom code.

-- 
Aymeric.

> On 5 janv. 2016, at 12:27, Cory Benfield  wrote:
> 
> On Tuesday, January 5, 2016 at 10:37:32 AM UTC, Aymeric Augustin wrote:
> Hi Cory,
> 
> I’m not subscribed to web-sig but I read the discussion there. Feel free to 
> forward my answer to the group if you think it’s useful.
> 
> 
> Thanks Aymeric, this feedback was extremely valuable. I've forwarded it to 
> the web-sig list so that I can keep track of it all, which will let me get a 
> feel for how the wider community thinks about WSGI.
> 
> Cory 
> 
> -- 
> 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/fb4ad1a4-f2fb-469e-a4f7-56f407f52311%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/157F6457-EFB8-4E26-8DED-4DAD740C1967%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Request for Input: WSGI 2.0

[Cory Benfield]

On Tuesday, January 5, 2016 at 10:37:32 AM UTC, Aymeric Augustin wrote:
>
> Hi Cory,
>
> I’m not subscribed to web-sig but I read the discussion there. Feel free 
> to forward my answer to the group if you think it’s useful.
>
>
Thanks Aymeric, this feedback was extremely valuable. I've forwarded it to 
the web-sig list so that I can keep track of it all, which will let me get 
a feel for how the wider community thinks about WSGI.

Cory 

-- 
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/fb4ad1a4-f2fb-469e-a4f7-56f407f52311%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for Input: WSGI 2.0

[Aymeric Augustin]

Hi Cory,

I’m not subscribed to web-sig but I read the discussion there. Feel free to 
forward my answer to the group if you think it’s useful.

I have roughly the same convictions as Graham Dumpleton. If you want to support 
HTTP/2 and WebSockets, don’t start with design decisions anchored in CGI. 
Figure out what a simple and flexible API for these new protocols would be, 
specify it, implement it, and make sure it degrades gracefully to HTTP/1. You 
may be able to channel most of the communication through a single generator, 
but it’s unclear to me that this will be the most convenient design.

If you want to improve WSGI, here’s a list of mistakes or shortcomings in PEP 
 that you can take a stab at. There’s a general theme: for a specification 
that looks at the future, I believe that making modern PaaS-based deployments 
secure by default matters more than not implementing anything beyond what’s 
available in legacy CGI-based deployments.

1. WSGI is prone to header injection vulnerabilities issues by design due to 
the conversion of HTTP headers to CGI-style environment variables: if the 
server doesn’t specifically prevent it, X-Foo and X_Foo both become HTTP_X_Foo. 
I don’t believe it’s a good choice to destructively encode headers, expect 
applications to undo the damage somehow, and introduce security vulnerabilities 
in the process. If mimicking CGI is still considered a must-have — 1% of 
current Python web programmers may have heard about it, most of them from PEP 
 — then that burden should be pushed onto the server, not the application.

2. More generally, I fail to see how mixing HTTP headers, server-related 
inputs, and environment variables in a dict adds values. It prevents iterating 
on each collection separately. It only makes sense if not offering more 
features than CGI is a design goal; in that case, this discussion doesn’t serve 
a purpose anyway. It would be nicer and possibly more secure if the application 
received separately:

a. Configuration information, which servers could read from environment 
variables by default for backwards compatibility, but could also get through 
more secure channels and restrict to what the application needs in order to 
better isolate it from the entire OS.
b. Server APIs mandated by the spec, per request.
c. HTTP headers, per request.

3. Stop pretending that HTTP is a unicode protocol, or at least stop ignoring 
reality when doing so. WSGI enforces ISO-8859-1-decoded str objects in the 
environ, which is just wrong. It’s all the more a surprising choice since this 
change was driven by Python 3, that UTF-8 is the correct choice, and that 
Python 3 defaults to UTF-8. Django has to re-encode and re-decode before doing 
anything with HTTP headers: 
https://github.com/django/django/blob/d5b90c8e120687863c1d41cf92a4cdb11413ad7f/django/core/handlers/wsgi.py#L231-L253

4. Normalize the way to tell the application about the original protocol, IP 
address and port. When dev and ops responsibilities are separate, this is 
clearly an ops responsibility, but due to the lack of standardization devs end 
up dealing with this problem in custom middleware, when they do it at all. 
Everyone keeps getting it wrong, which introduces security vulnerabilities. 
Also it always breaks silently on infrastructure changes.

5. Improve request / response length handling and connection closure. Armin and 
Graham have talked about in the past and know the topic better than I do. 
There’s also a rejected PEP by Armin which made sense to me.

As you can see from these comments, I don’t quite share the design choices that 
led to WSGI as it currently stands. I think it will be easier to build a new 
standard than evolve the current one.

I hope this helps!

-- 
Aymeric.

> On 4 janv. 2016, at 13:43, Cory Benfield  wrote:
> 
> All,
> 
> An effort has begun over in the PSF Web-SIG special interest group to come up 
> with a new version of the WSGI specification. 
>  The goal 
> is to develop a successor to WSGI that will be more useful in the development 
> of modern, asynchronous web applications, with the goal of making available 
> all of the improvements in both HTTP and Python that have come through in the 
> years since PEP 333.
> 
> As Django is one of the major users of WSGI, any attempt to specify a new 
> version without getting input from the Django community and development team 
> would be extremely foolish! This is therefore a request for input: I'd like 
> it very much if the Django development team could come up with a response to 
> the email linked earlier, indicating what the Django team would like from a 
> new version of WSGI and what you believe the priorities should be. For 
> obvious reasons there may not be consensus around this issue amongst the 
> Django developers, and that's fine: multiple submissions from Django would be 
> entirely acceptable.
> 
>