PEP 767: Address feedback & open issues by Enegg · Pull Request #4559 · python/peps

Enegg · 2025-08-25T15:31:53Z

Added my real name 🫠
Updated Post-History
Bikeshedded on some of the wording in this PEP
Clarified that use of bare ReadOnly is not allowed, and added that to rejected ideas
Specified that a protocol's read-only attributes are not accessible from its type (type[Protocol])
Closed open issue: "Extending Initialization"

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

Clarify that bare `ReadOnly` is not allowed, and add that to rejected ideas Specify that `type[Protocol]` does not inherit the protocol's attributes Close issue: "Extending Initialization" Bikeshed on some wording Use my real name

peps/pep-0767.rst

hugovk

Where are we up to with this PR? Can we merge it? Let's do so if there's no further feedback in ~a week.

peps/pep-0767.rst

Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

This reverts commit 11f4522.

"Terminology" section allow initializing read-only attributes by subclass allow `@classmethod` to initialize instance attributes allow `ReadOnly` + `Final`, though redundant

oscarbenjamin · 2026-03-02T22:30:24Z

peps/pep-0767.rst

+This PEP uses "attribute mutation" as a reference to assignment to,
+or ``del``\ etion of the attribute.
+This is distinct from :term:`mutability <mutable>` of the attribute's value.


This terminology seems likely to confuse. The fact that we need to say that "attribute mutation" is different from "mutating the attribute's value" makes it seem like a better term is needed.

I have always used "mutate" to mean changing the value of an object regardless of whether that object is bound to any name, attribute, etc so I already got confused reading this in the diff below:

- The inability to reassign read-only attributes makes them covariant. + The inability to mutate read-only attributes makes them covariant.

Is it particularly useful here to use the term "mutating" rather than just saying "reassigning or deleting" which the term is defined here as being an alias for?

I agree with this. The PEP doesn't actually use the term "mutate" all that often; I don't think it would be onerous to simply say "assign or delete" in those cases. And I think it is confusing to use "mutate" to mean "assign or delete".

a better term is needed

I think it is confusing to use "mutate" to mean "assign or delete".

Hmm, I don't think I've seen anyone refer to "assignment or deletion" collectively with a term other than "mutation".

And to me it makes sense to use it, as the two actions are a form of mutation, just not of the assigned value, but of the object the value is assigned to.

But alright, if it seems I only added to confusion rather than reduce it, I'll change it to say "assign or delete" in those cases.

carljm · 2026-03-03T18:13:47Z

peps/pep-0767.rst

+This PEP uses "attribute mutation" as a reference to assignment to,
+or ``del``\ etion of the attribute.
+This is distinct from :term:`mutability <mutable>` of the attribute's value.


I agree with this. The PEP doesn't actually use the term "mutate" all that often; I don't think it would be onerous to simply say "assign or delete" in those cases. And I think it is confusing to use "mutate" to mean "assign or delete".

carljm · 2026-03-03T18:14:31Z

peps/pep-0767.rst

+or ``del``\ etion of the attribute.
+This is distinct from :term:`mutability <mutable>` of the attribute's value.
+
+"Read-only" is used to describe attributes which may be read, but not assigned to


"not assigned to (except in limited cases to support initialization)" ?

carljm · 2026-03-03T18:48:32Z

peps/pep-0767.rst


 Use of ``ReadOnly`` in annotations at other sites where it currently has no meaning
 (such as local/global variables or function parameters) is considered out of scope
 for this PEP.


"...and remains forbidden." ?

carljm · 2026-03-03T18:50:08Z

peps/pep-0767.rst


    def read_games(shelf: HasGames[abc.Sequence[Game]]) -> None:
-        shelf.games.append(...)             # error: "Sequence" has no attribute "append"
+        # shelf.games.append(...)           # error: "Sequence" has no attribute "append"


Why is this line commented?

carljm · 2026-03-03T18:52:39Z

peps/pep-0767.rst

+Assignment to a read-only attribute can only occur in the class declaring the attribute
+and its nominal subclasses, at sites described below.


I think we should clarify somewhere that assignment to / deletion of a readonly attribute on a protocol type is never permitted.

And we should also clarify that a normal writable attribute can implement a protocol with a ReadOnly attribute. (This does not cause unsoundness because the attribute is not writable on the protocol type, where it is covariant.)

carljm · 2026-03-03T19:01:04Z

peps/pep-0767.rst

 * In ``@classmethod``\ s, on instances of the declaring class created via
  a call to the class' or super-class' ``__new__`` method.


This seems redundant with what's above under "must".

