Python 3.4 Released 196
New submitter gadfium writes:
"Python 3.4 has been released. It adds new library features, bug fixes, and security improvements. It includes: at standardized implementation of enumeration types, a statistics module, improvements to object finalization, a more secure and interchangeable hash algorithm for strings and binary data, asynchronous I/O support, and an installer for the pip package manager."
Re: and... (Score:4, Informative)
This exactly.
If your UTF-8 string is not completely valid, Python 3 barfs in useless and unpredictable ways. This is not a problem with Python 2.x.
Until they fix the string so that an arbitrary sequence of bytes can be put into it and pulled out *UNCHANGED* without it throwing an exception then it cannot be used for any serious work. Bonus points if this is actually efficient (ie it is done by storing the bytes with a block copy).
Furthermore it would help if "\xNN" produced raw byte values rather than the UTF-8 encoding of "\u00NN" which I can get by typing (gasp!) "\u00NN".
Re: and... (Score:5, Informative)
This is why there's a bytes type.
If what you have is not text, don't use the text type.
Re: and... (Score:5, Informative)
The inconsistencies are fully within Python 2. My experience is closer to full-scale horror when having to consider different encodings in Python 2, and since I am from a country that actually needs these "bells and whistles" regarding encoding for regular I/O on a regular basis, I have met these issues many times. Using chains of codecs to read and write files, having to intercept exceptions and .encode() .decode() in differing combinations to be able to avoid Python 2 "double-crashing" when reporting an exception, deep level hacking to reinitialize sys.stdout before output on certain machines, etc.
In Python 3, it does not "just work", but that is because character encoding is never a "just works" problem, and languages that say it is fail miserably in this regard as soon as it meets real world international encodings. Python 3 defines the problem correctly, and solves it natively in the best way I can imagine, by always being aware of the problem. No more prepending the u qualifier to every single string that might or might not be output (or combined with any other string that might or might not be output). Python 3 solves it correctly, by acknowledging character encoding as something that is actually an issue, and it does not make the silly assumption that ASCII is the way of the world. This assumption has been silly for at least 40 years, but many products were developed in ASCII centric regions, or at least in regions where you seldom saw more than one encoding, and never fully addressed the problem.
The Python 3 standard library does strings right , and should get credit for it. Instead it gets flac from programmers who do not like that it does not inherit the quirks from Python 2 that we have become accustomed to (and are still miles better than in many other languages; PHP and unicode, anyone?).
Heck, the number one reason that I have converted as many projects as I can to Python 3 is because of the blocks of encoding centered Python 2 code I can just throw out the window, and ease future maintenance. There are still some big module holdouts, but that was a much larger problem in ~2010. Today, the ones I miss in Python 3 are e.g. WXPython (where work is ongoing in the Phoenix project) and MySQLdb (the MySQL connection alternatives for Python 3 are outright silly -- either non-functional or non-documented).
There are several introductory programming courses I know of that focuses on Python, and they all use Python 3 by default. I am sincerely looking forward to the day when Python 3 is the natural order.
It takes a lot of motivation to change language structures from Python 2, and those working on the drafts are certainly top-class in their fields, so if one finds any design changes weird, the first instinct should be to read up on the rationales for the decisions. I have yet to encounter a change that seems "silly" or unnecessary after reading about the process.
Also, for the early adopters, not that Python 3.3 (och 3.4, as this article is about) is not 3.0 or 3.1. There is a lot of things that have been fixed along the way.