4 ms·

Yes. Following reasons: * I work a lot with low level data and I prefer strings to be an array of bytes. The forced unicode support is stupid for all my use ca

by sprash 9y ago

Yes. Following reasons: * I work a lot with low level data and I prefer strings to be an array of bytes. The forced unicode support is stupid for all my use cases. Also Unicode in 3.x support is rather flawed: http://www.cmlenz.net/archives/2008/07/the-truth-about-unicode-in-python http://www.cmlenz.net/archives/2008/07/the-truth-about-unico... * Major APIs now return iterators or views instead of simple lists. This is rarely justified introduces unnecessary complication in many cases. Everybody knows list, why not keep it simple. I can't count how often I list() all the things just to get things going and because I didn't bother to look up the API to check what types are returned. * I have to convert a lot of clear text data formats and needing to use 'print(x, end=" ")' instead of a simple 'print x,' is really cumbersome. I think printing something is absolutely substantial and it is justified for "print" be a statement. * There is a distinct performance loss if you directly compare 3.x to 2.x at least for all my use cases. * The sudden harsh break of backwards compatibility was completely unnecessary and stupid. Why not introduce new features slow and mark old features as deprecated or allow to specify the version in the header. There are a lot of ways one could handle this better. * Python 3.x may be a marginally better (e.g more consitent) language than 2.x. For me it only introduces inconveniences. It takes a huge amount of effort to port code from 2.x to 3.x (if you want to keep it clean and readable). The practical benefits are close to zero (and you even loose performance). This is why the community seems to agree to stay with 2.x for a very long time.

deathanatos 9y ago
> The forced unicode support is stupid for all my use cases. bytes and bytearray are still there … if you don't want to work with unicode data in a proper Unicode type, you don't have to. But it doesn't follow that the rest of us that do want a good type for text shouldn't be able to have a good type / tooling for that. (If you mean that functions that take text require text as input now, well, yeah.) > Also Unicode in 3.x support is rather flawed The entirety of "Internal Representation" is out of date, and no longer correct. For just about every other section, I believe libraries readily exist in PyPI to solve those problems. I do agree that it would be nice to have some of that closer to the standard library. > I have to convert a lot of clear text data formats I find it strange that you work with text formats, but you dislike having a proper text type? Even if you data were mostly or all ASCII, Python's text handling would still be mostly transparent, just silently doing the right thing if non-ASCII ever were encountered. > I think printing something is absolutely substantial and it is justified for "print" be a statement. I'm going to disagree. Python 2's print statements special syntax just adds cognitive load to reading, and to newcomers encountering such syntax, that just doesn't need to be there. Further, the trailing comma for "no EOL" is too subtle from a readability perspective. > Major APIs now return iterators or views instead of simple lists. This is rarely justified introduces unnecessary complication in many cases. The old APIs forced materialization of an iterable to a list, and there are plenty of circumstances where this just isn't required. This results in higher memory usage, for that list. The list() also makes it explicit where such materialization happen. You can always get a list from an API/function that uses generators. You can't go the other way.

by sprash 9y ago

deathanatos 9y ago

> The forced unicode support is stupid for all my use cases. bytes and bytearray are still there … if you don't want to work with unicode data in a proper Unicode type, you don't have to. But it doesn't follow that the rest of us that do want a good type for text shouldn't be able to have a good type / tooling for that. (If you mean that functions that take text require text as input now, well, yeah.) > Also Unicode in 3.x support is rather flawed The entirety of "Internal Representation" is out of date, and no longer correct. For just about every other section, I believe libraries readily exist in PyPI to solve those problems. I do agree that it would be nice to have some of that closer to the standard library. > I have to convert a lot of clear text data formats I find it strange that you work with text formats, but you dislike having a proper text type? Even if you data were mostly or all ASCII, Python's text handling would still be mostly transparent, just silently doing the right thing if non-ASCII ever were encountered. > I think printing something is absolutely substantial and it is justified for "print" be a statement. I'm going to disagree. Python 2's print statements special syntax just adds cognitive load to reading, and to newcomers encountering such syntax, that just doesn't need to be there. Further, the trailing comma for "no EOL" is too subtle from a readability perspective. > Major APIs now return iterators or views instead of simple lists. This is rarely justified introduces unnecessary complication in many cases. The old APIs forced materialization of an iterable to a list, and there are plenty of circumstances where this just isn't required. This results in higher memory usage, for that list. The list() also makes it explicit where such materialization happen. You can always get a list from an API/function that uses generators. You can't go the other way.