Blog Archive

Viewing page 1 of posts tagged "Python" from June 08, 2013\ to July 04, 2015\ .

Static Libraries in a Dynamic World

Creating more honest versions of wrapped APIs.

There is a common pattern when using bindings for C libraries that work against the dynamic language I'm working in: the conceptual packages in the library (which are exposed as header includes, and so provide no extra overhead to use in your code) are actually packages in the binding.

Unless they are flying in the face of good practices, the dynamic language user actually has to work harder to identify a specific function/variable than the static language user would!

The Problem

Let's look at an example Qt program written in C++:

 1 2 3 4 5 6 7 8 9 #include #include int main(int argc, char *argv[]) { QApplication app(argc, argv); QPushButton hello("Hello world!"); hello.show(); return app.exec(); } 

If we translate directly to Python, we are left with code that feels not only too specific, but puts more of a burden on the programmer than they would have with the static version of the library since they need to know exactly where every object comes from:

 1 2 3 4 5 6 7 import sys from PyQt4 import QtGui app = QtGui.QApplication(sys.argv) hello = QtGui.QPushButton("Hello world!") hello.show() exit(app.exec_()) 

This is something I encounter all the time. For example, in PyQt/PySide, the Adobe Photoshop Lightroom SDK, PyOpenGL, Autodesk's Maya "OpenMaya", PyObjC use of Apple's APIs, etc..

Posted . Categories: .

Repairing Python Virtual Environments

When upgrading Python breaks our environment, we can rebuild.

Python virtual environments are a fantastic method of insulating your projects from each other, allowing each project to have different versions of their requirements.

They work (at a very high level) by making a lightweight copy of the system Python, which symlinks back to the real thing whenever necessary. You can then install whatever you want in lib/pythonX.Y/site-packages (e.g. via pip), and you are good to go.

Depending on what provides your source Python, however, upgrading it can break things. For example, I use Homebrew, which (under the hood) stores everything it builds in versioned directories:

$readlink$(which python)
../Cellar/python/2.7.8_2/bin/python


Whenever there even a minor change to this Python, symlinks back to that versioned directory may not work anymore, which breaks my virtual environments:

$which python /usr/local/bin/python  In a similar stream, I often want to know the location of a Python package or module that I am importing, or what entry points are available in the current environment. Lets write a few tools which do just that. Read more... (1 minute remaining to read.) Posted . Categories: . Where Does the sys.path Start? Constructing Python's import path Importing modules in Python seems simple enough on the surface: import mymodule looks across the sys.path until it finds your module. But where does the sys.path itself come from? Sure, there is a $PYTHONPATH variable which "augments the default search path for module files", but what is the default search path, how is it "augmented", how does easy_install or pip fit into this, and where does my package manager install modules?

Posted . Categories: .

When Two Packages Fight for a Name

Pillow, the [un]friendly fork of PIL.

Many of us have had the "pleasure" of working with a pair of forked projects. Normally, this is an exercise in patience and reading code with extreme precision, but sometimes it is a whole other level of frustration.

In particular, I have spent a lot of time banging my head on FFmpeg and Libav, both of which generally provide identically named shared libraries which provide identically named exports, but are slowly diverging and offer slightly different functionality. Perhaps I am a complete n00b, but I have found it anything but easy to anticipate which one I will get when I install or later call upon anything prefixed with "ffmpeg" or "av", let alone develop code against them.

Because of that, I was very concerned when I started taking a serious look at Pillow, the self-dubbed "friendly" fork of PIL. On the surface, I am in love with the project and its call to action. However, I am afraid of the project's assumption of the "PIL" namespace, and how that will inevitably break other code in interesting ways.

Posted . Categories: .

Dictionary Building for Word-Search

Mining Wikipedia for a "geek" lexicon.

One of the local pubs styles itself after geek/nerd culture (e.g. sci-fi, fantasy, and board games). The back of the coasters feature a word-search. It reports to contain 45 "geek words and phrases":

Writing code to solve a word-search isn't particularly tricky (if you remember to use a prefix trie) as long as you have a list of words to find, but in this case we are given no such clues.

But, since we are tremendously lazy, how can we solve this with code anyways?

Posted . Categories: .

Autocompleting Python Modules

Simplifying the search for modules to execute from a shell.

The last few times I overhauled an execution environment I required people to execute the bulk of their tools via python -m package.module instead of python package/module.py (to enable the development environment).

The downside is that you lose shell autocompletion, which can be a big deal if you have dozens of tools that you only occasionally use.

This addition to your ~/.bashrc fixes that.

Posted . Categories: .

@classproperty

Is this an amazing, or terrible idea?

Lets define a classproperty in Python such that it works as a property on both a class, and an instance:

class classproperty(object):

def __init__(self, func):
self.func = func

def __get__(self, obj, cls):
return self.func(cls, obj)


It can be used thusly:

class Example(object):

@classproperty
def prop(cls, obj):
return obj or cls

x = Example()
assert x.prop is x
assert Example.prop is Example


Is this a good idea, or a bad idea?

(Hint: I don't know.)

Posted . Categories: .

RenderMan Textures from Python

In order to better understand the guts of Python and RenderMan, in the past I have implemented a number of proof of concept projects extending or embedding each. Previously, I combined my efforts by embedding Python into RenderMan as an RSL shadeop so that shaders could be written in Python!

Unfortunately, that code is lost to the ages, so I decided to revisit my efforts and produce something that could actually have applications: using Python as a source of texture data for RenderMan.