Review: Python version 3.3.2

July 15, 2013

I must admit I’ve a lot of respect to Guido van Rossum who is the original creator of the Python language because his drastic move to improve Unicode support with all text strings being Unicode by default as well as awesome bytes/Unicode separation. The most recent python version 3.3.2 that fixes crash in the ASCII decoder on m68k has new features compared to “Python 3000” which remain one of the most incompatible Python releases I have ever come across. Version 3.3.2 has more changes than previous versions that are significant for all Python users. Nonetheless, after using it for two months, Python latest version does not really represent much change as such. As the case with a new programming language releases, the misc and news file in source distribution contains a wealth of detailed information about every small thing that was changed.

These latest version 3.3.2 release has an extended support for this end-of-life release and this means that all recent standard library improvements are available now. Life is easier for newcomers because core language such as print and exec being statements, integers using floor division have been adjusted to be easier for newcomers to learn and to be more consistent with the rest of the language. Interestingly, all classes are now new style. The new python document provides a good overview of the major language changes and likely sources of incompatibility with existing Python code. Apart from vocational programmers, my alpha brothers and sisters would agree with me that broader Python ecosystem has accumulated a huge amount of quality software over the years. I would want to advise that unicode is sophisticated and Python’s latest version 3.3.2 seems not to care about unicode.

Python unicode does not replace one letter with two when changing the case and also be aware that it doesn’t allow locale information for character mappings. Also, another prominent challenge is that Python uses UCS4 or UCS2 internally. A programmer who has an UCS2 build, len called on strings does not give the number of characters in the string although the number of UCS2 interpreted characters that might not be the same and all letters outside the basic plane are wrongly counted.  In my experience, I have learned that binary extensions have to be compiled for UCS2 and UCS4 pythons separately. What irritates me is that setuptools only partly allow programmers to publish both builds on pypi and select the accurate one. Python 3.3.2 has degraded bytestrings from strings to celebrated integer arrays and enforced unicode on non-unicode protocols. I have also found it very difficult to convert such libraries that require unicode to Python 3.3.2 since 2 to 3 assumes the creators assume one is using byte strings and not unicode. After a couple of weeks working with 3.3.2 I’m more disgusted with Python. Why did for example creators fail to appreciate that allowing access to new features of the language and adding more vibrant support for compiler optimizations among others would do justice the python community.

Contador Harrison