[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Change by Ethan Furman : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Terry J. Reedy added the comment: os.environ is initially a copy of the os string-string mapping. That some string values happen to represent file paths is opaque to the mapping. So, to me, looking at os.environ by itself, there is no particular reason to autoconvert Path values but not

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Ethan Furman added the comment: Well, I would prefer if Path objects were seamless to use since at one time they were actually strings, but I can live with Brett's rationale that they are only seamless where paths are explicitly expected. -- ___

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

STINNER Victor added the comment: I understand that os.fsencode() was modified to support the fspath protocol to be consistent with the C implementation PyUnicode_FSConverter() which calls PyOS_FSPath(). I agree that at least in C, we need two functions: one which accepts (str, bytes),

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Raymond Hettinger added the comment: I don't think proposal this makes sense. os.environ is a dict-like object providing clean access to the environment variables. Use of Paths is an orthogonal problem unrelated to environment variables. -- nosy: +rhettinger

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Eryk Sun added the comment: > as long as the behavior is *consistent* with the env kwarg to > subprocess.run() subprocess isn't consistent with itself across platforms. The env parameter in Windows is strictly an str->str mapping, like os.environ. This is coded in getenvironment in

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Antony Lee added the comment: FWIW, I'm actually fine with not supporting Path objects in os.environ, as long as the behavior is *consistent* with the env kwarg to subprocess.run() -- note that the original title of the thread only pointed out to the inconsistency, and did not strongly

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Brett Cannon added the comment: > but now it's too change to change it again :-) I actually don't think it is if we want to revert this. We can raise a deprecation warning if the call to os.fsencode() leads to a value different than its argument and say that people are expected to handle

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Ethan Furman added the comment: The idea behind PEP 519 was to alleviate str(path_obj) calls between the os/program interface. We can either make that as consistent as we can as we find places that still require the str(path_obj) idiom, or we can make users remember which ones do, and

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Eryk Sun added the comment: > I honestly would have disagreed with the Popen change for its 'env' > argument or any other place that is dealing with environment > variables os.spawnve (Windows) and os.execve support __fspath__ for the env dict partially due to me (bpo-28114), so sorry if

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Serhiy Storchaka added the comment: Path-like objects are now unintentionally accepted for many non-path things, like hostname in socket.sethostname() and username in os.initgroups(). I also think it was a mistake, and we should not make new mistakes. --

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

STINNER Victor added the comment: > I don't think this should be done (and I honestly would have disagreed with > the Popen change for its 'env' argument or any other place that is dealing > with environment variables). Environment variables are strings, period, so > they should be

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Brett Cannon added the comment: I don't think this should be done (and I honestly would have disagreed with the Popen change for its 'env' argument or any other place that is dealing with environment variables). Environment variables are strings, period, so they should be specified as such;

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Eryk Sun added the comment: Supporting __fspath__ for os.environ[b] makes it consistent with POSIX os.putenv, which already supports it via PyUnicode_FSConverter. For example: os.putenv(Path('spam'), Path('eggs')) getenv = ctypes.CDLL('libc.so.6').getenv getenv.restype =

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Ethan Furman added the comment: True, but this example of implicit conversion is only for Path objects which are currently implicitly converted throughout the stdlib where appropriate, and this looks like one of those appropriate places. I don't know enough about os.environb to offer an

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Serhiy Storchaka added the comment: Implicit conversion can also hide some bugs. Semantically os.environ is an str to str mapping and os.environb is a bytes to bytes mapping. -- nosy: +serhiy.storchaka ___ Python tracker

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Ethan Furman added the comment: True, but so is having Path objects not seemlessly usable. Also, isn't os.environ a special case where all values should be strings? -- ___ Python tracker

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

STINNER Victor added the comment: Currently, os.environ behaves as a dictionary. When you put value into os.environ[key], os.environ[key] gives you back this value. If we start to convert value to a different type (convert something to str), it can be surprising. --

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Ethan Furman added the comment: Adding `os.environ` support makes sense to me. -- ___ Python tracker ___ ___ Python-bugs-list

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Change by STINNER Victor : -- title: os.environ does not support Path-like values, but subprocess(..., env=...) does -> [RFE] os.environ should support Path-like values, like subprocess(..., env=...) type: -> enhancement ___ Python tracker