It would be great if a return type could describe/construct a read-only type for a TypedDict instance

[gh-andre]

It would be quite useful if TypedDict instances could be returned as read-only references, similar to how one can return a const refence in C++. Here's an example.

class UserDoc(TypedDict):
    name: str
    screen_name: NotRequired[str]

class User:
    def __init__(self, user_doc: UserDoc) -> None:
        self._user_doc = user_doc

    @property
    def name(self) -> str:
        return self._user_doc["name"]

    @property
    def screen_name(self) -> str|None:
        return self._user_doc.get("screen_name")

    @screen_name.setter
    def screen_name(self, value: str|None) -> None:
        if value is not None:
            self._user_doc"screen_name"] = value
        else:
            del self._user_doc"screen_name"]

    def get_user_doc(self) -> UserDoc:
        return self._user_doc

The get_user_doc method is typically used for things like inserting the underlying document into the database, etc, but may also be used to bypass the elaborate property methods above and set anything in the typed dictionary. The only way to get around this today is to use deep copies, so a temporary copy is returned for every call.

If a const-reference type could be constructed on the fly by static type checkers, it would create a special class that would have all fields wrapped in ReadOnly, such that something like this:

    def get_user_doc(self) -> ReadOnly[UserDoc]:
        return self._user_doc

, would produce the equivalent of this:

user_doc: ReadOnly[UserDoc] = user.get_user_doc()

class UserDoc(TypedDict):
    name: ReadOnly[str]
    screen_name: ReadOnly[NotRequired[str]]

That would allow exposing read-only references to typed dictionaries and would align very well with various ways to control access to object fields, like those @property constructs provide.

This mechanism would apply only to typed dictionaries, so there's no need to invent the equivalent of const methods, like those in C++, and this could be contained fully within the static typing ecosystem.

[Daverball]

This suggestion came up during PEP 705's discussion, unfortunately it's ambiguous:

class Foo(TypedDict):
   x: str

class Bar(TypedDict):
   y: ReadOnly[Foo]  # what does this mean? Is it a `ReadOnly` version of `Foo` or is the `y` key read-only?

A better avenue would be a dedicated type modifier like e.g. Immutable. Partial was also suggested at one point, which would be the equivalent type modifier for turning all keys into NotRequired.

The main problem with type modifiers like this however, is that they currently would only be well-defined for TypedDict, which begs the question if a type constructor à la NewType wasn't a better way to do this, even if it ends up being a little bit more verbose.

Something more generic and flexible would arguably be even better though, which would let you define your own Partial and Immutable type modifiers.

See e.g. how Partial is implemented in TypeScript:

type Partial<T> = {
    [P in keyof T]?: T[P];
};

[Daverball]

Whatever the committee decides, I suppose, but references to other programming languages may help, such as the TypeScript above makes it a read-only field, and C++ does the same, where an equivalent of the Xy class implemented with pointers (e.g. const Xy xy{new std::string("A"), new int(1)}) will allow me to change the value of what the pointer points to, but not the pointer itself, as it would be impossible to propagate this down all the fields in an object.

That was a rhetorical question, it was already decided, that it wasn't going to fly, due to the inherent ambiguity. ReadOnly should mean the same thing no matter the context. In PEP 705's case it was defined as a type qualifier, so it's a property of the type that contains the reference, not the type that's enclosed in the brackets, just like Final/ClassVar/Required/NotRequired.

What you're proposing is a type modifier, as it modifies the type it's enclosing. We don't have any type modifiers yet in Python's type system.

I think immutability is a heavier concept, like a string object that cannot be modified at all, and perhaps it would not be very descriptive as a read-only modifier for a return type, etc. In the context of this thread, I'm thinking of a modifier for a reference to an existing TypeDict instance that turns it into a read-only instance within the applicable scope, such as passing an argument into a method or getting a reference to a class member via a return value.

