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
* Remove read-only options:
* "module_search_paths_set": not useful, always true.
* "pythonpath_env": get os.environ['PYTHONPATH'] directly.
* "sys_path_0": only make sense during Python initialization.
* "_install_importlib", "_init_main", "_is_python_build": private
options which only make sense during Python initialization.
* Fix related sys API for base_executable and exec_prefix.
* legacy_windows_fs_encoding is Windows only.
* Fix sorting.
* Re-open PEP 501 in consideration of PEP 701
* Switch naming from "interpolation template strings" to "template literal string"
* Add Nick Humrich as co-author
---------
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
Co-authored-by: Nick Coghlan <ncoghlan@gmail.com>
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
Victor Stinner
Eric Traut
Sergey B Kirpichev
Alyssa Coghlan
Andy Castille
Brian Schubert
Filipe Laíns 🇵🇸
William Woodruff
Petr Viktorin
Ofek Lev
Łukasz Langa
Stephen Rosen
Hugo van Kemenade
Pavel Karateev
khneal
Karolina Surma
Brett Cannon
Cornelius Roemer
Barry Warsaw
David Foster
Nick Humrich