4 ms·

It's still an opaque handler - as long as you're just passing the filename to other OS functions, everything works. If you're printing ("directly manipulating")

by eeZi 11y ago

It's still an opaque handler - as long as you're just passing the filename to other OS functions, everything works. If you're printing ("directly manipulating") it, however, you have to decide what to do about non-Unicode bytes.

saurik 11y ago
Even this is new, though; I don't remember when they fixed it, but Python 3.0 seriously would just ignore filenames that were not in the expected encoding... as in listing the files on the directory would just skip them as if hey were not in the folder... Python 3 had this big promise of solving a bunch of Unicode issues, but it doesn't really seem to have enabled anything not already possible--and not even terribly hard--in Python 2, while making a lot of missteps along the way and only very recently (as in, not even yet in Python 3.4, though committed to some development branch, per statements by others elsewhere on this thread) providing anything actuallt new in the area most often considered the "carrot" for upgrading to Python 3.
- thrownaway122 11y ago
  > Python 3.0 seriously would just ignore filenames Why are you worried about python 3.0?
  - saurik 11y ago
    You have to look at Python 3.0 to get a good understanding of what happened with the Python 3.x transition, as that was the critical moment that set the mentality of how people were going to view the people telling everyone "you need to port your stuff to Python 3"; when you see that some of the underlying complexity and issues still aren't fixed in 3.4 from the same decision, it is damming to the argument that Python 3 was really solving a real world problem at all. If nothing else, it means you have to start the transition clock not when Python 3 was first released, but from when it first manages to not be horribly worse than Python 2 by reasonably objective measures.
- eeZi 11y ago
  Python 3 did solve a bunch of Unicode issues (some of the fixes were backported to Python 2). The most important one is probably lack of consistency - while it's possible to enfore the bytes/Unicode barrier in Python 2, it's not intuitive and many programmers just ignore it. There was a recent LWN.net submission about the other carrots: https://news.ycombinator.com/item?id=9378898 https://news.ycombinator.com/item?id=9378898

by eeZi 11y ago

saurik 11y ago

Even this is new, though; I don't remember when they fixed it, but Python 3.0 seriously would just ignore filenames that were not in the expected encoding... as in listing the files on the directory would just skip them as if hey were not in the folder... Python 3 had this big promise of solving a bunch of Unicode issues, but it doesn't really seem to have enabled anything not already possible--and not even terribly hard--in Python 2, while making a lot of missteps along the way and only very recently (as in, not even yet in Python 3.4, though committed to some development branch, per statements by others elsewhere on this thread) providing anything actuallt new in the area most often considered the "carrot" for upgrading to Python 3.

thrownaway122 11y ago
> Python 3.0 seriously would just ignore filenames Why are you worried about python 3.0?
- saurik 11y ago
  You have to look at Python 3.0 to get a good understanding of what happened with the Python 3.x transition, as that was the critical moment that set the mentality of how people were going to view the people telling everyone "you need to port your stuff to Python 3"; when you see that some of the underlying complexity and issues still aren't fixed in 3.4 from the same decision, it is damming to the argument that Python 3 was really solving a real world problem at all. If nothing else, it means you have to start the transition clock not when Python 3 was first released, but from when it first manages to not be horribly worse than Python 2 by reasonably objective measures.
eeZi 11y ago
Python 3 did solve a bunch of Unicode issues (some of the fixes were backported to Python 2). The most important one is probably lack of consistency - while it's possible to enfore the bytes/Unicode barrier in Python 2, it's not intuitive and many programmers just ignore it. There was a recent LWN.net submission about the other carrots: https://news.ycombinator.com/item?id=9378898 https://news.ycombinator.com/item?id=9378898