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 brett.cannon
Recipients Antony.Lee, brett.cannon, eryksun, ethan.furman, serhiy.storchaka, vstinner
Date 2020-01-28.18:35:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1580236553.49.0.5425346537.issue39461@roundup.psfhosted.org>
In-reply-to
Content
> 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 conversions themselves.

> The idea behind PEP 519 was to alleviate str(path_obj) calls between the os/program interface

... where file paths were explicitly expected. os.environ is not a place where file paths are explicitly expected, just a place where they _might_ end up. Basically I only consider PEP 519 valid in places where file paths are the only thing that are expected (e.g. all the path manipulation functions in os.path). Everywhere else where paths are only a "maybe" I would say it shouldn't be relied upon to do implicit conversions.

> Out of curiosity, any idea how often non-strings are used to set os.environ, and so need explicit conversion?

I have anecdotal evidence from outside of Python that people will do this when they can and then are surprised when the conversion doesn't work the way they expect (e.g. floats).
History
Date User Action Args
2020-01-28 18:35:53brett.cannonsetrecipients: + brett.cannon, vstinner, ethan.furman, serhiy.storchaka, Antony.Lee, eryksun
2020-01-28 18:35:53brett.cannonsetmessageid: <1580236553.49.0.5425346537.issue39461@roundup.psfhosted.org>
2020-01-28 18:35:53brett.cannonlinkissue39461 messages
2020-01-28 18:35:53brett.cannoncreate