Thanks to visit codestin.com
Credit goes to github.com

Skip to content

PEP 750: collect spec fixes discovered during final implementation work #4364

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open

PEP 750: collect spec fixes discovered during final implementation work #4364

wants to merge 7 commits into from
+16 −5

Conversation

davepeck
Copy link
Contributor

@davepeck davepeck commented Apr 11, 2025 •
edited by AA-Turner
Loading

  • Change is either:
    • To a Draft PEP
    • To an Accepted or Final PEP,
      • with Steering Council approval
    • To fix an editorial issue (markup, typo, link, header, etc)
  • PR title prefixed with PEP number (e.g. PEP 123: Summary of changes)

Hate to do this < 24 hours after acceptance, but as we've been going through the spec with a fine-tooth comb, @lysnikolaou and I discovered a minor spec issue in PEP 750.

The intent of the debug specifier behavior is to precisely match the behavior of current day f-strings. The PEP as accepted got one detail wrong, fixed here.

(The wrong detail: if a debug specifier is used with a format spec but no conversion — t"{value=:foo}" — the Interpolation.conversion should default to None, not s as in the accepted PEP. Having s as the default would be a departure from what f-strings do: they provide no default when there's a format_spec so that __format__() is called.)

📚 Documentation preview 📚: https://pep-previews--4364.org.readthedocs.build/

@davepeck davepeck changed the title Spec fix: make the debug spec section fully match f-string behavior PEP 750: spec fix: make the debug spec section fully match f-string behavior Apr 11, 2025
@AA-Turner
Copy link
Member

It might make sense to bundle all PEP changes discovered during implementation into one PR before marking the PEP as Final?

If changes based on implementation experience and user feedback are made to Standards track PEPs while in the Provisional or (with SC approval) Accepted state, they should be noted in the PEP, such that the PEP accurately describes the implementation at the point where it is marked Final.

A

@davepeck
Copy link
Contributor Author

davepeck commented Apr 11, 2025 •
edited
Loading

It might make sense to bundle all PEP changes discovered during implementation into one PR before marking the PEP as Final?

That makes sense. I believe that this is the only spec issue that will crop up; the implementation is largely complete and spec-matching. But to be safe, collecting/waiting until we merge into cpython beta makes sense.

@lysnikolaou
Copy link
Member

Yes, agreed. Let's keep this PR open (possibly also change the title) while we're finilizing the implementation and at least until some more people have reviewed it.

@davepeck davepeck changed the title PEP 750: spec fix: make the debug spec section fully match f-string behavior PEP 750: collect spec issues fixes discovered during final implementation work Apr 11, 2025
@davepeck davepeck changed the title PEP 750: collect spec issues fixes discovered during final implementation work PEP 750: collect spec fixes discovered during final implementation work Apr 11, 2025
@davepeck davepeck mentioned this pull request Apr 11, 2025
Closed
@davepeck
Copy link
Contributor Author

We should consider how to sequence this PR (collecting miscellaneous updates) and #4395 (the template concatenation PR)

@davepeck
Copy link
Contributor Author

Hi @lysnikolaou !

As we discussed during PyCon, I've updated the PEP to:

  1. Clarify the behavior of Interpolation.expression
  2. Make Interpolation.expression default to "" (currently a value must be provided when explicitly constructing an Interpolation)

The second change is a small but meaningful spec/implementation change — should we also open a steering council issue, or is it okay as is?

/cc @AA-Turner

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@gvanrossum gvanrossum Awaiting requested review from gvanrossum gvanrossum is a code owner

@lysnikolaou lysnikolaou Awaiting requested review from lysnikolaou lysnikolaou is a code owner

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@davepeck @AA-Turner @lysnikolaou