* Remove stray reference to `ht_moduleptr`
* Update copyright info
* Remove the new slot for offsets
* Remove note on removed internal functions
* Remove stray reference to Py_TPFLAGS_HEAP_IMMUTABLE
The PEP's previous handling of the micro version compatibility
testing question really wasn't very good, and didn't address the
question of pickle compatibility at all.
So if this idea is going to be considered seriously, it needs
to provide a way to explicitly opt out of the feature additions,
without having to downgrade back to an earlier point release.
* Rewrite section on passing the "defining class" into C methods.
* Remove proposal for immutable heap exception types. Let's leave those to another PEP
* Restrict METH_METHOD to a single calling convention.
This calling convention should be efficient, so also reduce the Optimization section.
* Set names in monospaced font
* Use `nargsf` for the vectorcall "number of args + flag" argument
* Link "per-module state" to the terminology section
* Adjust link to Marcel's current implementation
* Other minor rewordings
https://github.com/python/peps/pull/1159
- switch from the new `TargetScopeError` to a plain `SyntaxError`
as per referenced python-dev discussion
- clarify rationale for those extra SyntaxError cases (we don't
want current CPython implementation details to implicitly leak into
the "do what CPython does" de facto language specification)
- broaden one of the error cases to handle the fact that CPython's
symbol table analysis for a comprehension involves two different
scopes and hence makes it difficult to detect when the target of
a named expression in the iterable expression gets re-used as an
iteration variable in the comprehension
- note that even dead code affects the symbol analysis pass
- hire a professional project manager
- create playground issue tracker for experiment
- test repo for labels
- python triage team has been created
- devguide update
Co-Authored-By: Carol Willing <carolcode@willingconsulting.com>
Major rewrite pass over PEP 600
This has minimal substantive changes, though it does fill in some
details. Mostly it's just aligning the text with all the discussion on
Discourse.
- several Scientific Python projects are working on a
common version support policy for their projects,
which we need to take into account when considering
changes to our release cadence
- reviewing that draft NEP highlighted several problems
with the way this PEP was using the "major" and "minor"
terms, so this takes a pass through that, replacing
inappropriate uses of "major" with "feature", and
and inapproriate uses of "minor" with "micro"
- I also went through and collected statistics on how many
changes we've been making in micro releases that
warranted version added/changed notes in the docs
* PEP 599: Remove vsyscall section
The vsyscall usage in glibc removed in the 2.14 release, so this is not
relevant for manylinux2014
* Clarification about PyPI support
* PEP 598: Further discuss testing implications
Also rephrase the section about Python 3.10 vs 4.0
to make it clearer that the PEP isn't *proposing*
releasing 4.0 after 3.9, just discussing the impact
the different choice of version number would have
on the proposal.
* Also propose a tweak to the provisional API policy
Updated manylinux naming and compatibility profile definition
proposal, to be considered in combination with the
(competing/complementary?) manylinux2014 proposal in
PEP 599.
Per GH-560, the current definition of `python_version` is not compatible
with a 2+ digit major or minor version. There were no objections to
changing the definition to more accurately reflect the semantic content
intended to be conveyed (i.e. the major and minor version).