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 loewis
Recipients Arfrever, ezio.melotti, gregory.p.smith, lemburg, loewis, pitrou, vstinner
Date 2010-05-03.20:18:25
SpamBayes Score 3.582007e-10
Marked as misclassified No
Message-id <>
In-reply-to <>
STINNER Victor wrote:
> STINNER Victor <> 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?
Date User Action Args
2010-05-03 20:18:27loewissetrecipients: + loewis, lemburg, gregory.p.smith, pitrou, vstinner, ezio.melotti, Arfrever
2010-05-03 20:18:25loewislinkissue8514 messages
2010-05-03 20:18:25loewiscreate