2014-01-16
Link: Armin Ronacher's 'More About Unicode in Python 2 and 3'
Armin Ronacher's More About Unicode in Python 2 and 3 contains a lot of information about the subject from someone who works with this stuff and so is much better informed about it in practice than I am. A sample quote:
I will use this post to show that from the pure design of the language and standard library why Python 2 the better language for dealing with text and bytes.
Since I have to maintain lots of code that deals exactly with the path between Unicode and bytes this regression from 2 to 3 has caused me lots of grief. Especially when I see slides by core Python maintainers about how I should trust them that 3.3 is better than 2.7 makes me more than angry.
I learned at least two surprising things from reading this. The first was that I hadn't previously realized that string formatting is not available for bytes in Python 3, only for Unicode strings. The second is that Mercurial has not and is not being ported to Python 3. As Ronacher notes, it turns out that these two issues are not unrelated.
For me, the lack of formatting for bytes adds another reason for not using Python 3 even for new code because it forces me into more Unicode conversion even if I know exactly what I'm doing with those unconverted bytes. Since I use Unix, with its large collection of non-Unicode byte APIs, there are times when this matters.
(For instance, it is perfectly sensible to manipulate Unix file paths as bytes without trying to convert them to Unicode. You can split them into path components, add prefixes and suffixes, and so on all without having to interpret the character sets of the file name components. In fact, in degenerate situations the file name components may be in different character sets, with a directory name in UTF-8 and file name inside a subdirectory in something else. At that point there is no way to properly decode the entire file path to meaningful Unicode. But I digress from Armin Ronacher's article.)
Debian does not have long term support
Every so often someone says that Debian's stable releases have a long support period. Unfortunately this is what one would call 'wrong', and for at least two reasons.
(For now, let us define 'support' here as 'gets security fixes'.)
First, it is wrong as a plain matter of fact. No Debian release has ever been supported for more than a sliver over four years, and only one release has hit that mark (Debian 3.0 'woody', released mid 2002 and supported through mid 2006, per here). Every release since 2005 has been supported for only about three years. Ubuntu LTS manages five years; Red Hat Enterprise Linux goes even longer.
Second, it is wrong as a philosophical matter because Debian doesn't promise any particular support period. Debian doesn't promise to support a release for X years, just more or less to support it for a year after the next release comes out. If the next release comes out in roughly two years (as has been the case since 2005), you get three years. If the next release comes out in a year, you get two years. And so on. The only way you get long support periods is if Debian is painfully slow to make releases.
This has two consequences. First, Debian support periods are unpredictable. If you install a machine with Debian, you have no sure idea how long you'll have support for (although you can often make an informed guess). Second, the real support period for a machine can be as low as a year, if you have to install a machine shortly before the next release comes out.
(In theory the minimum period is even lower, but this would likely require Debian to do two releases in a year. This seems, well, unlikely.)
Real long term support involves three things. First, you must commit up front to a definite support period (as Ubuntu and Red Hat do). Second, you must actually have a long support period (which is always shorter than it looks in practice); three years doesn't really cut it even if Debian committed to that for releases (which they are not going to do so). Third, you need a significant support overlap between the current release and the previous release because of the real support period issue.
Debian does none of these, which is fair enough; Debian doesn't claim it has long term support. I just wish people would stop claiming that it did on its behalf.