The provisional acceptance led to some additional valid concerns being raised
with the current design in the PEP, so I'm reverting it to Draft status
while we resolve them.
* New PEP 546: Backport MemoryBIO to Python 2.7
* PEP 546: Alex Gaynor's review
* PEP 546: Nick Coghlan's review: ensurepip
* PEP 546: new Nick Coghlan's review
Part of the PEP 538 implementation is to add a new
"Legacy C Locale" section to PEP 11 that explicitly
limits our support for running Python 3.7+ in the
ASCII based legacy C locale.
(Note: if PEP 540 is also accepted, this section will
be amended accordingly)
It looks like setting LANG may have undesirable
side effects in some cases, and all the issues
the PEP aims to handle are resolved by setting
LC_CTYPE.
The proposal and implementation have thus been
updated to only set LC_CTYPE, even when the
target coercion locale is a full locale.
* Add covariant mutable overriding and overriding variance to rejected ideas
* Update the notes on runtime implementation
* Add one more argument for prohibiting variance overrides
* PEP 545: FIX typo.
* PEP 545: Grammar tweaks from Brett Cannon.
* PEP 545: Adding the Hugarian group in known groups.
* PEP 545: FIX typos, thanks to Jakub Wilk.
* PEP 545: Clarify the false equality between language codes and country codes.
* PEP545: Update licensing after discussion with Van. L from the PSF.
* Tidy up the abstract and emphasise the equivalence between
this proposal and long supported configuration settings
* Don't set LC_ALL (set LC_CTYPE instead)
* Add a rationale for that change
* Use GNU readline misbehaviour as a specific example of the
benefits of reconfiguring the locale
* Clarify rationale for enabling the changes by default on all
autotools-using platforms
* Mention the possibility of exposing a public API for use by
embedding platforms
The previous wording suggested that all three standard streams
were affected by the proposed change to the default error handler.
Only stdin and stdout are affected - the default error handler for
stderr continues to be "backslashreplace"
* 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.