PEP 841: Adding Frozen Syntax to Make Immutable Types Optimizable

[corona10]

Basic requirements (all PEP Types)

• Read and followed PEP 1 & PEP 12
• File created from the latest PEP template
• PEP has next available number, & set in filename (pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) and PEP header
  • Tip: find the next available number with pepotron — run uvx pepotron next (or pipx install pepotron then pep next)
• Title clearly, accurately and concisely describes the content in 79 characters or less
• Core dev/PEP editor listed as Author or Sponsor, and formally confirmed their approval
• Author, Status (Draft), Type and Created headers filled out correctly
• PEP-Delegate, Topic, Requires and Replaces headers completed if appropriate
• Required sections included
  • Abstract (first section)
  • Copyright (last section; exact wording from template required)
• Code is well-formatted (PEP 7/PEP 8) and is in code blocks, with the right lexer names if non-Python
• PEP builds with no warnings, pre-commit checks pass and content displays as intended in the rendered HTML
• Authors/sponsor added to .github/CODEOWNERS for the PEP

Standards Track requirements

• PEP topic discussed in a suitable venue with general agreement that a PEP is appropriate
• Suggested sections included (unless not applicable)
  • Motivation
  • Specification
  • Rationale
  • Backwards Compatibility
  • Security Implications
  • How to Teach This
  • Reference Implementation
  • Rejected Ideas
  • Open Issues
  • Acknowledgements
  • Footnotes
  • Change History
• Python-Version set to valid (pre-beta) future Python version, if relevant
• Any project stated in the PEP as supporting/endorsing/benefiting from the PEP formally confirmed such
• Right before or after initial merging, PEP discussion thread created and linked to in Discussions-To and Post-History

[read-the-docs-community]

Documentation build overview

📚 pep-previews | 🛠️ Build #33679545 | 📁 Comparing 3506d9b against latest (d2259e1)

  🔍 Preview build  

10 files changed · + 1 added · ± 7 modified · - 2 deleted

+ Added

• pep-0841/index.html

± Modified

• index.html
• numerical/index.html
• pep-0000/index.html
• pep-0790/index.html
• pep-0828/index.html
• pep-0840/index.html
• topic/packaging/index.html

- Deleted

• pep-0837/index.html
• pep-0838/index.html

[eli-schwartz]

I must confess I'm slightly surprised to see direct mention here about the risk of monopolizing symbols such as $ in case they might be of value in the future -- and yet no mention of using { itself in a context which was previously available and could have been used to good effect.

In particular since this PEP is all about adding constant folding opportunities for exactly two built-in functions -- just to make the functions tempting enough to make people more liable to use them -- the fact that the proposal locks down some syntax forever to mean this one thing, is something I really would expect to see justified.

[corona10]

@sobolevn We may need to revise this section. Thank you @eli-schwartz

[eli-schwartz]

And for context, an example of something the PEP could argue against -- the PEP I'd probably write, if I had the time / sponsorship -- would be to solve the problem of "builtins cannot be unambiguously referenced after being overwritten / reused as a kwarg, and even import builtins; builtins.int can't definitely get you one. Nor can type(1) or builtins.type(1), to say nothing of builtins that aren't for classes with dedicated syntax". And not that any of these are actually good ways to achieve said goal!

The obvious thing that springs to mind for using f{}, aside for "f-sets", is func{arg1} as a guaranteed builtin with no name lookups, which means we can reimplement this PEP as frozenset{ {'data'} }. The optimization opportunities are identical, but more extensive as now all other builtin functions are in scope.

(This is basically why I dislike the PEP itself -- it feels like "thinking small" / not very imaginative about pushing the boundaries of python.)

[sobolevn]

@eli-schwartz this is not really a place for technical discusions, let's please move to https://discuss.python.org/t/pep-841-adding-frozen-syntax-to-make-immutable-types-optimizable/108219/32 for better visibility :)