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 thread.
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 working. 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. -- Steven
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 such code.
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 directory: python26 someScript.py # calls python31 secondScript.py internally python31 anotherScript.py # calls python25 thirdScript.py internally etc. Or give the full path to the executable: C:\Programs\python26\python.exe someScript.py # 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 > someParameters'. 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 arbitrary executables. > 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 that. > 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. /facepalm > 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. -- Steven
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 scripts and create a config file for all other tools (or add a marker file n the path of these tools) |