Re: maintain 2 versions of python on my computer
In article xns9d02b5e2cd9b1duncanbo...@127.0.0.1, Duncan Booth duncan.bo...@suttoncourtenay.org.uk wrote: That seems overkill. This does pretty much the same thing: @(C:\Python26\Python -x %~f0 %* || pause) goto:EOF import sys print sys.version # raise RuntimeError # uncomment to trigger the 'pause' blink What version of Windows is necessary to use this? Anything with cmd.exe? (Sure doesn't look anything like DOS batch files...) -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ import antigravity -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
* Aahz: In article xns9d02b5e2cd9b1duncanbo...@127.0.0.1, Duncan Booth duncan.bo...@suttoncourtenay.org.uk wrote: That seems overkill. This does pretty much the same thing: @(C:\Python26\Python -x %~f0 %* || pause) goto:EOF import sys print sys.version # raise RuntimeError # uncomment to trigger the 'pause' blink What version of Windows is necessary to use this? Anything with cmd.exe? (Sure doesn't look anything like DOS batch files...) Well, all of that has been there since, I don't know, long ago... -x A Python option that skips the first line of the script. @ suppresses echo of the line. () group commands (creates a compound command) || shortcut-evaluated OR shortcut-evaluated AND % see below... C:\test for /? | find %~ %~I - expands %I removing any surrounding quotes () %~fI- expands %I to a fully qualified path name %~dI- expands %I to a drive letter only %~pI- expands %I to a path only %~nI- expands %I to a file name only %~xI- expands %I to a file extension only %~sI- expanded path contains short names only %~aI- expands %I to file attributes of file %~tI- expands %I to date/time of file %~zI- expands %I to size of file %~$PATH:I - searches the directories listed in the PATH %~dpI - expands %I to a drive letter and path only %~nxI - expands %I to a file name and extension only %~fsI - expands %I to a full path name with short names only %~dp$PATH:I - searches the directories listed in the PATH %~ftzaI - expands %I to a DIR like output line values. The %~ syntax is terminated by a valid FOR variable name. C:\test _ Cheers hth. (even if a bit off-topic!), - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
a...@pythoncraft.com (Aahz) wrote: In article xns9d02b5e2cd9b1duncanbo...@127.0.0.1, Duncan Booth duncan.bo...@suttoncourtenay.org.uk wrote: That seems overkill. This does pretty much the same thing: @(C:\Python26\Python -x %~f0 %* || pause) goto:EOF import sys print sys.version # raise RuntimeError # uncomment to trigger the 'pause' blink What version of Windows is necessary to use this? Anything with cmd.exe? (Sure doesn't look anything like DOS batch files...) Windows NT, Windows 2000, Windows XP, Windows Vista, Windows 7, Server 2003, Server 2008 will all handle the and || stuff. I didn't think that NT recognised the goto:EOF as special but a quick search with Google seems to indicate that it did. If so this script probably worked since 1993.[*] Windows 7 still supports this cmd.exe syntax, but it also has Microsoft Powershell which seems to be Microsoft's latest answer to shell scripts and allows direct access to COM objects and .Net classes. [*] or at least would have worked if Guido used his time machine to take a copy of Python 2.6 back to 1993. :^) -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
Duncan Booth wrote: @(C:\Python26\Python -x %~f0 %* || pause) goto:EOF import sys print sys.version # raise RuntimeError # uncomment to trigger the 'pause' That is nice! This should probably be in the documentation, here: http://docs.python.org/using/cmdline.html#cmdoption-x ... instead of This is intended for a DOS specific hack only.. Gertjan. -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
En Sat, 16 Jan 2010 05:16:14 -0300, Gertjan Klein gkl...@xs4all.nl escribió: Gabriel Genellina wrote: En Thu, 14 Jan 2010 08:21:28 -0300, luis soli...@gmail.com escribió: Is there any way to indicate the version of the python interpreter must use a script? See http://www.effbot.org/zone/exemaker.htm It uses the #! line to determine which version to load, resembling the Unix way. (I've written a variant of the same idea but isn't ready yet) I'd be interested to see what you've come up with, if you care to share. I've been thinking about something like this as well. Exemaker, for me, is the wrong solution, because it requires making an .exe file for every script you want to run this way. The advantage is that Task Manager shows the right program name, instead of always python.exe. (You don't have to *make* an .exe for every script, just rename/copy it.) If you don't care, the recipe posted by Duncan Booth is as close as a #! line as its gets. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
On 1/14/2010 3:23 PM, Lie Ryan wrote: On 01/14/10 22:21, luis wrote: Hi I am not an expert in programming and using Python for its simplicity I have 2 versions of python installed on my computer (windos xp) to begin the transition from version 2.4 to 2.6 or 3. maintaining the operability of my old scripts Is there any way to indicate the version of the python interpreter must use a script? thanks On my Windows machine, I make a copy python.exe and rename it as python25.exe, python26.exe, python3.exe, etc in their respective directories. Then after setting up the PATH environment variable, you can simply call python25, python3, etc from any directory in the command prompt. Lie, ActivePython does both of this during the installation -- pythonXY.exe and set PATH accordingly. Luis, Distribute (a setuptools fork) has a feature called entry points that will create exe wrappers for the specified Python script. These exe wrappers use the #! line to determine the actual Python interpreter to invoke. http://packages.python.org/distribute/setuptools.html#automatic-script-creation If your script is foo-script.py, foo.exe will ultimately read the first line in foo-script.py which is #!C:\Python26\python.exe .. and that is used to run the script. Task manager will show foo.exe instead of python.exe. -srid -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
Gabriel Genellina wrote: En Thu, 14 Jan 2010 08:21:28 -0300, luis soli...@gmail.com escribió: Is there any way to indicate the version of the python interpreter must use a script? See http://www.effbot.org/zone/exemaker.htm It uses the #! line to determine which version to load, resembling the Unix way. (I've written a variant of the same idea but isn't ready yet) I'd be interested to see what you've come up with, if you care to share. I've been thinking about something like this as well. Exemaker, for me, is the wrong solution, because it requires making an .exe file for every script you want to run this way. What I've been thinking about is to write a single executable that gets associated with .py and .pyw (instead of python.exe itself). This executable would parse the #! line to look for a specific python version, or use a configured default if none found (or a parsing error occurs). It would then invoke the appropriate python version (with whatever arguments, if any, are supplied). As far as I can see, this allows both typing the script name and arguments (i.e., without python31 before it) from a command prompt, and doubleclicking on a .py or .pyw file from windows explorer. In both cases, the proper python executable would be used to run the script. What's been holding me back so far is that probably needs to be written in C, to prevent the Python runtime's startup overhead. I haven't written any significant amount of C code in years, if not decades, so that seems like a daunting task to me at the moment. ;-) Gertjan. -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
* Gertjan Klein:
What I've been thinking about is to write a single [Windows] executable that
gets associated with .py and .pyw (instead of python.exe itself).
Well, you need two: one for console subsystem, and one for GUI subsystem.
Happily you can use the same source code. :-)
This
executable would parse the #! line to look for a specific python
version, or use a configured default if none found (or a parsing error
occurs). It would then invoke the appropriate python version (with
whatever arguments, if any, are supplied).
As far as I can see, this allows both typing the script name and
arguments (i.e., without python31 before it) from a command prompt, and
doubleclicking on a .py or .pyw file from windows explorer. In both
cases, the proper python executable would be used to run the script.
What's been holding me back so far is that probably needs to be written
in C, to prevent the Python runtime's startup overhead. I haven't
written any significant amount of C code in years, if not decades, so
that seems like a daunting task to me at the moment. ;-)
If it's OK with C++, I just sat down and wrote this.
It's not especially well tested (or almost not at all), and it's limited.
It handles or is meant to handle Unicode script file paths, but the path to the
Python interpreter, specified in a #! comment in the script's first line, must
be single byte per character. And if that path contains spaces must be quoted.
code file=run_script.cpp
// Note: in order to handle Unicode paths needs to use Windows API command line.
//
// If this code works then it was written (but not tested) by Alf P. Steinbach.
// Otherwise it's someone impersonating me.
#includestring// std::wstring
#includevector// std::vector
#includestdexcept
#includestdio.h
#includestddef.h
#undef STRICT
#undef NOMINMAX
#undef UNICODE
#define STRICT
#define NOMINMAX
#define UNICODE
#includewindows.h // CommandLineToArgvW, GetCommandLine
using namespace std;
//-- Various things ordinarily from libraries...
bool throwX( char const s[] ) { throw std::runtime_error( s ); }
typedef ptrdiff_t Size;
template typename Container
Size n_elements( Container const c ) { return c.size(); }
// The C++98 standard library doesn't offer Unicode filename functionality.
// Using library extension that works with GNU g++ and Microsoft Visual C++.
class TextFileReader
{
private:
FILE* f;
TextFileReader( TextFileReader const );// No copy constructor.
TextFileReader operator=( TextFileReader const ); // No assignment.
public:
TextFileReader( wstring const path )
: f( _wfopen( path.c_str(), Lr ) )
{
(f != 0) || throwX( Unable to open file for reading );
}
~TextFileReader() { fclose( f ); }
wstring line()
{
wstring s;
for( ;; )
{
int const c = fgetc( f );
if( c == EOF || c == L'\n' ) { break; }
s.push_back( wchar_t( c ) );
}
return s;
}
};
wstring substring( wstring const s, Size const i, Size const n = -1 )
{
wstring::size_type constcount = (n == -1? wstring::npos : n);
return (i = n_elements( s )? L : s.substr( i, count ));
}
//-- Main
typedef wstring String;
typedef vectorString StringVector;
StringVector cmdArguments()
{
struct Args
{
wchar_t** p;
int n;
Args()
{
p = CommandLineToArgvW( GetCommandLine(), n );
(p != 0) || throwX( Unable to obtain command line arguments );
}
~Args() { GlobalFree( p ); }
};
Args const args;
return StringVector( args.p, args.p + args.n );
}
int run( wstring const prog_path, wstring const args )
{
wstring cmd_line= prog_path + L + args;
cmd_line.c_str();
PROCESS_INFORMATION process_info= {};
STARTUPINFO startup_info= { sizeof( startup_info ) };
bool const ok = !!CreateProcess(
0, // application name
cmd_line[0], // command line
0, // process security attributes
0, // thread security attributes
TRUE, // inherit handles
0, // creation flags
0, // environment, 0 = inherit parent process env.
0, // current directory
startup_info,
process_info
);
(ok)
|| throwX( Unable to run the interpreter );
bool const wait_ok =
(WaitForSingleObject( process_info.hProcess, INFINITE ) != WAIT_FAILED);
DWORD exit_code = EXIT_FAILURE;
GetExitCodeProcess( process_info.hProcess, exit_code );
CloseHandle( process_info.hProcess );
CloseHandle( process_info.hThread );
(wait_ok) || throwX( Waiting for the program to end failed );
return exit_code;
}
int cppMain()
{
Re: maintain 2 versions of python on my computer
Alf P. Steinbach wrote: * Gertjan Klein: What I've been thinking about is to write a single [Windows] executable that gets associated with .py and .pyw (instead of python.exe itself). Well, you need two: one for console subsystem, and one for GUI subsystem. Why? I'd have imagined writing something for the GUI subsystem (without actually creating a GUI, just to prevent a DOS box popping up), creating the proper commandline, with either python.exe or pythonw.exe, and launching that as a separate process. (I have no idea whether this would actually work though -- I'm just thinking out loud at this stage.) Thinking about it some more, perhaps that way I can't get at return codes a python script might provide. I haven't used those, but they may be useful at some point. If it's OK with C++, I just sat down and wrote this. Thanks for that. I won't be using it though; I don't know C++ at all, and the source looks like complete gobbledygook to me. I wouldn't know where to begin to change anything in it. ;-) Gertjan. -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
* Gertjan Klein: Alf P. Steinbach wrote: * Gertjan Klein: What I've been thinking about is to write a single [Windows] executable that gets associated with .py and .pyw (instead of python.exe itself). Well, you need two: one for console subsystem, and one for GUI subsystem. Why? I'd have imagined writing something for the GUI subsystem (without actually creating a GUI, just to prevent a DOS box popping up), creating the proper commandline, with either python.exe or pythonw.exe, and launching that as a separate process. (I have no idea whether this would actually work though -- I'm just thinking out loud at this stage.) Thinking about it some more, perhaps that way I can't get at return codes a python script might provide. I haven't used those, but they may be useful at some point. Return codes work OK no matter what. But it's a hassle for the user to connect up standard input, standard output and standard error for a GUI subsystem process. That's mainly why the distinction between [.py] and [.pyw] is there in Windows: the former is associated with console subsystem interpreter ensuring that the standard streams are connected up automatically, the latter is associated with GUI subsystem interpreter ensuring no automatic console window. If it's OK with C++, I just sat down and wrote this. Thanks for that. I won't be using it though; I don't know C++ at all, and the source looks like complete gobbledygook to me. I wouldn't know where to begin to change anything in it. ;-) Ah, well. Perhaps do this in JScript or VBScript (languages bundled with Windows)? There may be less startup overhead than with Python. But I haven't checked. Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
Alf P. Steinbach wrote: * Gertjan Klein: Alf P. Steinbach wrote: Thinking about it some more, perhaps that way I can't get at return codes a python script might provide. I haven't used those, but they may be useful at some point. Return codes work OK no matter what. Ok, I won't have to worry about that then. ;-) But it's a hassle for the user to connect up standard input, standard output and standard error for a GUI subsystem process. Good point. Two executables it is. But out of curiousity, what happens when a user pipes something into a GUI subsystem executable? Perhaps do this in JScript or VBScript (languages bundled with Windows)? There may be less startup overhead than with Python. But I haven't checked. Won't these create a DOS window, always? Or can they run windowless as well? If so, that might be an option worth exploring as well. Gertjan. -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
On unix you would start the file with a hashbang e.g. #!/usr/bin/python3 Fraid I don't know if that works on XP though. Roger. It does not; Windows associates applications with file extensions. However, I have used something like this to get something like the Unix shebang behavior: @echo off rem = ver26.bat: Python 2.6 C:\Python26\python -x %~f0 %* goto END rem # ver26.py wrapped in ver26.bat to mimic Unix #! behavior import sys print sys.version rem = :END pause rem @echo off rem = ver31.bat: Python 3.1 D:\Python31\python -x %~f0 %* goto END rem # ver31.py wrapped in ver31.bat to mimic Unix #! behavior import sys print(sys.version) rem = :END pause rem I cannot remember where I first saw this, and don't think I have ever seen it since. It seems like a bit of a hack, but I use it from time to time when I cannot rely on Windows file associations. Perl has a much cleaner way to accomplish the same thing for Windows (see the pl2bat.bat script that ships with Perl Windows distributions). Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
Mike m...@mhuffman.com wrote: t does not; Windows associates applications with file extensions. However, I have used something like this to get something like the Unix shebang behavior: @echo off rem = ver26.bat: Python 2.6 C:\Python26\python -x %~f0 %* goto END rem # ver26.py wrapped in ver26.bat to mimic Unix #! behavior import sys print sys.version rem = :END pause rem That seems overkill. This does pretty much the same thing: @(C:\Python26\Python -x %~f0 %* || pause) goto:EOF import sys print sys.version # raise RuntimeError # uncomment to trigger the 'pause' EOF is a special label which may be used to exist a CMD file without having to explicitly define it. As I wrote it above the pause is executed only if the script exists with a non-zero status. -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
That seems overkill. This does pretty much the same thing: @(C:\Python26\Python -x %~f0 %* || pause) goto:EOF import sys print sys.version # raise RuntimeError # uncomment to trigger the 'pause' Indeed! Must be as close to a Windows shebang line as you can get. In actual use, if/when I want a pause, I typically make a call raw_input() or msvcrt.getch() EOF is a special label which may be used to exist a CMD file without having to explicitly define it. Did not know that; something new for my toolbox! Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
Mike m...@mhuffman.com wrote: That seems overkill. This does pretty much the same thing: @(C:\Python26\Python -x %~f0 %* || pause) goto:EOF import sys print sys.version # raise RuntimeError # uncomment to trigger the 'pause' Indeed! Must be as close to a Windows shebang line as you can get. In actual use, if/when I want a pause, I typically make a call raw_input() or msvcrt.getch() Right, but that doesn't help if you have an uncaught exception. Personally I run scripts from a command window so I don't care whether they pause or not, but since your example had a pause I thought I'd throw one in too. EOF is a special label which may be used to exist a CMD file without having to explicitly define it. Did not know that; something new for my toolbox! s/exist/exit/ There's a surprising amount you can do in a windows cmd or bat file, it's just that the syntax is so archane. -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
* Gertjan Klein: Alf P. Steinbach wrote: * Gertjan Klein: Alf P. Steinbach wrote: Thinking about it some more, perhaps that way I can't get at return codes a python script might provide. I haven't used those, but they may be useful at some point. Return codes work OK no matter what. Ok, I won't have to worry about that then. ;-) But it's a hassle for the user to connect up standard input, standard output and standard error for a GUI subsystem process. Good point. Two executables it is. But out of curiousity, what happens when a user pipes something into a GUI subsystem executable? The same as with a console program, I guess. Indeed piping is one way to connect up the output. Disclaimer: I can't recall ever actually trying to pipe input to a GUI subsystem exe. However, piping output, while not common, at least I've done that! :-) Perhaps do this in JScript or VBScript (languages bundled with Windows)? There may be less startup overhead than with Python. But I haven't checked. Won't these create a DOS window, always? No. They're run via the Windows Script Host interface. WSH has two runner programs: cscript (console) and wscript (GUI). So you get a console window (it's tehnically not DOS although the icon was MS-DOS until and including Windows NT 4.0) if you run a [.js] or [.vbs] file via cscript, and not via wscript. wscript is the default. But you can change that association, or create new associations, via the Windows 'assoc' and 'ftype' commands (note that after some XP update 'ftype' is no longer able to delete associations, it must then be done directly in registry). Or can they run windowless as well? Yes, see above. If so, that might be an option worth exploring as well. Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
* luis: Hi I am not an expert in programming and using Python for its simplicity I have 2 versions of python installed on my computer (windos xp) to begin the transition from version 2.4 to 2.6 or 3. maintaining the operability of my old scripts Is there any way to indicate the version of the python interpreter must use a script? I think the most direct way is to use different filename extensions, and associate them with corresponding interpreters via the 'assoc' and 'ftype' Windows commands. An alternative is to associate '.py' and '.pyw' with two dummy programs (console and GUI subsystem programs) that in some way determines the Python version of the script and invokes the right interpreter. Offhand I can think of three ways to let such a dummy program know the Python version of a script (filename extensions are not a way because with distinct filename extensions you don't need the dummy program): * version information in comment in the file. * version information in the filename, like e.g. 'myscript.python31.py', or version information in the general path, e.g. 'python31\myscript.py'. * version information in some kind of 'database', which might be a separate file or simply hardcoded in your dummy startup program. But I think personally I'd go for filename extensions and using 'assoc' and 'ftype', because while ugly it's simplest, like '.py24', '.py26', 'py31'. Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
En Thu, 14 Jan 2010 08:21:28 -0300, luis soli...@gmail.com escribió: I am not an expert in programming and using Python for its simplicity I have 2 versions of python installed on my computer (windos xp) to begin the transition from version 2.4 to 2.6 or 3. maintaining the operability of my old scripts Is there any way to indicate the version of the python interpreter must use a script? See http://www.effbot.org/zone/exemaker.htm It uses the #! line to determine which version to load, resembling the Unix way. (I've written a variant of the same idea but isn't ready yet) Or, you can always invoke your scripts with an explicit interpreter. Create a python24.cmd file containing just this line: @c:\path\to\python.exe %* (and a similar one for 2.6 and 3.0) and put them somewhere in your path (it is convenient to add a single directory to the system PATH for your own utilities; I use c:\util; others use c:\bin). Then you can say: python26 foo.py to execute foo.py using Python 2.6 -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
luis wrote: Hi I am not an expert in programming and using Python for its simplicity I have 2 versions of python installed on my computer (windos xp) to begin the transition from version 2.4 to 2.6 or 3. maintaining the operability of my old scripts Is there any way to indicate the version of the python interpreter must use a script? thanks On unix you would start the file with a hashbang e.g. #!/usr/bin/python3 Fraid I don't know if that works on XP though. Roger. -- http://mail.python.org/mailman/listinfo/python-list
Re: maintain 2 versions of python on my computer
On 01/14/10 22:21, luis wrote: Hi I am not an expert in programming and using Python for its simplicity I have 2 versions of python installed on my computer (windos xp) to begin the transition from version 2.4 to 2.6 or 3. maintaining the operability of my old scripts Is there any way to indicate the version of the python interpreter must use a script? thanks On my Windows machine, I make a copy python.exe and rename it as python25.exe, python26.exe, python3.exe, etc in their respective directories. Then after setting up the PATH environment variable, you can simply call python25, python3, etc from any directory in the command prompt. Tips: On Vista and above, you can Shift-Right-Click to show Open Command Window Here in the context menu. On XP, you can install the PowerToys http://www.microsoft.com/windowsxp/Downloads/powertoys/Xppowertoys.mspx -- http://mail.python.org/mailman/listinfo/python-list
