Python virtual environments transparently add themselves to sys.path

I have recently been exploring some aspects of Python's virtualenvironments , so Ithought I had a reasonable understanding of how they worked. In the HN discussion of my entry on installing modules to a custom location , I saw someone say that you could just run thevirtual environment's python binary (ie, /bin/python, which is normally a symlink to the system Python )without 'activating' the virtual environment and it would stillfind the modules that you'd installed in the


Python 3 venvs don't normally really embed their own copy of Python (on Unix)

Python 3 has standard support for virtual environments . The documentation describesthem in general as:

[...] a self-contained directory tree that contains a Pythoninstallation for a particular version of Python, plus a number ofadditional packages.

As a system administrator, a 'self-contained directory tree' thathas a particular version of Python is a scary thing to read about,because it implies that the person responsible for keeping thatversion of Python up to date on security patches, bug fixes, andso


Why I write recursive descent parsers (despite their issues)

Today I read Laurence Tratt's Which Parsing Approach? ( via ), which has adecent overview of how parsing computer languages (including littledomain specific languages) is not quite the well solved problemwe'd like it to be. As part of the article, Tratt discusses how recursive descent parsers have anumber of issues in practice and recommends using other things,such as a LR parser generator.

I have a long standing interest in parsing, I'm reasonably wellaware of the annoyances of recursive descent


How I think I want to drop modern Python packages into a single program

For reasons beyond the scope of this blog entry, I'm consideringaugmenting our Python program to log email attachment informationfor Exim touse oletools to peerinside MS Office files for indications of bad things. Oletools isnot packaged by Ubuntu as far as I can see, and in any case it wouldbe an older version, so we would need to add the oletools Pythonpackages ourselves.

The official oletools install instructions talk about using eitherpip or setup.py. As a general rule, we're very


When the Go garbage collector will panic over bad pointer values

For some time, I've vaguely remembered that the Go garbage collectoractually checked Go pointer values and would panic if it found thatan alleged pointer (including unsafe.Pointer values) didn't point to avalid object. Since the garbage collector may interrupt you atalmost random points, this would make it very dangerous to playaround with improper unsafe.Pointer values. However, this wasjust a superstitious memory , so todayI decided to find out what the situation is in current Go by readingthe relevant


Rolling distribution releases versus periodic releases are a tradeoff

In reaction to my entry on the work involved for me in upgradingFedora , Ben Cotton wrote a useful entry, Whatdo “rolling release” and “stable” mean in the context of operatingsystems? .In the entry, Ben Cotton sort of mentioned something in passingthat I want to emphasize, which is that the choice between a rollingrelease and a periodic release is tradeoff, not an option wherethere is a clear right answer.

In the Linux world, fundamentally things change because the upstreamsof our software


I'm now a user of Vim, not classical Vi (partly because of windows)

In the past I've written entries (such as this one )where I said that I was pretty much a Vi user, not really a Vim user,because I almost entirely stuck to Vi features. In a comment on myentry on not using and exploring Vim features ,rjc reinforced this, saying that I seemed to be using vi instead ofvim (and that there was nothing wrong with this). For a long time Ithought this way myself, but these days this is not true any more


Some notes on what Fedora's DNF logs and where

In comments on my entry on why Fedora release upgrades arecomplicated and painful for me , Ben Cotton wound up asking me to describe my desiredexperience for DNF's output during a release upgrade. This caused meto go out and look at what DNF actually logs today (as opposed to itsconsole output), so here are some notes. The disclaimers are that thisis on my Fedora systems, which I think are reasonably stock but may notbe, and that this isn't documented that I could find


Permanent versus temporary redirects when handling extra query parameters on your URLs

In yesterday's entry on what you should do about extra queryparameters on your URLs , I said thatyou should answer with a HTTP redirect to the canonical URL of thepage and that I thought this should be a permanent redirect insteadof a temporary one for reasons that didn't fit into the entry.Because Aristotle Pagaltzis asked, hereis why I think permanent redirects are the right option.

As far as I know, there are two differences in client behavior(including web spider behavior) between permanent HTTP


My take on permanent versus temporary HTTP redirects in general

When I started digging into the HTTP world (which was around thetime I started writing DWiki ), the major practical difference betweenpermanent and temporary HTTP redirects was that browsers aggressivelycached permanent redirects. This meant that permanent redirectswere somewhat of a footgun; if you got something wrong about theredirect or changed your mind later, you had a problem (and otherpeople could create problems for you ).While there are ways to clear permanent redirects in browsers, they'regenerally so intricate that you can't