Skip to content

TypedMapping for extended compatibility? #1952

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ego-thales opened this issue Mar 26, 2025 · 4 comments
Open

TypedMapping for extended compatibility? #1952

ego-thales opened this issue Mar 26, 2025 · 4 comments
Labels
topic: feature Discussions about new features for Python's type annotations

Comments

@ego-thales
Copy link

Hello,

Consider the following, where lock aims at making provided argument immutable.

@dataclass
class Works:
    foo: Mapping

    def lock(self) -> None:
        self.foo = MappingProxyType(self.foo)

It works great with mypy, no issue. Now imagine I want to enforce a bit more to foo by requesting it be compatible with a Movie. I would try the following, without success.

class Movie(TypedDict):
    author: str
    year: int

@dataclass
class Fails:
    foo: Movie

    def lock(self) -> None:
        self.foo = MappingProxyType(self.foo)  # error: Incompatible types in assignment (expression has type "MappingProxyType[str, object]", variable has type "Movie")  [assignment]

Is there an workaround? If not, is if a good idea to discuss the possibility of a TypedMapping, that would simply work as follow?

class Movie(TypedMapping):  # New feature ?
    author: str
    year: int

@dataclass
class Fixed:
    foo: Movie

    def lock(self) -> None:
        self.foo = MappingProxyType(self.foo)  # Would work

Thanks for your time.

All the best!
Élie.

@ego-thales ego-thales added the topic: feature Discussions about new features for Python's type annotations label Mar 26, 2025
@ego-thales
Copy link
Author

ego-thales commented Mar 27, 2025

I found a few references mentioning this, most notably PEP 705 and a few related posts on the python forum:

One of the mentioned issue was the lack of "strong use-case", which is a bit hard to discuss in complete objectivity and time-consistency. I personally find the use case I described in opening quite standard.

A point I'd like to make is that many discuss TypedMapping as a "read-only TypedDict", which seems incorrect to me, as it misses the distinction between Mapping and MappingProxyType. I think describing TypedMapping as a base of TypedDict would be more appropriate.

@Gobot1234
Copy link
Contributor

Yeah that was how I thought about it originally. I would have liked it to type data frames and other mapping like things.

@jorenham
Copy link

jorenham commented Apr 11, 2025

With enum.Enum you can do something like

class DoubleThink(int, Enum):
    FIVE = 2 + 2

So how about using this same trick to avoid having to introduce a new typing member, and instead extend TypedDict so that you can do e.g.

class Movie(Mapping[str, str | int], TypedDict):
    author: str
    year: int

I'm not sure if this has been proposed before, but I thought I might as well throw it out there.

@ego-thales
Copy link
Author

I'm not entirely sure, but I think your approach forces inheritance from TypedDict which seems counterproductive (TypedMapping should be looser, am I right?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: feature Discussions about new features for Python's type annotations
Projects
None yet
Development

No branches or pull requests

3 participants