On 6/20/2010 8:26 AM, Giampaolo Rodolà wrote:
I attempted to port pyftpdlib to python 3 several times and the
biggest show stopper has always been the bytes / string difference
introduced by Python 3 which forces you to *know* and *use* Unicode
every time you deal with some text and 2to3 is completely useless
here.
I believe the advice in the wiki porting page is to use unicode() and
bytes() but never str(), in a version that runs in 2.6. Then 2to3 should
do fine. For 2.5-, add 'bytes = str' somewhere.
2to3 still gets patches, I believe, when someone exhibits code that
could and ought to be converted but is not.
I suspect that if you posted 'Problems porting pyftpdlib to Python3',
you would get some help. If it involved inadequacies in the current
tools and guides, it would to be be on-topic here. Or try python-list.
The choice of forcing the user to use Unicode and "think in Unicode"
was a very brave one, and I'm sure it's for the better, but not
everyone wants to deal with that because Unicode is hard to swallow.
I felt that way until my daughter decided to switch from Spanish to
Japanese for here foreign language. Once I quit fighting it, it because
much easier to swallow and learn. As it turns out, thinking in Unicode
is a pretty straightforward generalization of thinking in ascii. There
are some annoying glitches due to the need to accomodate legacy systems.
The plethora of legacy encodings for various subsets, besides ascii, is
also a nuisance.
The majority of people
who use latin-char alphabets
prefer to stay with bytes and eventually learn
and introduce Unicode only when that is actually needed.
The example at
http://code.google.com/p/pyftpdlib/
uses names and filenames. Without unicode, these are restricted to
ascii, unless you use multiple encodings, which to me would be worse.
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
