Repository navigation
Conversation
sobolevn
left a comment
There was a problem hiding this comment.
please, improve test coverage: more paramspec and typevartuple types :)
6b93bab to
afc37ad
Compare
The positional fallback for ParamSpec/TypeVarTuple aliases had the original bug (as I noted in PR description before) and I was too lazy to change their behavior that day. However, since you asked for tests, I got my act together and replaced it with binding by declared parameter for all kinds =) |
| return has_default is not None and has_default() | ||
|
|
||
|
|
||
| def _resolve_type_alias(alias, args): |
There was a problem hiding this comment.
Question: can we re-use some parts of typing.py? this looks like a complete rewrite from scratch
There was a problem hiding this comment.
Hmm, I guess we can at some point. The reason I wrote it from scratch is that it was easier to debug to me.
There was a problem hiding this comment.
Well, after a few hours I couldn't think of anything better than reusing typing's __typing_prepare_subst__ for binding and our existing _apply_params for substitution. IIRC there is no public api for resolving aliases, and I am not familiar with private ones if they do exist.
Co-authored-by: sobolevn <mail@sobolevn.me>
Generic
typealiases bind their arguments by position in the alias body instead of by declared parameter order. The body's__parameters__follow first appearance, so fortype Swap[A, B] = dict[B, A]the arguments end up swapped:The same happens with
ParamSpecandTypeVarTupleparameters whenever the declared order differs from the body's:^ it now goes through
_resolve_type_alias, which binds by name, applies PEP 696 defaults, and raisesTypeErroron too many / few arguments.