[Web-SIG] PEP 0333 and PEP XXXX Updated

[Armin Ronacher]

Hi,

Graham Dumpleton schrieb:
> Regardless of the details of changes being made to the PEP and the
> creation of any new ones, do we need to first agree on the overall
> direction we are going to take. Ie., the grand plan at a high level.
Indeed.  The 0333 changes are mostly uncontroversial and can be
discovered separately.  So far the discussions on this mailinglist in
the last days only covered what would be a new WSGI version which is in
the XXXX file.

> What I am getting at here is that the likes of PJE has indicated a
> preference for skipping any WSGI 1.1 altogether and going straight to
> WSGI 2.0. If there isn't going to be support all round for even coming
> out with WSGI 1.1, then don't want to see time wasted trying to come
> up with a new PEP only for what is needed to change.
The time wasted on XXXX is not that much, it's just your #3 written down
to text with the unicode return values.

> So, I am starting to get nervous that we could go to a great deal of
> work to try and resolve the various issues for a specific definition,
> only to find that people don't even agree that such a version is
> warranted and we get a deadlock.
WSGI 1.1 as currently specified in XXXX would be pretty uncontroversial
on Python 2.x because of the str/unicode coercion that Python implicitly
applies and that this is basically the only change.

> 1. Clarifications and corrections to existing WSGI for Python 2.X
Is already in 0333 in the repository.

> 2. Come up with a version of WSGI for Python 3.X. The whole bytes
> versus unicode discussion.
That is in XXXX, just that this new version of WSGI also works in Python
2.x and is unicode based.

> 3. Drop the start_response() function and ability to use its write()
> function returned as result. What people have been calling WSGI 2.0.
That would be too many changes at the same time.  We can specify WSGI
2.0 at the same time based on XXXX and just change the return value to
``(app_iter, status, headers)`` and drop the `start_response`.  But that
really breaks applications and workflows and I don't think everybody
would swtich over to that right away.

> The first question is, should Python 2.X forever be bytes everywhere,
> or if we start introducing unicode [...]
Latest version of XXXX specifies ist as unicode for 2.x and 3.x except
where native strings still make sense.

> In my definitions I introduced 'native' string along with 'bytes' and
> 'unicode' string in an attempt to try and be able to use one set of
> language which would describe WSGI and be interpretable in the context
> of both Python 2.X and Python 3.X.
XXXX is basically that.

> The second question is, do we want to try and come up with something
> for Python 3.X, ie., (2) above, while still preserving the current
> start_response() callback, or do we instead want to jump direct to
> WSGI (Python 3.X) 2.0, ie., combine (2) and (3) above, and say that
> there is no WSGI 1.X for Python 3.X at all?
XXXX does not drop start_response.  That would break too much code (all
middlewares and it's not straightforward to write middlewares for both
start_response and without then).

> For example, one option for a roadmap would keep bytes everywhere in
> Python 2.X and jump direct to WSGI 2.0 in Python 3.X.
IMO WSGI 1.0 should just fix the small problem it has, and WSGI 1.1 goes
to unicode in both versions.

> WSGI (Python 2.X) 1.1 - Clarify existing WSGI by adding (1) above.
> WSGI (Python 2.X) 2.0 - Drop start_response() from WSGI (Python 2.X)
> 1.1. Keep bytes everywhere.
> WSGI (Python 3.X) 2.0 - Adapt WSGI (Python 2.X) 2.0 to Python 3.X. Use
> definition #4 (or more likely a variation on it).
For that I would rather go like this:

WSGI 1.0       stays the same as PEP 0333 currently is
WSGI 1.1       becomes what Ian and I added to PEP 0333
WSGI 2.0       becomes a modified version of PEP XXXX
WSGI 3.0       like XXX but drops start_response

> One reason for still keeping bytes everywhere in Python 2.X is that is
> because how it is and if unicode introduced then possibly would just
> be ignored by people anyway.
If WSGI 2.0 based on the list above introduces unicode to both Python
2.x and Python 3.x not much would change for the user.  Frameworks are
already using unicode everywhere already, if the decoding step happens
in the webserver they just would have to make their own decoding a NOOP
if they detect version (2, 0).

> Second reason is whereby Ian is promoting PEP 0383 as way of resolving
> transcoding issues
If we want to be WSGI still Python 2.x compliant for all version (which
I hope we do), that is out of the question.  Also latin1 is fine because
it's actually what HTTP speaks and does not drop any information.  For
URIs we do what browsers do already which also does not lose any
information.  Don't see what 0383 gives us we can't have with what you
and Robert are already doing.

> So, perhaps we can step back for a minute and ask those couple of
> major questions. To state them again, they were:
> 
> 1. Do we keep bytes everywhere forever in Python 2.X, or try to
> introduce unicode there at all to at least mirror what changes might
> be made to make WSGI workable in Python 3.X?
-1, Specifications should work the same in 2.x and 3.x

> 2. Do we skip WSGI 1.X completely for Python 3.X and go straight to
> WSGI 2.0 for Python 3.X?
Yes.

> I would like to see all the major players, ie., Robert, Armin, PJE and
> Ian, plus if possible, major developers on packages like Pylons, TG,
> Django, Zope/Repoze etc, at least comment on these two questions.
You got my answers. :)


Regards,
Armin