PEP 750: collect spec fixes discovered during final implementation work

[davepeck]

• 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/

[AA-Turner]

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]

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]

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]

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

[davepeck]

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

[lysnikolaou]

LGTM!

[davepeck]

This one is ready to merge, I think @AA-Turner !

[AA-Turner]

Shall we capture the changes to t-string concatenation here @davepeck?

A

[davepeck]

Shall we capture the changes to t-string concatenation here @davepeck?

A

@AA-Turner Think we captured those in #4395, already merged.

[AA-Turner]

Oops! My mistake, sorry!

A

[davepeck]

Oops! My mistake, sorry!

Hah! There are so many PEP 750 related PRs at this point that I've personally entirely lost the plot. 😅