I vaguely remember reading some discussion about Annotated and, for what
little it's worth, I disagree with the consensus.
For now all that comes to mind is either stuffing the information in
docstrings (which would be kind of an involution, seeing as that was the
way for annotating type before type annotations), or changing the name
of the type to something more obvious at a glance. Something like
Typeguards["param", T], if arbitrary strings could be included, which
would have to correspond to parameter names. This would give a few extra
advantages:
- Multiple parameters could be annotated per function if needed (e.g.
def my_function(param1, param2) -> Typeguards["param1", T, "param2",
U]). An alternative syntax could be Typeguards[["param1", T], ["param2", U]]
- Functions with additional parameters that the function uses but which
are not typeguarded could be used, and there would be no ambiguity as to
which parameter is affected by the typeguard: def my_function(param1:
Any, param2: bool) -> Typeguards["param1", T]
Personally, I like the idea of functions that /happen/ to restrict the
type of a variable without it necessarily being their only or primary
goal; this would enable those.
Possible alternative names: Ensures["param1", T], Ensure["param1", T],
IsType["param1", T]. It's important to remember that jargon creates a
potential hurdle to comprehension, so simpler language should, in my
opinion, always be preferred.
Side-note: | is being introduced for union types in type annotations.
Could it be an idea to add a & as well, to signal side-effects of the
function that do not interfere with the return value? A function could
then have a signature like:
- def my_function(param1, param2) -> bool & Typeguards["param1", T]
- def my_function(param1) -> int & Typeguards[T] # Only one param, so
"param1" is optional
I realise it would make signatures (optionally!) longer and arguably
uglier, but the latter is mostly a matter of personal taster and of
getting used to, which is always there when new features are introduced.
I remember := being controversial, but it grew on me over time.
I hope there's at least something worth considering in the above ideas.
On 07/04/2021 21:59, gu...@python.org wrote:
But it isn't a "side effect". It is a distinct concept that is
important to the type checker.
Note that in TypeScript this also doesn't look like a boolean -- it
uses a unique syntax that has to be learned:
function isCustomer(partner: any): partner is Customer {
. . .
}
Arguably the TS syntax is more easily intuited without looking it up,
but TS has a certain freedom in its syntactic design that we don't
have for Python: new *syntax* has to be added to the Python parser and
can't be backported, whereas new *types* (like `TypeGuard[T]`) can
easily be backported via typing_extensions.py.
We have really tried, but we did not come up with anything better than
the current PEP.
FWIW you might be interested in Annotated (PEP 593), which can be used
to indicate various attributes of a type annotation. Before you
suggest that we adopt that instead of PEP 647, we considered that, and
the consensus is that that's not what Annotated is for (it's intended
for conveying information to tools *other* than the type checker, for
example schema checkers etc.).
--
--Guido van Rossum (python.org/~guido <http://python.org/~guido>)
/Pronouns: he/him //(why is my pronoun here?)/
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/AMAXAPIZIHW2IATRQDQYWMKTRZAWS6W3/
Code of Conduct: http://python.org/psf/codeofconduct/
