STINNER Victor wrote:
> STINNER Victor <victor.stinner@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?