Prev: Builtn super() function. How to use it with multipleinheritance? And why should I use it at all?
Next: numpy installation
From: Thomas Jollans on 25 Jul 2010 17:57
On 07/25/2010 11:10 PM, Edward Diener wrote:
> On 7/25/2010 3:39 PM, Christian Heimes wrote:
>> Am 25.07.2010 21:32, schrieb Thomas Jollans:
>>> If a script uses sys.executable instead of "python", there is no
>>> problem, at all.
>> It's true that sys.executable is the best way if you have to start a new
>> Python interpreter. However sys.executable may not be set for NT
>> services. So there may be a problem after all.
> Once you start instrusively changing scripts to find a solution to
> multiple versions of Python co-existing in one system, you are heading
> down a path of endless problems.
What exactly is it that you're afraid to change?
The standard library? There's certainly no need to change that in any way!
Your own code? That'd just be nonsense.
Someone else's then. Is there any problem at all when you start it with
a specific Python interpreter? I expect that there probably isn't. If
there is, if the code makes ANY assumptions about where to find a Python
interpreter on your system, I would consider that a serious bug that
should be reported. If it's only one or two affected lines of code, why
not change them? There's nothing intrusive or wrong about fixing
something on your own computer!
If it turns out that you'd have to change a lot of code to make it work,
THAT's the time to think about a complex workaround, like writing a
batch file that sets up an environment in which it works, for that
program. Otherwise, I don't think it's worth the effort.
I'm on a Linux system with multiple Python interpreters. (Almost) all
installed Python programs work with the system default interpreter
(CPython 2.6). Those that don't have been fitted with shebang lines like
"#!/usr/bin/python2.5". This tells the OS to use a different
interpreter, like the pystarter script solution proposed in this very
From: Steven D'Aprano on 25 Jul 2010 20:41
On Sun, 25 Jul 2010 15:19:53 -0400, Edward Diener wrote:
> On 7/25/2010 10:03 AM, Thomas Jollans wrote:
>> On 07/25/2010 02:46 PM, Edward Diener wrote:
>>> The problem with this is that you forget that a script can invoke
>>> Python internally. So whether one uses the console or file association
>>> method of invoking Python externally, any already written script can
>>> use either internally.
>> Maybe it's just me, but I think that a script that does this is quite
>> simply badly written: it *will* break on systems that have multiple
>> Python versions.
> Whether it is badly written or not in your opinion it is legal and
> happens all the time.
Yes, people write poorly written, buggy scripts all the time. Just
because code is legal syntax doesn't mean it does what is intended, or
that what is intended is sensible.
If you have multiple versions of Python installed, and you call "python
somescript.py" without knowing *which* Python will be called, it is
neither sensible nor does it do what you intend. End of story.
This is no different from calling any other application without knowing
what version you will get, then relying on features that are only
available in some versions. It is just buggy code.
> Are you going to refuse to use any script, no
> matter for what library or for what purpose, that internally invokes
> Python either through a 'python' command or through a file with a Python
> extension ? And how would you find out if a script did this or not ? Are
> going to search every script in every distribution and library to
> determine if it does this ? And when you find out a script does this,
> what will you do ?
Treat it like any script with a bug: fix the bug, stop using the script,
or determine a work-around that masks the bug. All three are acceptable,
the third being the least acceptable because it just leaves a bug waiting
to bite you again in the future.
> Be real. saying you do not like scripts that internally invoke Python
> does not solve anything if you have multiple coexisting versions of
> Python installed.
No, it solves it completely. Treat it as a bug, and fix it.
If you're not willing to treat it as a bug, then uninstall all but one of
the Python versions, and the problem goes away. You might have a
different problem, namely that some scripts stop working, but now the
solution is obvious and straight-forward: fix the scripts that aren't
Or rename the Python applications, so that scripts can easily call the
right version without getting confused.
Trying to make some brittle, Do-What-I-Mean solution for trying to auto-
magically select between Python versions is pursuing a path of endless
problems. Any solution that doesn't fix the actual problem, namely that
the scripts are buggy, is at best just a work-around and at worst is no
solution at all.
From: Edward Diener on 25 Jul 2010 23:08
On 7/25/2010 8:41 PM, Steven D'Aprano wrote:
> On Sun, 25 Jul 2010 15:19:53 -0400, Edward Diener wrote:
>> On 7/25/2010 10:03 AM, Thomas Jollans wrote:
>>> On 07/25/2010 02:46 PM, Edward Diener wrote:
>>>> The problem with this is that you forget that a script can invoke
>>>> Python internally. So whether one uses the console or file association
>>>> method of invoking Python externally, any already written script can
>>>> use either internally.
>>> Maybe it's just me, but I think that a script that does this is quite
>>> simply badly written: it *will* break on systems that have multiple
>>> Python versions.
>> Whether it is badly written or not in your opinion it is legal and
>> happens all the time.
> Yes, people write poorly written, buggy scripts all the time. Just
> because code is legal syntax doesn't mean it does what is intended, or
> that what is intended is sensible.
> If you have multiple versions of Python installed, and you call "python
> somescript.py" without knowing *which* Python will be called, it is
> neither sensible nor does it do what you intend. End of story.
Somebody is supplying you with a Python script and internally invoking
Python again. But that somebody does not have to be myself.
I am neither buying "End of story" nor that invoking Python internally
is an error. But if you believe it to be then you can root out all such
Python code, or correct it as you like. Even with co-existing versions
of Python installed I have better things to do with my time and
therefore will pursue a solution that will work for me in the face of
From: Steven D'Aprano on 26 Jul 2010 01:34
On Mon, 26 Jul 2010 00:36:47 -0400, Edward Diener wrote:
> On 7/25/2010 10:42 PM, David Robinow wrote:
>> Edward, I'm having a really hard time understanding your problem. Could
>> you give an example of some real code that is causing you difficulty?
> I start a Python script for version X by going to X's root directory and
> invoking 'python someScript.py' from the command line. Does that not
> sound reasonable ?
No it doesn't, it's a very unreasonable thing to do.
If you have multiple versions of Python, you should name them
appropriately so you can launch the appropriate version from any
python26 someScript.py # calls python31 secondScript.py internally
python31 anotherScript.py # calls python25 thirdScript.py internally
Or give the full path to the executable:
# calls C:\Programs\python31\python.exe secondScript.py internally
If a script doesn't do this, then the script should be treated as buggy.
> In SomeScript.py there is an internal call to 'python someOtherScript.y
That's a pretty dodgy thing to do in the first place, unless you can
guarantee that there's only one executable called python. Otherwise, how
do you know which one will be called? You can't easily predict which one
will be called, so don't do it unless you want your scripts to call
> But the call invokes another version of Python because
> it is that version which is in the PATH. Or in SomeScript.py there is an
> internal call to 'someOtherScript.py someParameters'. But the call
> invokes another version of Python because the .py extension is
> associated with a different version.
Exactly. The root of your problem is that there are multiple executables
called "python" and you don't know which one you will get. So don't do
> My solution is that I will write some code which sets a particular
> version of Python as the current version for a particular time, meaning
> that version will be in the PATH and associated with Python extensions.
> The way I do not have to worry when I externally invoke Python from the
> command line that internal calls are going to some other version.
Good luck with that.
From: Gelonida on 26 Jul 2010 03:26
On 07/25/2010 10:39 PM, MRAB wrote:
> News123 wrote:
>> Thus my idea of having a pystarter with a config file
>> mentioning which directories (tools) should use which python executable
> I think that's the wrong way round. A pystarter should ask the _tool_
> which version of Python it needs.
Hm, it's dfifficult to think about a solution satisfying everyone.
Edward seems to insist on a non intrusive solution, where no script is
changed (thus my idea of a config file)
I personally would probably add information to all of my self written
and create a config file for all other tools (or add a marker file n the
path of these tools)