homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ronaldoussoren
Recipients loewis, ronaldoussoren
Date 2009年09月22日.10:48:54
SpamBayes Score 1.5188512e-08
Marked as misclassified No
Message-id <1253616536.4.0.145439176425.issue6834@psf.upfronthosting.co.za>
In-reply-to
Content
The attached file 'pythonw.c' is a first version of a better pythonw 
executable.
This version uses posix_spawn rather than execv to start the real 
interpreter. The main advantage of the new implementation is that 'arch 
-ppc pythonw' works as expected, with the current version of pythonw the 
'arch' command only affects the pythonw executable and not the real 
interpreter.
Todo:
* I'm not use if the '-X32bit' option is a good idea or not.
 The basic idea of this is to provide an easy way to force python to 
 start in 32bit mode (for use in #! lines) for scripts that need it
 (basicly anything that needs to access Carbon GUI APIs, including most
 current Python GUI libraries)
* The implementation of '-X32bit' is sucky, it contains a copy of the
 getopt format string from Py_Main in Modules/main.c
* The path to the real executable is hardcoded for a standard framework
 install of 2.7 (easily changed to the same mechanism as used by
 the current edition of pythonw)
 What I'd like to do is link pythonw to the framework and use dyld
 introspection to deduce the path to the real executable. That's 
 slightly more complicated, but would provide a clean way to reuse
 the executable in tools like virtualenv without recompiling.
History
Date User Action Args
2009年09月22日 10:48:56ronaldoussorensetrecipients: + ronaldoussoren, loewis
2009年09月22日 10:48:56ronaldoussorensetmessageid: <1253616536.4.0.145439176425.issue6834@psf.upfronthosting.co.za>
2009年09月22日 10:48:54ronaldoussorenlinkissue6834 messages
2009年09月22日 10:48:54ronaldoussorencreate

AltStyle によって変換されたページ (->オリジナル) /