Comments (13)
It's good enough for me. :-)
I also like using cast() to initialize result variable with an empty container of the right type:
def word_count(input: Iterable[str]) -> Dict[str, int]:
res = cast(Dict[str, int], {})
for w in input:
res[w] = res.get(w, 0) + 1
return res
from typing.
Maybe we need different kinds of casts, like in C++? This makes me a little
sad, so much complexity to satisfy the type checker in rare cases.
On Wednesday, January 7, 2015, Jukka Lehtosalo [email protected]
wrote:
Yeah, cast() can be used with empty containers, but it has the drawback
that you don't get an error from mypy if you give a bogus type:a = cast(Dict[str, int], []) # ouch, no error
If you use a # type: comment, you'll get an error:
a = [] # type: Dict[str, int] # error, incompatible types in assignment
cast() just blindly accepts whatever you give it. This is different from
Java, for example, where the compiler catches some bogus casts. Mypy could
also do that, but only for built-in types (since they don't support
arbitrary multiple inheritance).—
Reply to this email directly or view it on GitHub
#15 (comment).
--Guido van Rossum (on iPad)
from typing.
from typing.
Mypy treats # type:
comments differently from casts. When using a comment, types still have to be compatible. For example, this is not valid:
def f(x: Sequence[int]) -> None:
y = x # type: List[int] # Error, since Sequence is not compatible with List
However, this is okay:
def f(x: Sequence[int]) -> None:
y = cast(List[int], x) # Fine
Effectively, type annotations (comments) are type safe (or as type safe as anything in mypy), but casts can do arbitrary things and work around the restrictions of the type system.
Also, cast
can be used within expressions, whereas a type comment is only valid for assignment statements. This is often useful. Here is a toy example:
foo(cast(List[int], x))
If we used a type annotation as a cast, this would require an extra local variable:
tmp = x # type: List[int]
foo(tmp)
In more complex cases the refactoring could be non-trivial (it could break the order of evaluation in a boolean expression, for example).
from typing.
@JukkaL, do you have non-toy examples where working around the type system with cast()
is necessary? That would be good to put in the PEP.
from typing.
It's actually a bit tricky to give a short, realistic example where a cast is clearly useful. Here is one inspired by a similar example in mypy:
def find_first_str(a: Sequence[object]) -> str:
index = next((i for i, s in enumerate(a) if isinstance(s, str)), -1)
if index >= 0:
return cast(str, a[index])
else:
raise ValueError
Every example with a cast can be rewritten to not need a cast, but when adapting existing dynamically typed code, introducing a cast is often the simplest way of getting a piece of code to type check.
from typing.
Yeah, cast()
can be used with empty containers, but it has the drawback that you don't get an error from mypy if you give a bogus type:
a = cast(Dict[str, int], []) # ouch, no error
If you use a # type:
comment, you'll get an error:
a = [] # type: Dict[str, int] # error, incompatible types in assignment
cast()
just blindly accepts whatever you give it. This is different from Java, for example, where the compiler catches some bogus casts. Mypy could also do that, but only for built-in types (since they don't support arbitrary multiple inheritance).
from typing.
How about:
cast(Dict[str, int], []) # error
with typing.skip_type_checks:
cast(Dict[str, int], []) # okay
from typing.
Łukasz, I presume you're talking about errors from the static checker only. After Jukka's comments in #33 I think it's better to use comments to disable the type checker than with-statements.
Doing runtime checks in cast() is madness anyway (it took me a little while to realize this, but there are too many ways it can fail incorrectly, modify the value by even looking at it, or waste a lot of time).
from typing.
Yes, those would be static checker errors only.
Fixed in e2e6fc4 (advertises usage of @no_type_checks for routines and "# type: ignore" for lines).
from typing.
Oh, the core issue, whether we need cast()
is still open. @JukkaL, @gvanrossum, now that we endorse "# type: " comments, maybe a specific comment would be better suited for this?
Jukka, you were worried about runtime performance of cast(), the comment would resolve that.
from typing.
As mentioned earlier, a # type:
comment is not a replacement for a cast, since # type:
comments only act as hints and the type checker will still verify that the initializer type is compatible, whereas the type checker will assume that casts are valid and may allow code that does bad things at runtime. This is similar to Java variable type definitions vs. casts -- only the latter can be used to write 'unsafe' code.
So this would be rejected by the type checker:
x = <expression> # type: object
y = x # type: int # error, since object is not compatible with int
But this would be okay:
x = <expression> # type: object
y = cast(int, x) # okay (casts are usually used to go from a general to a narrower type)
Cast should be an expression, since casts are often used within subexpressions. # type:
comments, on the other hand, are only used for declaring the types of variables, so they are always applied to an assignment statement, and thus there is no need to nest them within expressions.
from typing.
Decision: we'll add cast()
to the PEP. Closing this issue; the TODO is added to the README.rst.
from typing.
Related Issues (20)
- Treat alternative syntax for unions (and other "new-semantics-old-syntax" typing features) in explicit `TypeAlias`es inside `if TYPE_CHECKING` blocks as stringized annotations. HOT 6
- Spec: Annotating the `self` argument in `__init__` methods HOT 17
- FYI: I removed the "stable" docs version
- Pre-draft proposal: Amend the prior removal of support for unpacking of typevartuples in union. (revisiting pep 646) HOT 1
- PR preview HOT 3
- Outdated stub package guidance HOT 1
- Integrate the Type Stubs document into the spec HOT 1
- Types for "truthy" and "falsy" values HOT 6
- Abstract classmethod returning object of type cls: "is not a supertype of its class" HOT 1
- hello
- Spec: Add PEP 696 (Type parameter defaults) HOT 2
- Spec: Add PEP 705 (Read-only TypedDict items) HOT 3
- Extra key of TypedDict HOT 2
- Reason given for disallowing non-concrete subtype assignment is unsound HOT 10
- Out-of-date description of how to indicate positional-only parameters
- Typing spec should be clearer that type checkers are not expected to support PEP 3141 HOT 22
- Incorporate PEP 483 into the spec HOT 5
- Conformance tests: Add mechanism to allow errors on one of multiple lines HOT 2
- Conformance tests: Add mechanism to ignore errors
- Conformance tests: Align automated and manual scoring
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from typing.