Review: Python version 3.3.2
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 in Python 3.0, compared to “Python 3000” which
remain one of the most incompatible Python releases I have ever come across.
3.3.2 has more changes than previous version that are significant for all
Python users. Nonetheless, after using it for weeks, Python latest version does
not really represent much change as such. As the case with a new programming
language release, the misc/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 only available in Python 3.x. 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.
Comments
Post a Comment