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

Guido van Rossum guido at python.org
Wed Mar 5 03:25:21 CET 2008


On Tue, Mar 4, 2008 at 6:13 PM, Martijn Faassen <faassen at startifact.com> wrote:
> 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.

It does nothing of the kind. It leaves 'xxx' literals alone and
translates u'xxx' to 'xxx'. That's because (in many apps) both are
used primarily for text.

BTW I suggest that you play with it at least a little bit (run it on
its own example.py file) before diving into this discussion...

>  >  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
>
>
> _______________________________________________
>  Web-SIG mailing list
>  Web-SIG at python.org
>  Web SIG: http://www.python.org/sigs/web-sig
>  Unsubscribe: http://mail.python.org/mailman/options/web-sig/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Web-SIG mailing list