Seven pet h8s: Verity is sorely vexed

"Real time systems tend to have real world consequences when the software misbehaves."

Reminded me of working on software to control a tank turret. After an unfortunate accident, a large lump of nickel steel was attached to the turret, and ditto to hull, to prevent the turret rotating too far and taking the cabling with it, along with the damage to a human occupant.

Working on the thing from the inside, it was less than encouraging to notice the large dents in the lumps of nickel steel, and having to hope that the welds were still sound.

As a fairly heavy-duty Python coder

I don't understand the resistance to Python 3.

I *do* understand the issues it causes with legacy codebases, and how the pain involved in porting an existing codebase to the new version (where even possible), may not make sense. This, in turn, may result in needing to write new code in older versions of Python so they work with these legacy codebases. I have to do this myself, and find it manageable. (I have also successfully ported existing code libraries, though they were all pure Python with no C extensions.)

Aside from maintaining legacy codebases, though, I don't really understand why anyone would prefer the 2.0 branch. As someone who started with Python back in 2.2, I personally find the 3.x dialect's modest syntax changes and its library reorgs sensible, useful, and less obtuse in a number of ways.

Tying in to the discussion of Uncode text, I find the Py3K change to dealing with all strings as Unicode to be far more practical and safe in any context where you have to deal with non-ASCII data. Which these days means just about anything that touches text.

And finally, though I love working with Python, no, I'm not the biggest fan of the syntactic relevance of white space. I deal with it without serious issue, but I wouldn't mind at all if I didn't have to deal with it. That said, I really think anyone who can't deal with it doesn't really want to try. If interns opening and closing a Python source file in a text editor is actually a problem, that's pointing out a pretty serious deficiency in source code management. I'll agree it'd be much nicer to not need to worry about it, but come on, really.

Zed Shaw's rant

People have already lambasted Shaw's ignorance of why bytes and unicode need to be different underlying types. He mentioned a combined bytes/unicode object, but shows no understanding of why it came into existence. (Lazy scripters waste lots of cycles encoding and decoding the same string. By keeping the unicode and encoded versions together, python can recycle an existing objects instead of creating new ones.) I noticed Shaw did not mention the new style classes available in python3 that make multiple inheritance work. It is almost as if he has left multiple inheritance in the tool box because he never recognised the right times to use it.

Python devs believed fixing python2's defects with multiple inheritance and unicode properly were going to require changes that would be incompatible with the existing language. They created python3. Shaw did not create a language compatible with Python2 that fixed the inherent flaws.

After a huge tiresome rant about the need for backward compatibility, Shaw recommended deleting python's legacy string formatting mechanisms. I could not find the words to express what I thought about that, but someone has helpfully created a suitable web page here.

>Well, I say "okay". Actually it is a pig to use, and its makefiles tend to be as robust and immune to environmental changes as a mechanical wristwatch fashioned from ice. But at least it was standard.

Verity -- that rationality, on both sides -- I think I just fell in love with you.