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 -- http://mail.python.org/mailman/listinfo/python-list
