PEP 797: Arbitrary Object Immortalization

[ZeroIntensity]

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
• 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
  • Rationale
  • Specification
  • Backwards Compatibility
  • Security Implications
  • How to Teach This
  • Reference Implementation
  • Rejected Ideas
  • Open Issues
• 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

---

This is following this discussion off DPO. I decided to split this into two PEPS: one for arbitrary object immortalization, and another for shared object proxies (similar to how PEP 683 and PEP 684 were split). But, I'm unsure if this was the right call. If this would all be better in one giant PEP, please let me know.

---

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

[JelleZijlstra]

This abstract is much longer than it should be.

[ZeroIntensity]

Ok, will shorten it. Which parts do you think should be excluded/moved?

[JelleZijlstra]

Most of it, really. The abstract should generally only be a few paragraphs. It explains primarily what the PEP does, not the motivation or implementation details.

[ZeroIntensity]

I've now significantly reduced the size of the abstract. Does that look better?

[AA-Turner]

This is my first time reading it, but I would say it can still be shorter -- ideally max one or two paragraphs. Perhaps:

Immortal objects have been internal to the CPython interpreter since
their introduction in :pep:`683`.
This PEP introduces a public mechanism to immortalize arbitrary objects,
while ensuring that the object is properly deallocated.
We achieve this through a pair of new functions;
:py:func:`sys._immortalize` and :c:func:`PyUnstable_Immortalize`.
These will be public and documented functions, but are expected to have
little use outside of CPython itself.
To ensure safe deallocation, we introduce a new simulated garbage collection
pass during interpreter finalisation.

I would bin the example code entirely, I don't think it significantly helps in the abstract.

[AA-Turner]

Mainly of the first half of the PEP. The tail end of the Specification section is very prose-heavy, I've suggested moving some of the setup & exposition/context to the earlier sections.

A

[AA-Turner]

Current title reads slightly oddly to me:

Suggested change

	Title: Arbitrary Object Immortalization
	Title: Immortalizion of Arbitrary Objects

[ZeroIntensity]

Hmm, I think the current title is good. How tied are you to this suggestion?

[AA-Turner]

The current title reads as if object immortalisation is arbitrary, rather than that it is immortalisation of arbitrary objects: it is unclear if the correct grouping should be "arbitrary (object immortalisation)" or "(arbitrary object) immortalisation". The suggestion was an attempt to clarify, though I'd equally be fine with any other phrasing. It's not my PEP, though, so you'd be entirely within your rights to reject this idea and keep the current title.

A

[ZeroIntensity]

I've learned from PEP 788 that I'm not good at naming PEPs, so I'm inclined to defer to you.

[AA-Turner]

This is my first time reading it, but I would say it can still be shorter -- ideally max one or two paragraphs. Perhaps:

Immortal objects have been internal to the CPython interpreter since
their introduction in :pep:`683`.
This PEP introduces a public mechanism to immortalize arbitrary objects,
while ensuring that the object is properly deallocated.
We achieve this through a pair of new functions;
:py:func:`sys._immortalize` and :c:func:`PyUnstable_Immortalize`.
These will be public and documented functions, but are expected to have
little use outside of CPython itself.
To ensure safe deallocation, we introduce a new simulated garbage collection
pass during interpreter finalisation.

I would bin the example code entirely, I don't think it significantly helps in the abstract.

[AA-Turner]

I think this would benefit from being split into Motivation and Rationale. Recall from PEP 12:

• Motivation: Clearly explain[s] why the existing language specification is inadequate to address the problem that the PEP solves.
• Rationale: Describe[s] why particular design decisions were made.

[AA-Turner]

I would first argue why immortalising a general object matters or has benefits before describing the current technical restrictions that prevent doing so.

[AA-Turner]

This topic & idea is introduced in Specification. Can you move the bits that already exist today to an earlier section, so that the Specification only needs to detail the changes or strengthening to the contract?

[AA-Turner]

This repeats the previous section, "The hardest part about immortality is the deallocation". I'd suggest that prose & the problem statement should be moved to Motivation & Rationale.

[ZeroIntensity]

Ok, I think @AA-Turner is right that too much here is informational. I'm going to convert this to a PEP about shared object proxies (because that's my actual motivation here), and then do one of two things:

1. Make an informational PEP afterwards about the new immortalization tactics.
2. Combine the current proposal with the new one (but that will create a massive PEP).

The former is probably the best approach unless anyone has objections.

[AA-Turner]

I think this makes sense (shared proxies & then informational on immortalisation). Do you want to reuse this PR or start anew? You can keep PEP 797 as the number regardless.

A

[ZeroIntensity]

It'll probably be easiest to make a new PR, but I'll keep this one open until it's ready (so pepotron doesn't mistake 797 as available).

[ZeroIntensity]

New draft is up at #4536. I'll turn this into an informational PEP later.