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.

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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

davepeck
Copy link
Contributor

@davepeck davepeck commented Apr 11, 2025

  • 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

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants