On Tue, Dec 23, 2014 at 12:06 AM, Liam Marsh
"""That's suggesting mixing and matching between versions within the same process space, which is highly unlikely to work correctly (except when modules are specifically designed for that, as indicated by the availability of backported versions on PyPI)."""
In fact, i was thinking about a small program, which just analize the file for these commentaries, and asks the OS to launch the appropriate "real" python environnement, and finishes.
If you just want to have the initial script control its version, then that can be done. Put an appropriate shebang at the top of the file, use the py.exe launcher on Windows, and that'll all work.
This small program will be also be able to chose the appropriate version by scanning the import statements, and seeking for these imported modules in the different environnements installed.
Not sure what you mean here, but if you use multiple different interpreters all installed concurrently, they'll each have their own separate module trees. Or do you mean different versions of imported libraries (so you could have, for instance, numpy 1.8.2 for this project, and numpy 1.9.1 for another)? In that case, you'd do well to use virtual environments, which cope just fine with this kind of thing. The one thing you *cannot* do easily is have an application request one Python version, and one of its imported modules request a different Python version. Similarly if you have two modules that each import the same third module; the nature of Python's import machinery is such that they have to get the same version (in fact, the same module). Within one execution space, you have to be consistent, or else go through some serious hoop-jumping to keep things separate. ChrisA