* default standard stream error handler is always "surrogateescape"
for the potential coercion target locales
* PEP 540 is now a purely optional follow-on PEP that improves the
handling of cases where none of these locales are available,
but doesn't require revisiting the changes made for this PEP
* the locale coercion and warning behaviours are now enabled by
default for all \*nix platforms, even Mac OS X
* covered the Android-specific changes to the use of `setlocale`
* state explicitly that we're aware this makes the behaviour
of standalone CPython and embedded CPython diverge, we just think
the potential benefits are sufficient to accept that downside
* note the reference implementation has yet to be updated with
these changes
* Typo: "not not" (thanks Florent Hivert)
* Added a terminology note that hopefully should clear up confusion for new-comers to the PEP, as there have also been recent PEPs/discussions surrounding TLS in the HTTPS sense
* Adds a brief summary of the motivation to the abstract, along with a link to the relevant bug
* Updated the new API specification to reflect additions/changes since the last draft
* Added a usage example to the specification
* Added an explanation of the need for Py_tss_NEEDS_INIT to the rationalization
* Other minor wording updates and typo fixes
This was discussed in https://github.com/python/typeshed/issues/270#issuecomment-296411726. Both mypy and pytype behave as described already. We should document this behavior in the PEP to make sure people are aware of it and promote uniformity.
Mypy also implicitly promotes bytearray to bytes in both Python 2 and 3. Not sure if that's worth codifying in the PEP too.
@vlasovskikh Is this also OK for PyCharm?
Note: there's an open question about whether interface variance should be inferred or be user-declared (defaulting to invariant unless declared otherwise). The current draft uses inferred invariance. See e.g. discussion at https://github.com/python/peps/pull/243#issuecomment-295826456.
* Change the specification example to be clearer.
Previously, we compared python_version < "2.7.10".
As python_version only keeps the major and minor number (2.7, 3.2),
it could lead to unexpected behaviour when comparing to 3-parts versions.
Changing the example might reduce the risk of making that small but
confusing mistake.
* Fix mistake in Backwards Compatibility about python_version.
In this section, it said:
"handle version comparisons with python_version "2.7.10" differently."
while is should have mentionned python_full_version, as python_version
will never have a 3-part version value.
- using PYTHONIOENCODING poses a compatibility problem for
Python 2 subprocesses, so use Py_SetStandardStreamEncoding
instead
- note that components checking for "no output on stderr
means success" will either need to avoid the warning or
switch to checking return codes instead
- Docker, Inc. ends with a full stop, not a comma (noted by
Jan Pokorný)
- explicitly acknowledge Charalampos Stratakis's work on the
Fedora 26 backport
- make expected filename pysdist.json and be clear this
metadata is about the published source code, not any
particular built or installed artifacts
- defer any changes to handling of project obsolescence
- add "all" and "alldev" as implied extras if not defined
- drop "self", "runtime" and proposed changes to the extras
notation
- reference implementation should align with the PEP now, aside from
excluding Mac OS X from the changes
- Fedora's initial 3.6 release is going to be 3.6.1, so reword the
backport section accordingly
- PYTHONCOERCECLOCALE=0 now also disables the library warning
- PEP just refers to locale-aware/locale-independent components,
without specifically limiting that to C/C++ components
- move Semantic Dependencies over to the Extras system
- integrate appropriate references to PEP 508
- cut no longer relevant "status report" sections
- cut explanations of changes that were moved to PEP 459
- updates reference implementation to use PYTHONCOERCECLOCALE
- removes hard dependency on PEP 540
- still notes PEP 540 covers case where no relevant C-with-UTF-8
locale is available
- clarifies that these settings are still recommended over the
legacy C locale settings for older Python 3 versions, even if
we don't recommend backporting the automatic coercion