On Thu, May 7, 2015 at 7:25 AM, Dima Tisnek email@example.com wrote:
On 30 April 2015 at 14:33, Steven D'Aprano firstname.lastname@example.org wrote:
On Thu, Apr 30, 2015 at 01:41:53PM +0200, Dima Tisnek wrote:
# internal vs external @intify def foo() -> int: b = "42" return b # check 1 x = foo() // 2 # check 2
Does the return type apply to implementation (str) or decorated
I would expect that a static type checker would look at foo, and flag this as an error. The annotation says that foo returns an int, but it clearly returns a string. That's an obvious error.
Is this per PEP, or just a guess?
I think PEP needs to be explicit about this.
The PEP shouldn't have to explain all the rules for type inferencing. There's a section "What is checked?" that says (amongst other things):
The body of a checked function is checked for consistency with the given annotations. The annotations are also used to check correctness of calls appearing in other checked functions.
Normally local variables will have their type inferred from the
operations done to them:
s = arg[1:] # s has the same type as arg
Good point, should be mentioned in PEP.
Again, what do you want the PEP to say? I am trying to keep the PEP shorter than the actual code that implements the type checker. :-)
Technically, type can be empty list, mixed list or custom return type for overloaded __getitem__ that accepts slices.
I'm sorry if I was not clear. My question was how should type of ephemeral `x` be specified. In other words, can types be specified on anything inside a comprehension?
That's actually a good question; the PEP shows some examples of #type: comments in peculiar places, but there's no example using list comprehensions. Your best bet is to leave it to the type inferencer; if your comprehension is so complex that need to put type annotations on parts of it, you may be better off rewriting it as a regular for-loop, which offers more options for annotations.
Stub is better (required?) because it allows to specify types of attributes that are not assigned in class scope, but that are expected to be there as result of __init__ or because it's a C extension.
Note that the PEP does not explicitly say whether the information of a stub might be *merged* with the information gleaned from the source code. The basic model is that if a stub is present the implementation source code is not read at all by the type checker (and, conversely, information from stubs is not available at all at runtime). But it is possible for some type checker to improve upon this model.
An example in PEP would be good.
Can you give an example that I can edit and put in the PEP?