Closed Felecarpp closed 1 year ago
Thanks for working on this.
I'm personally OK with ignoring some things for now, and revisiting them in the future. I guess the arguments are maybe more important than the return types (if only by a little), so getting those defined is a nice improvement. How about merging this in for now?
As for typing in general, whenever older Python releases go EOL it's a good time to see what syntax can be refined. I'm personally very much looking forward to using |
for Union
in the future ๐
Ok to merge as it is.
The X | Y
for Union syntax is still recent (python 3.10). Using it means to take two python releases off at the time (python 3.8 and python 3.9).
Another typing improvement (python 3.9) is using subscription on builtin types like list[tuple[str, int]]
(so remove some imports).
Thanks for working on this.
I'm personally OK with ignoring some things for now, and revisiting them in the future. I guess the arguments are maybe more important than the return types (if only by a little), so getting those defined is a nice improvement. How about merging this in for now?
As for typing in general, whenever older Python releases go EOL it's a good time to see what syntax can be refined. I'm personally very much looking forward to using
|
forUnion
in the future ๐
If so, @Felecarpp please create issue first not to forget about removing those ignores. But as far as I know cast
is just for static typing so not affecting performance.
https://docs.python.org/3/library/typing.html#typing.cast
at runtime we intentionally donโt check anything (we want this to be as fast as possible)
So yes, typing.cast
do not affect performance significantly.
The
X | Y
for Union syntax is still recent (python 3.10). Using it means to take two python releases off at the time (python 3.8 and python 3.9).Another typing improvement (python 3.9) is using subscription on builtin types like
list[tuple[str, int]]
(so remove some imports).
With from __future__ import annotations
both of these features can be used since Python 3.7.
typing.cast
isn't no cost. It costs less then isinstance
but still has the overhead of a Python call. It depends on how often the cast is called but I'd try to keep it out of the insertion, removal, or access of components. Personally, I wouldn't use the casts and instead change # type: ignore
to add the specific error code # type: ignore[no-any-return]
.
About X | Y
, an other PR can add this syntax.
About typing.cast
, I agree @HexDecimal. The minimal performance cost is using # type: ignore
in the function body. The typing in function header is enough to make mypy running when the function is called. So I think to commit again about this.
If you're OK, I'm happy to merge this as is. We can always follow up later.
I am OK to merge this as is.
GitHub shows me "Only those with write access to this repository can merge pull requests.".
mypy config dotfile with strict=True full typing of esper/_init__.py World(timed=True) become TimedWorld() 3 lines uses
# type : ignore
to disable type check on the line