* Thomas Wouters is now the BDFL-delegate
* Elaborate the Rationale
* New "Path configuration" section
* New "Python Issues" section
* Add PyWideStringList_Insert() function
* Add PyConfig.configure_c_stdio option.
* Add PyConfig.parse_argv field
* Rename bytes/wide functions. Add "Bytes" to functions taking char*,
remove "Wide" from functions taking wchar_t*. Rename
PyConfig_DecodeLocale() to PyConfig_SetBytesString().
* PyConfig: Rename '_frozen' to 'pathconfig_warnings'
* Re-introduce PyConfig._init_main
* Complete tables of global configuration variables; annotate
variable values which are negated.
* Add default values of all PyPreConfig and PyConfig fields
* Elaborate the Rationale
* Add a few more issues
* Add PyPreConfig.legacy_windows_fs_encoding rules
* Add "Isolate Python" section
* PyConfig_SetString() and PyConfig_SetBytesString() now requires the
configuration as the first argument.
* Rename Py_UnixMain() to Py_BytesMain()
This PR contains mostly minor wording tweaks plus a paragraph explicitly allowing class objects as implementations of protocols, previously there were questions whether it is actually allowed, see python/mypy#4536.
The previous wording could be taken as suggesting that frontends should opt
out of their PEP 517 processing entirely if build-backend was not defined,
whereas it's actually fine to just use the setuptools provided backend that
implements the legacy build semantics.
See bpo-36798.
This update specifies the interplay between f-strings and
the assignment operator. Specifically, it attempts to
clarify how to use assignment operators inside of f-strings.
There is too little time left before the 3.8 release and I don't want Antoine to feel rushed to pronounce. The implementation is mostly complete, so we could land it for 3.8. However, the experience in 3.8 wouldn't be nearly as good, in part because we're still sharing the GIL. Plus, we need more confidence that extension modules won't be severely impacted by the wide-spread use of subinterpreters. Waiting for 3.9 will allow us to address both issues, as well improve performance (especially startup).
- consistently use "discourage" instead of "deprecate" for the zero-fill
behaviour in the existing constructors
- make the implied assumption of positional-only parameters explicit
This commit adjusts two sections of this PEP that are related to enums.
First, it removes the sections regarding the interaction between enums,
imports, and Any. I wasn't aware that the import behavior described in
that section was mypy-only and isn't codified in PEP 484. So, I decided
to just remove that section entirely -- it didn't feel there was much I
could salvage there.
Instead, I opted to adjust the "invalid parameters" section to explain
in a little more detail why `Literal[Any]` is not allowed.
Second, I split up the section about type narrowing into two.
The first new section is a reminder that PEP 484 requires type checkers
to support certain kinds of exhaustibility checks when working with enums.
To make this more clear, I adjusted the example to be more closer to what
is used in the spec and removed any mention of reachability -- it felt
like a distraction.
The second section focuses back on some neat tricks using Literals that
type checkers may optionally implement. I also tweaked some of the
examples here as suggested in https://github.com/python/peps/pull/993.
Victor Stinner
Barry Warsaw
Nick Coghlan
larryhastings
Ivan Levkivskyi
Jeroen Demeyer
Donald Stufft
Michael J. Sullivan
Hugo
Dominik Gabi
Petr Viktorin
Antoine Pitrou
Christian Heimes
Steve Dower
Mark Shannon
Łukasz Langa
Logan Jones
Guido van Rossum
Matthias Bussonnier
Brett Cannon
Eric Snow
Mariatta
Michael Lee
Brett Cannon