Message105888
| Author |
vstinner |
| Recipients |
Arfrever, gregory.p.smith, vstinner |
| Date |
2010年05月16日.23:14:53 |
| SpamBayes Score |
3.7152702e-08 |
| Marked as misclassified |
No |
| Message-id |
<1274051696.42.0.105161442793.issue8513@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
I asked on #python-dev about os.get_exec_path() result type. As expected, the answer was "It's a really bad idea".
So here is a new version of my patch. Summary of the patch version 4:
- subprocess.Popen() and os._execvpe() support bytes program name
- os.get_exec_path() now supports b'PATH' key and bytes value
- add os.supports_bytes_environ flag: "True if the native OS type of the environment is bytes (eg. False on Windows)"
Changes since the version 3:
- document the new os.supports_bytes_environ flag
- os.get_exec_path() result type is always str (decode bytes to str using sys.getfilesystemencoding() + surrogateescape)
- path.supports_unicode_filenames is False on Windows 9x but Windows 9x native type is unicode and so fsencode() should not be defined on this OS: revert the fsencode() test (if not path.supports_unicode_filenames => if name != 'nt') |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2010年05月16日 23:14:57 | vstinner | set | recipients:
+ vstinner, gregory.p.smith, Arfrever |
| 2010年05月16日 23:14:56 | vstinner | set | messageid: <1274051696.42.0.105161442793.issue8513@psf.upfronthosting.co.za> |
| 2010年05月16日 23:14:54 | vstinner | link | issue8513 messages |
| 2010年05月16日 23:14:54 | vstinner | create |
|