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 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 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 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 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 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 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 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 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 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 python binary (ie,
Python 3 venvs don't normally really embed their own copy of Python (on Unix)
Why I write recursive descent parsers (despite their issues)
How I think I want to drop modern Python packages into a single program
When the Go garbage collector will panic over bad pointer values
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
I'm now a user of Vim, not classical Vi (partly because of windows)
Some notes on what Fedora's DNF logs and where
Permanent versus temporary redirects when handling extra query parameters on your URLs
My take on permanent versus temporary HTTP redirects in general
Menu