PEP 767: Annotating Read-Only Attributes

[Enegg]

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

---

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

[cpython-cla-bot]

All commit authors signed the Contributor License Agreement.

[JelleZijlstra]

Thanks, this will be a great improvement to the type system!

[rchen152]

This looks like it'll be a great addition!

[carljm]

Thanks for your work on the PEP! Some things to sort out, but overall it looks strong to me.

[carljm]

This is looking ready for merge and discussion to me; I'm sure PEP editors will be able find some things that should be fixed before merge, though :) Thanks for all the work on it!

[Enegg]

This is looking ready for merge and discussion to me

Does that mean I do not need to bother with the How to teach this section (for the time being)?
Should I remove it, or is it fine if the template stays?

[carljm]

Does that mean I do not need to bother with the How to teach this section (for the time being)?
Should I remove it, or is it fine if the template stays?

I missed this, sorry. This section should be filled out. It doesn't need to be extensive for this PEP, I don't think. It should mention the existing use of ReadOnly in TypedDict, and the close parallel to this usage.

We should also go through the remaining checkbox items in the summary and make sure they are all addressed.

[Enegg]

I've noticed that covariant overrides of read-only attributes open a door for a type of bugs.
A subclass overriding a read-only attribute with a narrower type may incorrectly initialize it:

class Base:
    foo: ReadOnly[int]

    def __init__(self, foo: int) -> None:
        self.foo = foo + 1  # True + 1 == 2

class Subtype(Base):
    foo: bool  # narrower type; lack of ReadOnly doesn't matter

    def __init__(self, foo: bool) -> None:
        super().__init__(foo)  # is a call to super always safe?
        assert isinstance(self.foo, bool)

I wonder if what I've observed here is just an unsoundness on the bool.__add__ side (or the +1?), or it could happen elsewhere?

[beauxq]

I've noticed that covariant overrides of read-only attributes open a door for a type of bugs. A subclass overriding a read-only attribute with a narrower type may incorrectly initialize it:

...

I wonder if what I've observed here is just an unsoundness on the bool.__add__ side (or the +1?), or it could happen elsewhere?

This looks to me like it's the same as this.

class B:
    pass

class C(B):
    pass


class Base:
    foo: ReadOnly[B]

    def __init__(self) -> None:
        self.foo = B()

class Subtype(Base):
    foo: C  # narrower type

    def __init__(self) -> None:
        super().__init__()
        assert isinstance(self.foo, C)

What I see here is basically just saying we're overriding it without actually overriding it.
If you're going to override it, you need to actually override it, not just say you're going to override it and then don't.

[hugovk]

(Conflict resolved)

[JelleZijlstra]

Thanks, almost there!

[JukkaL]

Are the semantics of omitting the type explained? Example:

    class Patient:
        number: ReadOnly = 0  # Is this ok? What's the type of number?

If type inference is supported, it would be useful to have some guidelines about how type checkers should approach this, even if some details are omitted (similar to other PEPs that don't specify type inference in detail).

[beauxq]

There was some discussion on this here: #4127 (comment)

[JelleZijlstra]

I'm going to merge this so we can put the initial version of the PEP up for discussion. Changes can still be made to the PEP before it's submitted to the Typing Council.