On 28/06/2010 09:29, John Bokma wrote:
Tim Golden<m...@timgolden.me.uk> writes:
On 28/06/2010 00:03, eric_dex...@msn.com wrote:
It should be easier to have a large number of python versions on one
machine... I am realy fond of 2.5 so I am probily going to start
compiling them or just include the python2.5 exe if I port stuff and
settle it that way..
I have Python versions 2.1-2.7 and 3.0-3.2 installed on my Windows
box without any problems. I don't often have to use the full range
(mostly, in fact, for confirming that my unit tests still run on
my few released modules). But I certainly do use several different
ones each day where I have to make sure I'm running the same version
as the user who's experiencing a problem.
One technique I find particularly handy is to create a pythonxx.exe
hardlink in my c:\tools (which is always on my path), pointing to
c:\pythonxx\python.exe in turn. Then it's just a matter of: python25
my-script.py
Even without that, it's only a question of c:\python25\python my-script.py
if I need to.
I have in the past used a crude shebang-alike Python pre-processor
which hands off to the right version. It's a bit sluggish, though,
and that outweighed for me the slight convenience. YMMV
You might want to look into the assoc command to (temporarily) associate
.py& co with a different version of Python.
Thanks for the idea. ISTR playing around with this in the past. Ultimately,
though, it's typically a one-off run I'm doing (possibly repeated several
times while I fix the problem!) and the assoc will affect all open sessions
even if I revert it later, so I haven't gone down that route.
I do have a version-switcher script which makes whichever Python exe
runs it the default / on the path / etc. which is a sort of poor man's
virtualenv. (And predates virtualenv, in my defence). But even that I
use rarely.
TJG
--
http://mail.python.org/mailman/listinfo/python-list
