[Web-SIG] Are you going to convert Pylons code into Python 3000?

[Graham Dumpleton]

On 05/03/2008, Martijn Faassen <faassen at startifact.com> wrote:
> Hey,
>
>  On Wed, Mar 5, 2008 at 12:05 AM, Graham Dumpleton
>  <Graham.Dumpleton at gmail.com> wrote:
>  [snip]
>
> >  Personally I believe that WSGI 1.0 should die along with Python 2.X. I
>  >  believe that WSGI 2.0 should be developed to replace it and the
>  >  introduction of Python 3.0 would be a great time to do that given that
>  >  people are going to have to change their code anyway and that code
>  >  isn't then likely to be backward compatible with Python 2.X.
>
> I think lots of Python projects reason this way: Python 3 transition
>  is the right time to break backwards compatibility in our
>  library/framework. It's understandable.
>
>  Unfortunately this means that for people adjusting their code, they
>  won't just have to deal with the large Python 3 transition, but also
>  with lots of their frameworks and libraries making
>  backwards-incompatible changes. That's unfortunate, as that means any
>  automatic conversion strategy using the py2to3 script won't be
>  possible, and there won't be any way to keep libraries in transition
>  working in both Python 2 and 3 for a while (which is Guido's plan), as
>  their dependencies don't support it.

In the case of code which directly talks to the interface defined by
WSGI specification I very much doubt the py2to3 script will help. This
is because for WSGI to work with Python 3.0 there needs to be a change
from use of string type objects to byte string type objects. I would
suspect that py2to3 is only get help in any sort of automated way with
the fact that a string object becomes unicode aware, not where with
WSGI the code would have to change to use and deal with a different
type of object completely. The implications of this change to a byte
string type object are going to be much more complicated.

What I fear is that if Python 3.0 isn't used as a trigger to push out
WSGI 2.0, we will end up being stuck with WSGI 1.0 forever and there
will never ever be any momentum to updating it even though a range of
deficiencies and shortcomings have been identified in the
specification as far as the way it is drafted, with the functionality
it provides and how that functionality is described as needing to be
implemented.

I'd rather not see another XML-RPC where in practice it was a good
first attempt, but with a little bit of tweaking would have made it so
much better, but still keep its simplicity. And no I don't mean SOAP,
that went too far. Problem with XML-RPC from what I saw at the time is
that the original author had a lot invested in software that used the
original XML-RPC and he wasn't going to budge as he didn't want to
have to change his own systems based on it.

With Python 3.0 people are going to have to change their code anyway
and so it is an ideal time to push to a new version of WSGI
specification which fixes its warts and eliminates the oddities it had
to support certain legacy systems, something which is now not seen as
necessary.

Also, for most systems that use WSGI it would be quite minimal impact,
as they often use it merely as a bridge to some existing web server
interface. Thus changes would be very localised. Even something like
Paste/Pylons hides a lot of what is WSGI behind its own veneer, for
example WebOb and its predecessor and so higher layers may not even be
affected much.

As much as I'd like to see everything move to a better WSGI 2.0, if
there are components which people don't want to update, then a WSGI
2.0 to 1.0 bridging middleware can be used to adapt them.

Graham