conformance: allow consistent treatment of kwargs: Unpack[TD]#2272
Open
carljm wants to merge 1 commit intopython:mainfrom
Open
conformance: allow consistent treatment of kwargs: Unpack[TD]#2272carljm wants to merge 1 commit intopython:mainfrom
carljm wants to merge 1 commit intopython:mainfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The conformance suite currently asserts this (simplified for clarity):
This implies that the signature of
fde-sugars tof(*, v1: int). But the current conformance suite simultaneously also requires that callable assignability behave as if it de-sugars tof(*, v1: int, **kwargs: object). That addition to the conformance suite was justified by this call, which is allowed by pyright and pyrefly:It seems reasonable to allow this call, because TD2 is a subtype of TD1 and assignable to it, so
**td2should therefore be acceptable for**kwargs: Unpack[TD1]. But if this call (which definitely provides a keyword argumentv2) is allowed, then we should also allow the above call that explicitly providesv2.I think we could defensibly pick either of the interpretations of the signature of
f(with or without**kwargs: object), but type checkers should be allowed to pick a consistent interpretation, not be required to implement an inconsistent hybrid behavior.The interpretation with
**kwargs: objectis IMO more consistent and better supported by the spec. The spec says that ifTDhasextra_items, then arbitrary additional keyword arguments of that type should be accepted. And it also says that aTypedDictwithout an explicitclosedorextra_itemsparameter usually behaves as if it hasextra_itemsof typeReadOnly[object].The interpretation without
**kwargs: objectwould effectively be saying that**kwargs: Unpack[TD]is one of these special cases (along withTypedDictconstructor calls) where an unmarked TypedDict is (inconsistent with its "open" semantics) not treated as havingextra_itemsof typeReadOnly[object].We can have a discussion about which of these interpretations should be preferred, but given the lack of clarity about this in the spec, I think for now a conformant implementation should be allowed to choose either interpretation and implement it consistently.