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

[Martijn Faassen]

Hey,

On Wed, Mar 5, 2008 at 1:48 AM, Graham Dumpleton
<graham.dumpleton at gmail.com> wrote:
[snip]
>  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.

I have no idea what the capabilities of this script are. I would
*imagine* it would convert classic strings into the bytes types, and
unicode strings into the new string type.

>  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.
[snip XML-RPC example]

That argument doesn't work for me. You're implying that if Python 3.0
did not exist, there would be no way to
come out with a new version of the specification to fix shortcomings?
We can't fix APIs unless we have the momentum given by a  language
change? You better never have any ideas on WSGI 3.0 then, as it's
unlikely you'll have another such opportunity.

>  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.

"With Python 3.0 people are going to have their change their code
anyway as the language changes, so we're going to make it harder for
them by breaking their libraries too"

Having one thing change is hard enough on people. It's then nice to be
able to run your tests and have some indication it works. It's also
nice to be able to continue releasing for Python 2.x for a while, and
release the converted code using the conversion script. I'm not making
up this plan, that's the official plan. Changing libraries will break
this plan.

[WSGI is hidden, so it will be a low-impact change]

This may be true. I still don't see a reason to connect it to the
language change. Anyway, I'll stop on this now. I just think it's a
worrying trend.

>  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.

Yes, that would help people using Python 2.x, but would WSGI 1.0 even
be available in Python 3.0 given your plan?

Regards,

Martijn