I have a bit of a dilemma when it comes to sys.path and the location of the site-packages directory. The problem comes when someone is using Mailman 2.1 with Python 2.2. The latter comes with the email package, which is in the standard library. Through some contributions, my standalone email package now supports multibyte character sets in RFC-compliant ways (e.g. splitting long headers correctly). The question is, how do I get the updated package to Python 2.2 users? The standalone email package is a simple distutils thingie with a directory and a bunch of .py files. distutils sticks this in site-packages. But an "import email" will always get the standard library version instead of the site-packages version because site.py /appends/ site-packages to sys.path instead of prepending it. I can work around this by adding my own path-hacking code before any import of email.* modules. This is a bit ugly because now it means that the proper functioning of the application depends on import order, and that's nasty. So the question is: why does site.py append site-packages instead of prepending it to sys.path? If there's a valid reason, I don't remember it, and I'm currently blind to any valuable use case. If there's no good reason, it would seem to me that the following use case is better served by prepending: - We want to provide an enhanced version, or a fixed version of a module or package. Distribute it w/distutils and do a normal install. As long as you don't start Python w/ -S, you'll always get the improved version. Don't want the improved version? Start Python w/ -S or just don't ever install the new package. I'm mostly looking for rationale right now, before I try to decide whether it's something worth debating and/or changing. Thanks, -Barry