- 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).
* PEP 394: Distributions can choose what does python mean
Co-Authored-By: Petr Viktorin <encukou@gmail.com>
* fixup! PEP 394: Distributions can choose what does python mean
* fixup! PEP 394: Distributions can choose what does python mean
* fixup! PEP 394: Distributions can choose what does python mean
* PEP 394: Keep version agnostic shebang recommendation
This update reverts back to the version agnostic "python" invocation
as the default recommendation for developers, and rewords the
rest of the PEP accordingly.
In particular, it makes it clear that publishers are free to adopt
the attitude of "we assume you are using a virtual environment",
while at the same time granting the distributors the freedom they
need to make software with the expectation work correctly when
run directly against a system Python installation.
* Apply suggestions from code review
Co-Authored-By: Carol Willing <carolcode@willingconsulting.com>
* Moving letters around
* Change the abstract
* Remove a paragraph
* ValueError: some authors have more than one email address listed
* Apply suggestions from code review
Co-Authored-By: Petr Viktorin <encukou@gmail.com>
* Address review comments
* Rename section headers
* Push script publishers and users to virtual environments
* Rewording
* Remove "preferred" shebang line wording
* Change post date
* Little tweaks
* Address review comments
- Clarify wording on "older" Linux distros
- Remove discussion aroung Python 4.0
- use baseline feature release and incremental feature release
rather than major/minor feature release
- introduce a new "feature_complete" flag on sys.version_info
to allow the branch state to be inspected at runtime
- impose a runtime feature detection requirement on all features
added in incremental feature releases
Alternative to PEP 596 that aims to reduce feature delivery latency
by giving ourselves access to a new, less disruptive, feature
delivery vehicle, rather than by increasing the frequency with
which we deploy our existing disruptive feature delivery vehicle.
Batuhan Taşkaya
Damien George
Victor Stinner
Weiliang Li
Jeffrey Dorrycott
Michael Lee
Marc Abramowitz
Nick Coghlan
Sergey
Min ho Kim
Mariatta
Nathaniel J. Smith
Harmon
Paul Moore
Jeremy
Dustin Ingram
Christopher Hunt
native-api
Thomas Kluyver
Paul Ganssle
Brett Cannon
Ned Deily
Miro Hrončok
Łukasz Langa
Aliaksei Urbanski
Chris Martin
Ben Kooiman-Cox
Barry Warsaw
Peter Schmidt
July Tikhonov
Inada Naoki
Guido van Rossum
Dima Boger