[Web-SIG] PEP 0333 and PEP XXXX Updated

[Etienne Robillard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Armin Ronacher wrote:
> 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

Good plan but I'm afraid now only a bunch of elite people on this list
is going to remember all the details on theses "upcoming"
specifications. Why the rush to specify WSGI 3.0 and not focus
mainly on the next one ahead ?

With regards,

Etienne
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkq2JIYACgkQ/VP9MZjcTlePlwCfQKKjLp0ZUyObFJvYbUHIARdY
sqwAoJ99JgdKaIVjw5SZfXveFS+tSj7/
=VHY9
-----END PGP SIGNATURE-----