[Web-SIG] Unicode in Python 3

Massimo Di Pierro mdipierro at cs.depaul.edu
Sat Sep 19 18:06:33 CEST 2009


I agree

I was forced to write two files. The problems where

1)
     b'....' vs '....'
(could be solved using eval('b"...."') if python3 else eval("....")  
but ugly)
2)
     try:...:except Exeption,e:  vs try:...except Exception as e.
(no way around it)
3)
     it would have required a lot of if statements to convert str<- 
 >bytes because bytes do have .find.
(it is not a technical problem but makes code way less readable).




On Sep 19, 2009, at 9:01 AM, René Dudfield wrote:

> On Sat, Sep 19, 2009 at 2:26 PM, Georg Brandl <g.brandl at gmx.net>  
> wrote:
>> René Dudfield schrieb:
>>
>>>>> Here is a snippet from the compat.py we used to port pygame to  
>>>>> support
>>>>> python2.3 through 3.1
>>>> How is that related?
>>>>
>>>
>>> Rather than using a 2to3 tool - which then makes you have two  
>>> versions
>>> of your code, making the code work in python 2.x and 3.x.  2to3
>>> outputs python2.x incompatible code - when it doesn't have to.
>>
>> Sorry, but I think you do not express the intent of 2to3 correctly  
>> here.
>> It is not meant to provide a one-time conversion, so that you then
>> have to maintain two codebases, it is meant to be run over your 2.x  
>> code
>> every time you want to distribute a version for Python 3, or even
>> transparently in the distutils build process.  This of course means  
>> that
>> the 2.x code needs to be written with 3.x and the conversion in mind.
>>
>
> My point is: using b'' stops those that choose to have one code base.
> Not everyone can use 2to3, but for those that can: great!
>
> There is no 2to3 for extension modules.  There is no 2to3 distutils
> mod to run 2to3 automatically at this time(correct me if I'm wrong).
> People are creating separate branches for py3k... and those projects
> that do that seem to let the py3k version rot.  You still need to
> debug, and support multiple versions of code... since 2to3 generates
> multiple versions.  If someone sends you a patch for the 3.0 version
> you need to either reverse it yourself or find someone to do it for
> you... same thing with bug reports and tracebacks.
>
> There's some points for why 2to3 is not ok for every project.
>
>> Writing code that runs unchanged on 2.x (where x < 6) and 3.x may  
>> seem
>> nice, but forces you to do unnecessary workarounds, e.g. in exception
>> handlers.
>
> Well, I'm sure there are cases where it would cause unnecessary
> workarounds... however with the right compat.py and compat.h setup it
> hasn't been too hard in my experience in porting this way.
>
> There is an easy workaround for the exceptions changes...
> # define geterror in your compatibility module.
> def geterror ():
>    return sys.exc_info()[1]
>
> Now you can write:
> except ImportError:
>    e = geterror()
>
> Instead of these:
> #py2
> except ImportError, e:
>    pass
> #py3k
> except ImportError as e:
>    pass
>
>
>
>>
>>>>> Arguments against using bytes (and using unicode instead).
>>>>>
>>>>> So I'm -1 on using b'' all over the place since it's not in both
>>>>> versions of python, and makes it impossible for code bases to  
>>>>> share
>>>>> the same code for multiple versions of python.
>>>> That would not matter much because the high-level applications  
>>>> never see
>>>> what's under the hood.  Besides web2py all frameworks and  
>>>> libraries I
>>>> know about are using unicode internally anyways.
>>>>
>>>
>>> It would mean code bases need to support b'' - which is not  
>>> compatible
>>> with python2.
>>
>> b'' is supported as of Python 2.6.
>>
>> Georg
>
> ah yes.  I guess I meant the python2 series.  Python2.5 is still the
> most popular python... with 2.6 catching up(or passing it) in
> popularity.  So that should be changed to:
>
> """It would mean code bases need to support b'' - which is not
> compatible with <= python2.5.4"""
>
> ... anyway, just something to consider.
>
>
> ps. my facebook account on this email address was just banned.  I
> swear I didn't rant about how tornado sucks!
> _______________________________________________
> 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/mdipierro%40cti.depaul.edu



More information about the Web-SIG mailing list