Re: [Python-Dev] Is adding support for os.PathLike an enhancement or bugfix?

On 9 May 2017 at 05:08, Chris Barker wrote: > On Fri, May 5, 2017 at 9:30 PM, Nick Coghlan wrote: >> >> By contrast, 3.6 users can just unconditionally call os.fspath(), and >> know the result will work with all stdlib APIs, without allowing >> nonsense

Re: [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale

On 8 May 2017 at 15:34, Nick Coghlan wrote: > On 7 May 2017 at 15:22, INADA Naoki wrote: >> ## Background >> >> Locale coercion in current PEP 538 has some downsides: >> >> * If user set `LANG=C LC_DATE=ja_JP.UTF-8`, locale coercion may >> overrides

Re: [Python-Dev] Is adding support for os.PathLike an enhancement or bugfix?

On Fri, May 5, 2017 at 9:30 PM, Nick Coghlan wrote: > By contrast, 3.6 users can just unconditionally call os.fspath(), and > know the result will work with all stdlib APIs, without allowing > nonsense like attempting to use "str(str)" as a filesystem path. > > Doing that

Re: [Python-Dev] Is adding support for os.PathLike an enhancement or bugfix?

On Fri, May 5, 2017 at 2:34 PM, Terry Reedy wrote: > So it would be really great if any updates to shutils (and other stdlib >> packages) to support the new protocol be back-ported. >> > > Not if they change the language. we're not talking about language changes here -- we

Re: [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale

>>> On platforms where they would have no effect (e.g. Mac OS X, iOS, Android, >>> Windows) these preprocessor variables would always be undefined. >> >> Why ``--with[out]-c-locale-coercion`` have no effect on macOS, iOS and >> Android? > > On these three, we know the system encoding is UTF-8, so