[Web-SIG] PEP 0333 and PEP XXXX Updated

[Graham Dumpleton]

2009/9/21 P.J. Eby <pje at telecommunity.com>:
> At 08:48 AM 9/20/2009 -0400, Etienne Robillard wrote:
>>
>> 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 ?
>
> Because having more versions of the spec is a bug, not a feature.  How many
> versions will a server or framework be reasonably expected to support?

I think there is perhaps two aspects to the original question about
why even project ahead to WSGI 3.0 (no start_response) at this point.

The first is why we want to even be considering dropping
start_response at all at this point if people see the current way of
doing things as reasonable.

The second is whether any effort in drafting a new specification can
be avoided at all by going direct to WSGI 3.0, combining amendments,
going unicode and dropping start_response all in one go.

I have a few views on this.

The first is that although I probably have the most difficult job to
implement multiple WSGI versions, given that mod_wsgi is all in C code
with no Python code at all, the changes we are talking about at the
moment aren't that drastic that can't relatively easily support
multiple WSGI versions. In fact, mod_wsgi already implements what we
are talking about in WSGI 1.1. This is because WSGI 1.1 is more about
providing guarantees to the WSGI application based on how the majority
of WSGI adapters/servers already work. I would expect it will be even
simpler for WSGI adapters/servers implemented in pure Python to cope
with multiple versions.

In respect of defining all the versions now as a well defined roadmap,
from the adapter/server side, you need to realise that existing
implementations have become quite stable. As such, the frequency of
any updates to them is going to get larger and larger. For me, I would
rather add in the support for WSGI 1.1/2.0/3.0 now, knowing that
likely might not make another major version release of mod_wsgi for a
year or more, if at all. If mod_wsgi is stable and ends up don't see a
need to go and implement further new features I have speculated on,
then I don't want to come back in a year just to add WSGI 3.0 support.

Further, given that Python 3.X is going to be a trigger point for
people to at least make changes to unicode, it would be nice to have
WSGI 3.0 out there as a separate additional step they can consider at
the same time. Ultimately I feel it will be the general masses and not
WSGI adapter/server implementers who will make the decision about how
big a jump they will want to make. Enforcing a jump to WSGI 3.0 may
not be looked on favourably given that that is a much more significant
change.

Think of all the problems with migration to Python 3.X as far as
people waiting for third party modules to be updated. You will see the
same problem with WSGI components if we go direct to WSGI 3.0. As WSGI
2.0 for Python 2.X is, due to way bytes/unicode can still be used
interchangeably, it is a much simpler transition and I can see a quick
movement to that, or even for the WSGI components to work with all of
WSGI 1.0/1.1/2.0 at the same time.

For many, if they are smart about it, they may even be able to easily
support WSGI 3.0 as well at same time as 1.0/1.1/2.0. The key here
would probably be us defining prototype skeletons for code which
exhibits how supporting multiple versions in WSGI components could be
done easily.

As to the idea that going direct to WSGI 3.0 will save us some work in
drafting any specification at least, I don't see that it will on the
basis that at the moment the only difference we are talking about
between WSGI 2.0/3.0 is dropping of start_response(). This is because
bits of the other stuff already talked about in relation to what we
were calling WSGI 2.0 previously, is already a part of what we are now
saying is WSGI 1.1/2.0. In other words, the only important thing that
has got deferred to WSGI 3.0 is dropping of start_response(). Some of
the other comments seem to indicate that perhaps some have much more
drastic changes in mind than just that. If you do, then perhaps you
want to outline what those other changes may be so can gauge how
significant they are.

Even if people decide to only go as far as WSGI 2.0 at this point, I
would still likely implement WSGI 3.0 as an experimental feature just
so people can play with it directly rather than have to fiddle with
adapters. It wouldn't be the default version anyway, so its present
isn't going to affect the general population.

BTW, Python 2.6 can itself be seen as a transitional version in some
ways between Python 2.5 and Python 3.0. So, not like the idea of WSGI
2.0 being a transitional version is unique. :-)

Graham