* Rephrase "Optimize small integers" section for import.
* Elaborate on PyLong_GetNativeLayout() validity.
* Mention PyLong_FreeExport() in the specification.
* Update benchmarks.
Also fixes an incorrect comment about the impact
a CPython operand precedence bug will have on the
way template literals interact with regular strings.
Signed-off-by: William Woodruff <william@yossarian.net>
Co-authored-by: Alyssa Coghlan <ncoghlan@gmail.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
As discussed in: https://discuss.python.org/t/62402
It doesn't make much sense for C and Python to be different here,
and the reasons for "Knuth's style" in PEP 8 apply to C code as well.
With the addition of `project.dependencies` includes from Dependency
Groups, additions are warranted in the "How to Teach This" section of
the PEP.
Firstly, it is now useful to mention the similarity between a
dependency group and an old-style `setup.py` which reads either as
setup(install_requires=_read_helper("requirements.txt"), ...)
or else as
requirements = ["foo", ...]
...
setup(install_requires=requirements, ...)
Secondly, discussion of the interfaces for Dependency Groups adds a
dimension to the document. For tool authors, this clarifies that
allowing `project.dependencies` to use includes is necessary for
build backends to declare support, but that there are no other formal
requirements for tools. They will have to decide on interfaces -- and
therefore what it means to support Dependency Groups -- for
themselves. The spec provides only for the data. Additionally, the
consequences for users, and the fact that this allows tools to define
and enforce additional rules (which they must document) are called out
explicitly.
Implicitly, this hints that it is possible for tools to have
conflicting requirements, so that it may become possible for toolA and
toolB to have incompatible or at least orthogonal needs. Due to the
relatively low risk of outright conflicts, and the ability of
responsible tool maintainers to work through such cases if they do
arise, this is not addressed at length.
PEP 735 is expanded here to allow `project.dependencies` and
`project.optional-dependencies` to use Dependency Group Includes. This
allows for includes which help satisfy the use-cases described by the
`--only-deps` pip use-cases.
The changes for this are various:
- support for these includes is added to the rationale section
- a new use case is added, aligned with the `--only-deps` use case
- the spec section is updated to list changes to the `project` table
- backwards compatibility is extended significantly to address
repackaging concerns as well as dependency analyzers[^1]
- "how to teach this" is also extended to note compatibility and
repackaging issues
- rejected ideas has added an item on `[build-system.requires]`
[^1]: It may be overstatement to say these concerns are addressed.
They are considered and not dismissed, but it is not clear that any
choices can be made in the spec to address these issues other than to
inform users.
Additionally, one unrelated change is included: the spec now notes
explicitly that extra names and dependency group names can overlap
(this was already possible, implicitly) and instructs tools to decide
on their own how to handle that if they present dependency groups and
extras via a uniform interface.
Co-authored-by: Brett Cannon <brett@python.org>
* switch to lazy conversion specifier processing (includes adding `operator.convert_field`)
* added proposal for `!()` as a new conversion specifier that invokes `__call__` (rather than `__repr__` or `__str__`)
* add `render_text` callback to `TemplateLiteral.render` signature (default value: `str`)
* new protocol: `typing.InterpolationTemplate` (protocol corresponding to the concrete `types.TemplateLiteral` type)
* new protocol: `typing.TemplateText` (equivalent to `Decoded` from PEP 750)
* new protocol: `typing.TemplateField` (inspired by `Interpolation` from PEP 750, with adjustments for eager field evaluation)
* new concrete type: `types.TemplateLiteralText` (equivalent to `DecodedConcrete` from PEP 750)
* new concrete type: `types.TemplateLiteralField` (inspired by `InterpolationConcrete` from PEP 750, with adjustments for eager field evaluation)
* added iteration support to `TemplateLiteral`, producing `TemplateLiteralText` and `TemplateLiteralField` instances in their order of appearance (keeping the "no empty TemplateLiteralText entries" rule from PEP 750)
* change the way `TemplateLiteral` works based on the way PEP 750 works
* added or updated discussion notes about several included and deferred features
Closes#3904
Hugo van Kemenade
Jelle Zijlstra
Victor Stinner
Malcolm Smith
William Woodruff
Sergey B Kirpichev
Robert Simpson
Brett Cannon
Ofek Lev
Eric Traut
Alyssa Coghlan
Andy Castille
Brian Schubert
Filipe Laíns 🇵🇸
Petr Viktorin
Łukasz Langa
Stephen Rosen