py3k s***s

[Robin Becker]

Diez B. Roggisch wrote:
.
> You know what I was just wondering about? All these C-written 
> cross-platform libraries (which Python users benefit from, most probably 
> including evven you) that run on different unixes & windows, which are a 
> much greater diversity to handle than the not-even-yet-settled 
> differences between Py3K & 2.x. How the heck do they do that? 
.
I'm in the process of attempting a straightforward port of a relatively simple 
package which does most of its work by writing out files with a more or less 
complicated set of possible encodings. So far I have used all the 2to3 tools and 
a lot of effort, but still don't have a working version. This must be the worst 
way to convert people to unicode. When tcl went through this they chose the 
eminently sensible route of not choosing a separate unicode type (they used utf8 
byte strings instead). Not only has python chosen to burden itself with two 
string types, but with 3 they've swapped roles. This is certainly the first time 
I've had to decide on an encoding before writing simple text to a file.

Of course we may end up with a better language, but it will be a worse(more 
complex) tool for many simple tasks. Using a complex writing with many glyphs 
costs effort no matter how you do it, but I just use ascii :( and it's still an 
effort.

I find the differences in C/OS less hard to understand than why I need 
bytes(x,'encoding') everywhere I just used to use str(x).
-old fart-ly yrs-
Robin Becker