On Thu, May 7, 2015 at 7:25 AM, Dima Tisnek <dimaqq@gmail.com> wrote:

On 30 April 2015 at 14:33, Steven D'Aprano <steve@pearwood.info> 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 callable (int)?
>
> 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?

--Guido van Rossum (python.org/~guido)