Skip to content
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

Mappings first type parameter should be covariant #268

Open
KotlinIsland opened this issue Apr 9, 2024 · 2 comments
Open

Mappings first type parameter should be covariant #268

KotlinIsland opened this issue Apr 9, 2024 · 2 comments
Labels
based non-standard/breaking change (something you'd want to disable if developing a lib) type checking / linting issues relating to existing diagnostic rules or proposals for new diagnostic rules

Comments

@KotlinIsland
Copy link
Collaborator

KotlinIsland commented Apr 9, 2024

Attention!

Basedmypy supports this feature

Issue

m1: Mapping[str, object] = {"a": 1}
m2: Mapping[object, object] = m1  # error, lame

There are many many issues around about this

backwards compatibility assurance

there is a vary low chance of breaking edge cases of implementations of Mapping that abuse the invariant param:

from typing import *

class BadMap[K, V](Mapping[K, V]):
    def __init__(self, key: K, value: V):
        self.key: K
        self.value: V

    _secret_key: K

    @override
    def __getitem__(self, key: K) -> V:
        """you have to override a method method that takes `K` and make it do something unsafe like store the value"""
        self._secret_value = key
        return self.value

    def get_key(self) -> K:
        return self._secret_key

m: Mapping[str, object] = BadMap("key", "value")
b: Mapping[object, object] = m
b[2]
m.get_value()  # revealed str, actually 2

I believe that this would be extremely rare in real life.

Upvote & Fund

  • We're using Polar.sh so you can upvote and help fund this issue.
  • We receive the funding once the issue is completed & confirmed by you.
  • Thank you in advance for helping prioritize & fund our backlog :^)

Fund with Polar

@KotlinIsland KotlinIsland added the based non-standard/breaking change (something you'd want to disable if developing a lib) label Apr 9, 2024
@DetachHead DetachHead added the type checking / linting issues relating to existing diagnostic rules or proposals for new diagnostic rules label Apr 9, 2024
@DetachHead
Copy link
Owner

im hesitant to support this because it's technically unsafe. i've never run into any issues with it in its curent state

@DetachHead
Copy link
Owner

imo a better solution is to do #413 then create our own Mapping type that utilizes this functionality, to avoid breaking existing usages of Mapping

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
based non-standard/breaking change (something you'd want to disable if developing a lib) type checking / linting issues relating to existing diagnostic rules or proposals for new diagnostic rules
Projects
None yet
Development

No branches or pull requests

2 participants