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