3 ms·
With respect to Python 3, I think it /is/ in fact a similar but different language. Primarily my focus is not on small annoying easily covered things (a print(
by mjevans 10y ago
With respect to Python 3, I think it /is/ in fact a similar but different language.
Primarily my focus is not on small annoying easily covered things (a print() function is better than a print keyword), but on more systemic changes like it's decision to make a unicode str the default type of string for the language.
I would like to see a new version of Python (maybe 4?) that centers around basic, commonly atomic, types and arrays of those types. This would prevent the issue of Python 3 either mangling input strings or choking as it tries to digest legacy input that isn't in the anticipated encoding (at the cost of not making the mess larger). It would not-modify data that is being passed through the language UNLESS requested as an operation or as an output filter (implicit operation). Traditional UNIX like 8 bit clean handling is why UTF-8 is a super set of ASCII (code-points above 0x7f undefined/locally specific); UTF-8 was able to define an in-situ character sync method and was still compatible with existing files, and programs that did not enforce a specific encoding on the data stream.
- est 10y agoPy3k's problem is lack of incentives. If Py3k is 30% faster in execution speed ppl will migrate in no time. But currently everything is do-able in py2.7 and maybe even faster. A successful example is PHP7.
- ubernostrum 10y agoIf you think Python 3 doesn't offer anything compelling, you haven't read about what's in Python 3.
- jsmeaton 10y agoI suspect for a lot of people the carrots aren't really that relevant compared to the cost of migrating. Async is one of the bigger ones and for us folks doing Django it's not on the menu. There are certainly quality of life improvements but nothing too ground breaking apart from async.
- mjevans 10y agoI suspect a reason Python 3 might 'be slower' would be precisely how expensive everything being a /validated/ (is it UTF-16 internal? Some other crazy Windows Native format IIRC) string, including internal object elements like names and dictionary (map) keys.
- guitarbill 10y agoUTF-8/UTF-16 are encodings, used to encode strings for transport/exchange. Internally, strings are stored in UCS-2 or UCS-4 representation. AFAIK, this hasn't changed between Python2 and Python3, after all, Python2 also supports unicode. It has more to do with what a "string literal" in source code means. I don't want to go into it too much, but in Py3, `"a"` is a unicode string literal equivalent to `u"a"` in Py2. Py3 `b"a"` is roughly the same as Py2 `"a"`. But note the ambiguity in Py2 - could be a sequence of bytes, or an ASCII encoded string. This is, of course, an oversimplification btw. But not too far of if you think how e.g. `from __future__ import unicode_literals` works in Py2. Is parsing UTF-8 literals in a file slower? Maybe negligibly. Does it affect runtime? I have no idea. Probably not, you can still do string comparisons byte for byte once you've converted to UCS-2/4. It might use more memory though.
- gsnedders 10y ago> UTF-8/UTF-16 are encodings, used to encode strings for transport/exchange. Internally, strings are stored in UCS-2 or UCS-4 representation. That makes no sense; UCS-2 and UCS-4 are encodings too.
- guitarbill 10y agoIt isn't completely false. It's a simplification (as UCS-* is often used to denote internal encodings), because oh god, Unicode. This does a great job at explaining some intricacies: http://lucumr.pocoo.org/2014/1/9/ucs-vs-utf8/ http://lucumr.pocoo.org/2014/1/9/ucs-vs-utf8/ Also, in Python 3, strings can be UCS-1 (latin1?), UCS-2 (UTF-16?), UCS-4 (UTF-32?) or other: https://www.python.org/dev/peps/pep-0393/ https://www.python.org/dev/peps/pep-0393/ It's complicated. Really complicated. Sorry.