On 9 Jun 2020, at 03:35, Dominik Gabi <dkgispam@gmail.com> wrote:
1. I would like to re-focus the discussion on the pull request linked to in the initial post rather than the particular semantics of unbound type variables in callables: https://github.com/python/typeshed/pull/4045
Specifically,
@mrkmndz Sorry for forgetting to answer. Yes, considering theconsequences this has for the typing infrastructure, I think this should be discussed on typing-sig.
@srittau: could you clarify what consequences you meant? What's the specific concern that should be discussed?
2. I would also like to hear people's thoughts on how to deal with disagreements on semantics where not specified in PEPs in shared infrastructure. This is one particular example but I'm sure this will happen more in the future. _______________________________________________ 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/ Member address: jakub@stasiak.at
Sure – I merely meant to bring some context to the thread. With my type hint writer and occasional consumer hat on I’d like to both be able to write and consume def fun() -> Callable[[T], T] because the other interpretation of the relevant specification doesn’t provide me value (I get an error). In general case, all things considered, if there’s one interpretation of some pattern that causes an error and another that does something desirable, precise, unambiguous and not really causing any errors by itself I’d like to be able to use this pattern and for the tools to converge on it. Replacing Callable[[T], T] with IdentityFunction adds an indirection which makes the type hints slightly worse to consume in my opinion. And I expect there are many uses of this pattern outside typeshed that’ll be difficult to track down and convert in similar fashion. Best, Jakub