'import site' failed; use -v for traceback

If you suddenly start seeing this error every time you try to run Python:

'import site' failed; use -v for traceback

Chances are you have an erroneous file in your site-packages directory that's screwing up Python's import path initialisation and could lead to you being unable to import some installed modules.

To figure out which file this is you can use the Python debugger, pdb:

> python -v
>>> import pdb
>>> pdb.pm()
> [python_lib_path]/posixpath.py(173)exists()
-> return False
(Pdb) u
> [python_lib_path]site.py(146)addpackage()
-> f.close()
(Pdb) f
<closed file '[site-packages]._blah.pth', mode 'rU' at 0x52c38>

Your actual output will be quite a bit different with a lot of debugging information spewed into the console but let's explain what's going on here:

1. Run Python in verbose mode to get a traceback.
2. import pdb
3. Run the pm (postmortem) function to enter the (Pdb) shell and inspect the exact point at which the error occured.
4. Go up a level in the stack with u.
5. Inspect the f file object.

This tells us that ._blah.pth is causing Python's site import routine to choke. [bug report]

Move this file out of site-packages and try again, repeating the steps above if you get the same error.

When you run Python, it runs through all the directories specified by your PYTHONPATH environment variable, looking for .pth files. These can contain further directories to be added to the import path and are typically created by python packaging systems like easy_install. [more info on .pth files]

So what's up with this one?

The so called "dot-underscore" or AppleDouble files are actually created by Mac OS X. They contain resource forks and extra file metada for their corresponding file (the example we found earlier contains metadata for a legitimate file blah.pth).

Mac filesystems like HFS+ support resource forks natively and don't need these files, so they aren't usually created when you're accessing your machine locally. They can get created when you're accessing it over a network using the Samba protocol or if the connecting Mac otherwise thinks you don't support resource forks—usually if you're on Windows or an NFS filesystem.

You can safely delete these files from the site-packages directory and Python should be back to normal.

Ordering related objects in Django

Django models have a meta option order_with_respect_to that allows you to order objects within the scope of a related ForeignKey object.

This option adds an _order column to the model's database table to keep track of this ordering.

That's all very well, but if you need to change the sequence order you may well feel at a loss. The official documentation makes no mention of this option beyond a basic explanation of its purpose , and editing your objects in the built in admin app reveals no user interface for changing the ordering either. [1]

Update Feb 2009: There's now a ticket for this functionality to be added to the docs.

I managed to uncover a Python interface by delving into Django's API internals [2]. An object with related models that order with respect to it is given two handy methods:

get_RELATED_order()
set_RELATED_order()

where RELATED is the lowercased model name of the ordered objects

class Entry(model.Model):
    # ... fields

class Comment(model.Model):
    entry = model.ForeignKey(Entry, related_name='comments')
    # ... more fields
    
    class Meta:
        order_with_respect_to = 'entry'

Given the above example models, you can retrieve the order of an entry's comments:

>>> entry = Entry.objects.latest()
>>> entry.get_comment_order()
[1, 2, 3, 4]

And change the ordering by passing a list of comment ids back in.

>>> entry.set_comment_order([2, 1, 4, 3])

N.B. Be sure to pass in the same ids returned by get_comment_order

Two other handy methods exist for the Comment objects, get_next_in_order and get_previous_in_order [3]

>>> comment = Comment.objects.get(pk=3)
>>> comment.get_next_in_order()
<Comment: 4>
>>> comment.get_previous_in_order()
<Comment: 2>

1. A very early ticket is still open to restore this functionality to the admin app, and recent activity suggests it may well reappear soon. See also this thread on the django-developers mailing list. back


2. Look particularly at the two helper functions method_set_order and method_get_order in django.db.models.base. back


3. Theoretically at least, there's still a bug in get_previous_in_order but it should be fixed soon. Update: Fixed by the queryset-refactor back