
Looks all fine. Just double checking that the expectations is that for Enums you need explicit enum reference, however for IntEnum literal both the int number or the enum form is accepted, not (following the rules at https://www.python.org/dev/peps/pep-0586/#id20) ? (to follow language semantic) from enum import IntEnum class Test(IntEnum): A = 1 B = 0 M = {Test.A : 'a', Test.B : 'b'} print(M[1], M[0], M[Test.A], M[Test.B]) a b a b Another thought; for a TypedDict does this mean we (type checker) can now generate the items function as a generator of literals? Is the following the expected behaviour of a type checker? class Movie(TypedDict): name: str year: int a = {'name': 'a', 'year':int} reveal_type(tuple(a.items())) Tuple[ Tuple[Literal['name'], str], Tuple[Literal['year'], int] ] reveal_type(list(a.items()) List[ Tuple[Literal['name', 'year']], Union[int, str]] On Tue, May 21, 2019 at 11:26 PM Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On Mon, 20 May 2019 at 18:28, Sebastian Rittau <srittau@rittau.biz> wrote:
Am 20.05.19 um 16:30 schrieb Guido van Rossum:
I'm planning to accept the following PEPs related to the type system later this week:
PEP 544: Protocols PEP 586: Literal Types PEP 591: Final qualifier and @final decorator PEP 589: TypedDict
All of these have been proposed for and discussed before.
I look forward to these PEPs becoming part of the standard Python type system. One thing is a bit unclear to me in PEP 544, though: Can explicit protocols be used to mark classes that implement some of the protocol members dynamically. For example:
------------------------
from typing import Protocol, Any
class Foo(Protocol): def bar(self) -> str: ...
class ExplicitFoo(Foo): pass ExplicitFoo.bar = lambda self: "some-value" # type: ignore
class ImplicitFoo: pass ImplicitFoo.bar = lambda self: "some-value" # type: ignore
x1: Foo = ExplicitFoo() x2: Foo = ImplicitFoo()
------------------------
The text in the section "Explicitly declaring implementation" is a bit ambiguous about it, saying "So while it's possible to subclass a protocol explicitly, it's not necessary to do so for the sake of type-checking." In the case of ExplicitFoo, explicitly deriving from the protocol seems to be necessary. The section "Subtyping relationships with other types" actually says that ExplicitFoo is not a subtype of Foo: "A concrete type X is a subtype of protocol P if and only if X implements all protocol members of P with compatible types. ..."
I don't think there is a contradiction here. `ExplicitFoo` _inherits_ `bar` from Foo. The methods in protocol bodies serve as "default implementations" unless explicitly marked as abstract. Even in this case, they are inherited, and an error will be given only at instantiation point.
Actual implementation in mypy does look at MRO, but this is just an implementation detail (mostly for performance).
If you have a concrete proposal about improving wording here (better as a PR), then I will be happy to consider it.
-- Ivan
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/