Martin v. Löwis <mar...@v.loewis.de> added the comment: STINNER Victor wrote: > STINNER Victor <victor.stin...@haypocalc.com> added the comment: > >> Why is that? In msg104063, you claim that you want to create these >> functions to deal with file names (not environment variables) > > Yes, but my os_path_fs_encode_decode-3.patch uses it in getenv() which > is maybe a bad idea: os.environb may avoid this.
IIUC, that usage is an equivalent transformation, i.e. the code doesn't change its behavior. It is mere refactorization. So *if* these functions are accepted, this change is a good idea regardless of the os.environb introduction (unless I'm missing something, and there is indeed a behavior change). >> in msg104064, you claim that #8513 (which is about the program name in >> subprocess) would benefit from these functions. Do these use cases >> become invalid if os.environb becomes available? > > #8513 is also related to environment variables: subprocess._execute_child() > calls os.get_exec_path() which search the PATH environment variable. > It would be nice to support bytes environment variable in the env > argument of Popen constructor (bytes key and/or value). I still fail to see why this would make this issue block on the os.environb introduction. Whether this gets introduced or not, the program name issue remains, no? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8514> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
