[Python-Dev] What's missing in PEP-484 (Type hints)

[Guido van Rossum]

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

> On 30 April 2015 at 14:33, Steven D'Aprano <steve at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150507/cc198c9d/attachment.html>