Python is not really a fast language. People who use Python (meincluded) more or less accept this (or else it would be foolish towrite things in the language), but still we'd often like our codeto be faster. For a while the usual answer to this has been thatyou should look into PyPy in order to speedup Python. This is okay as far as it goes, and PyPy certainly canspeed up some things, but there are reasons to still care aboutCPython'

You may have heard of Lenovo's SuperFish incident ,where Lenovo destroyed HTTPS security on a number of their laptopsby pre-installing root certificates with known private keys. Well,now Dell's done it too ,and not just on consumer laptops, and it turns out not just one badcertificate but several. One could rant about Dell here, but there'sa broader issue that's now clear:

PC vendors have become hostile parties that you cannot trust .

Dell has a real brand. It

I recently wrote about how weshouldn't be making up new (web) templating packages but insteadshould just use existing ones. This leads me to admit that I havea little problem here with Python, in that I don't currently haveone of these that I'd use. Well, sort of.

If I was to write another relatively substantial web application, I'dunquestionably use Django (and thus I'd use Django's templating systemand form handling). It's

I mentioned a while back that I hadset up autocompletion in GNU Emacs for Go, using gocode and the auto-complete Emacs package . I also mentioned that I wasn't sureif I liked autocompletion and was going to stick with it. Well, theverdict is in for now; I found it too annoying and I wound up turningit off. However, I still kind of miss it. Thinking about what Imiss and what made me hate it enough to turn it off has led me towhat

If you read about new version control systems these days, it's verycommon to see them put forward as essentially the expression ormanifestation of mathematics. Maybe it's graph theory, maybe it'spatch theory, but the basic idea is that you build up some formalmodel of patching or version control and then build a VCS systemthat implements it. This is not restricted to recent VCSes, either;version control as a whole has long had a focus on formally correctoperations (and on avoiding operations

There once was a time where I felt that I more or less solidly knewand understood Python. Oh, certainly there were dark corners thatI wasn't aware of or that I knew little or nothing about, but asfar as the broad language went I felt that I could say that I knewit. Whether or not this was a correct belief, it fed my confidencein both writing and reading Python code. Of course the wheels sortof started to come off this relatively early , butstill I had

So this happened:

@thatcks :I think I just ruined my bisect run with one errant 'hg bisect --bad',because I can't see a way to recover from it in the Mercurial docs.
This is my extremely angry face. Why the hell won't Mercurial give mea list of the bisect operations I did? Then I could fix things.
Instead I appear to have just lost hours of grinding recompilation toa UI mistake. And Mercurial is supposed to be the friendly VCS.

There have been essentially public areas on the 'net for a longtime (from the time before the 'net was the Internet). In all ofthat time, a pattern that repeats over and over is that they getused for what I'll call closed discussions among an in crowd.These discussions happen in public (in a Usenet newsgroup, on apublic mailing list or website, on IRC, on Twitter, etc) so they'renot private, but they're not public in the

One reaction to my entry saying you shouldn't create new templatinglanguages is to ask why this is so. Myoriginal entry was written from the perspective of someone who'sactually done this so I just assumed that all of the problems withcreating your own were obvious, but this is not necessarily thecase. So let's run down the problems here.

When you create a new web templating system, you face a number ofproblems:

• You need to design the templating language. Language design ishard