Home/ Questions/Q 7775473
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T17:38:25+00:00

Edit: based on a Ulf Rompe’s comment, it is important you use 1 instead

  • 0

Edit: based on a Ulf Rompe’s comment, it is important you use “1” instead of “0”, otherwise you will break sys.path.

I have been doing python for quite a while now (over a year), and I am always confused as to why people recommend you use sys.path.append() instead of sys.path.insert(). Let me demonstrate.

Let’s say I am working on a module named PyWorkbooks (that is installed on my computer), but I am simultaneously working on a different module (let’s say PyJob) that incorporates PyWorkbooks. As I’m working on PyJob I find errors in PyWorkbooks that I am correcting, so I would like to import a development version.

There are multiple ways to work on both (I could put my PyWorkbooks project inside of PyJob, for instance), but sometimes I will still need to play with the path. However, I cannot simply do a sys.path.append() to the folder where PyWorkbooks is at. Why? Because python will find my installed PyWorkbooks first!

This is why you have to do a sys.path.insert(1, path_to_dev_pyworkbooks)

In summary:

sys.path.append(path_to_dev_pyworkbooks)
import PyWorkbooks # does NOT import dev pyworkbooks, imports installed one

or:

sys.path.insert(1, path_to_dev_pyworkbooks) # based on comments you should use **1 not 0**
import PyWorkbooks # imports correct file

This has caused a few hangups for me in the past, and I would really like it if we (as a community) started recommending sys.path.insert(1, path), as if you are manually inserting a path I think it is safe to say that that is the path you want to use!

Or do I have something wrong? It’s a question that sometimes bothers me and I wanted it in the open!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    If you have multiple versions of a package / module, you need to be using virtualenv (emphasis mine):

    virtualenv is a tool to create isolated Python environments.

    The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.7/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded.

    Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application.

    Also, what if you can’t install packages into the global site-packages directory? For instance, on a shared host.

    In all these cases, virtualenv can help you. It creates an environment that has its own installation directories, that doesn’t share libraries with other virtualenv environments (and optionally doesn’t access the globally installed libraries either).

    That’s why people consider insert(0, to be wrong — it’s an incomplete, stopgap solution to the problem of managing multiple environments.

    • 0