I can see the potential for confusion, since a modified type can still change its value through a separate mutable reference, but it makes sense as soon as you consider it a property of the reference, rather than the object. Just like in Rust you either take an immutable or mutable reference to objects. So Immutability in this context just means the holder of the immutable reference can't mutate the object, not that the object itself is immutable. So I think the terminology Immutable is fine and less confusing than ReadOnly, considering it already means something completely different in Python's type system.

[Daverball]

Also note how TypeScript distinguishes between camel case readonly for the type qualifier and pascal case for the utility type modifier Readonly. In Python we don't have that option, since all our special-forms are always pascal case, so the only way to distinguish between the two meanings is to use a distinct name.

But I think you'll face an uphill battle trying to get this added as its own thing, when TypeScript has already proven that mapped types could gives us this for free, with no additional special-casing required by type checkers. So you'll probably have an easier time with a proposal for mapped types, than individual proposals for Partial/Immutable. Even though it'll be more challenging to specify in Python, since we have to worry about runtime introspection, so we realistically can't rely on existing generator expression syntax and have to come up with something else, that's still ergonomic, reasonably performant and understandable.

[gh-andre]

Thanks for your detailed responses.

Just to be clear, I'm not arguing for actually implementing this via ReadOnly, but rather for having a type of a reference declaration to another variable that provides a read-only access to that original variable. The ReadOnly qualifier seemed like a natural extension of the existing mechanism for TypedDict instances, but I will happily use whichever mechanism would be implemented, as long as there's one.

how TypeScript distinguishes between camel case readonly for the type qualifier and pascal case for the utility type modifier Readonly

Python's TypedDict is different when compared to other types in that its static type is constrained by its layout, like in TypeScript, and not the actual type name, like with other classes. The reason I thought ReadOnly could be used here is because it's applicable only against TypedDict fields, so it seemed like a natural extension of the existing functionality to make read-only references to TypedDict instances. It wouldn't be applicable to other types, like regular class data members, just like ReadOnly isn't.

With regards to readonly vs. Readonly (BTW, these are neither camel nor Pascal case), I used both forms on purpose, just to show that the utility type merely provides a concise way of adding the readonly qualifier, but otherwise it uses the same mapped types functionality, which seemed to me like a good case for ReadOnly used the same way.

Having said that, if there is a desire is to extend this commonly-used technique of creating read-only references to include other Python classes, I would actually agree that ReadOnly is probably not the best vehicle for it, given that it's limited to TypedDict.

[Daverball]

There already is a proposal to widen ReadOnly to all classes, not just TypedDict. It's a very natural extension for Protocol, since those are also structural types, but it's useful even in nominal types, since it doesn't lock you into using @property.

And I agree, using mapped types would be better for adding the ReadOnly qualifier to all the TypedDict fields, that is what I'm advocating for, rather than introducing a new special-form or changing the meaning of ReadOnly in some contexts. Since the former is expensive for type checkers to maintain and the latter is confusing for users of the language and backwards incompatible.

Once we have this ability, the standard library can always choose to ship its own convenience type modifiers like Partial, since type checkers can then just rely on their existing support for mapped generic types, rather than needing to maintain a separate implementation for Partial (it will need to choose a different name for ReadOnly though, since it's already taken).

(Also Readonly is the Pascal case counterpart to readonly, you can argue whether or not readonly is camel case, but in the TypeScript naming convention it's supposed to be, it's possible they based it on the hyphenated read-only and for that reason chose to not capitalize the Only part, or it was an accidental inconsistency and instead of making things even more inconsistent by naming the convenience modifier ReadOnly, they named it Readonly, so the two names are at least consistent with each other)

[gh-andre]

I think we are agreeing in principle that there's a need for the type of a functionality that would allow one to create read-only references to otherwise mutable variables. In the OP I was thinking specifically of the TypedDict type, given its similarity with the TypeScript layout-based typing, which probably could be implemented in a simpler way, compared to the more general case that would affect all Python types. In any case, hopefully, something along these lines is in the works.

Thanks for your insights.