I think we can also combine classmethods into the previous point here.

carljm · 2026-03-03T19:03:11Z

peps/pep-0767.rst

-* At declaration in the body of the class.
-* In ``__init_subclass__``, on the class object received as the first parameter (likely, ``cls``).
+* At declaration in the class scope.
+* In ``__init_subclass__``, on the class object received as the first parameter (usually, ``cls``).


Suggested change

* In ``__init_subclass__``, on the class object received as the first parameter (usually, ``cls``).

* In ``__init_subclass__``, on the class object received as the first parameter (usually ``cls``).

carljm · 2026-03-03T19:06:53Z

peps/pep-0767.rst

@@ -433,6 +438,8 @@

 * Subtypes can :external+typing:term:`narrow` the type of read-only attributes::


Suggested change

* Subtypes can :external+typing:term:`narrow` the type of read-only attributes::

* Subclasses can :external+typing:term:`narrow` the type of read-only attributes::

carljm · 2026-03-03T19:09:08Z

peps/pep-0767.rst

-    This feature conflicts with :data:`~object.__slots__`. An attribute with
-    a class-level value cannot be included in slots, effectively making it a class variable.
+    This is possible only in classes without :data:`~object.__slots__`.
+    An attribute included in slots cannot have a class-level default.


It's weird that this example is under "Class attributes" heading, when class attributes are defined as "annotated as both ReadOnly and ClassVar" -- but here it is not annotated as ClassVar.

I think this should be under instance attributes instead.

carljm · 2026-03-03T19:11:38Z

peps/pep-0767.rst

@@ -464,8 +473,9 @@
        def pprint(self) -> None:
            print(self.foo, self.bar, self.baz)


This is phrased as what code authors "should" do, but it does not provide clear specification to type checkers. It seems like type checkers are not required to verify initialization (though they optionally can). This just seems like another variant of "verify initialization". I'm not sure it makes sense as a separate point -- it could be mentioned above in the section about optionally verifying initialization?

Update Post-History

4186484

Clarify that bare `ReadOnly` is not allowed, and add that to rejected ideas Specify that `type[Protocol]` does not inherit the protocol's attributes Close issue: "Extending Initialization" Bikeshed on some wording Use my real name

Enegg requested a review from carljm as a code owner August 25, 2025 15:31

JelleZijlstra reviewed Aug 25, 2025

View reviewed changes

peps/pep-0767.rst Outdated Show resolved Hide resolved

Enegg added 2 commits August 25, 2025 21:54

Attribute access off a protocol's type shouldn't have a known type

fbe0191

the -> an

afa3056

carljm approved these changes Aug 28, 2025

View reviewed changes

peps/pep-0767.rst Outdated Show resolved Hide resolved

peps/pep-0767.rst Show resolved Hide resolved

Remove internal mutation restriction

11f4522

Enegg requested review from JelleZijlstra and carljm September 5, 2025 18:54

hugovk reviewed Feb 24, 2026

View reviewed changes

peps/pep-0767.rst Outdated Show resolved Hide resolved

Enegg and others added 4 commits February 26, 2026 20:40

Remove non-email address

9cbf97e

Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

Revert "Remove internal mutation restriction"

837d0f4

This reverts commit 11f4522.

Cherry-pick changes from reverted commit

50a10e4

"Terminology" section allow initializing read-only attributes by subclass allow `@classmethod` to initialize instance attributes allow `ReadOnly` + `Final`, though redundant

Merge branch 'python:main' into pep-767

b3d1909

oscarbenjamin reviewed Mar 2, 2026

View reviewed changes

carljm reviewed Mar 3, 2026

View reviewed changes

		Assignment to a read-only attribute can only occur in the class declaring the attribute
		and its nominal subclasses, at sites described below.

		* In ``@classmethod``\ s, on instances of the declaring class created via
		a call to the class' or super-class' ``__new__`` method.

	* In ``__init_subclass__``, on the class object received as the first parameter (usually, ``cls``).
	* In ``__init_subclass__``, on the class object received as the first parameter (usually ``cls``).

		@@ -433,6 +438,8 @@

		* Subtypes can :external+typing:term:`narrow` the type of read-only attributes::

	* Subtypes can :external+typing:term:`narrow` the type of read-only attributes::
	* Subclasses can :external+typing:term:`narrow` the type of read-only attributes::

		@@ -464,8 +473,9 @@
		def pprint(self) -> None:
		print(self.foo, self.bar, self.baz)

Uh oh!

Conversation

Enegg commented Aug 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

hugovk left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Enegg commented Aug 25, 2025 •

edited

Loading