[Python-ideas] PEP 484 (Type Hints) -- first draft round

Chris Barker chris.barker at noaa.gov
Mon Jan 19 08:00:54 CET 2015

On Sun, Jan 18, 2015 at 7:28 PM, Guido van Rossum <guido at python.org> wrote:

> Um, what did you mean by "run-time of compile time static typing"? I'm
> guessing "or" instead of "of". With that assumption, I think the answer is
> both.

sorry for the typo -- yes that was supposed to be "or"

I want annotations to be (eventually) reserved for a standard type
> notation. The PEP focuses on the notation. The (by far largest) use case I
> see for the notation is running a separate off-line type checker, which
> acts like a linter but with much more understanding of types. (But not
> perfect!) A second use case (for the same notation!) is equally off-line,
> to provide information an IDE needs so it can give accurate suggestions etc.

both good things, yes.

> Some use cases that people (including myself) have often assumed but which
> I now find mostly anti-ideas: efficient code generation; run-time type
> checking; exact type checking by the Python interpreter when it compiles
> and loads modules.

I guess that's what I"ve pickedup on -- "anti-ideas"? but these are key for
some of us...

> I think it would be nice too. But what I hear from Stefan is that Cython's
> requirements are not a good fit for the proposal. And I believe it makes
> more sense to let Cython continue to do its own thing rather than trying to
> either expand the proposal so Cython can use it without change, or allow
> for alternate type notations so Cython can do its own thing. The latter
> however sounds closer to what's possible.

maybe that will have to be the way to go -- but if still seems like we are
building a too-limited system right up front -- that may be necessary to
keep it from being too ugly. You've certainly been thinking about this a
long time.

> Everything in the proposal has a namespace (either 'typing' or 'builtins')
> and the checker is expected to understand and follow imports properly. So I
> don't see a problem here.

OK -- that could be very helpful.

> Anyway, I guess it's unclear to me whether the intent is to create a
>> system that can be used for a static/run-time type checker like Cython.
> That is not the intent. (Though static and run-time seem two very
> different forms of type-checking. Apparently Cython does both?)

well, if you typedef a name:

cdef int i

then Cython generates static C code that uses i as an int (C int in this

and if you typedef a function's parameters:

def func(int i):

then Cython generates code that tries to convert the argument to that type
at run-time, raising an exception if it can't -- that's what i mean by run
time type checking (I guess it's run-time type conversion, but it has to
check in order to convert)

There have been a fair number of comments alone the lines of "this is only
>> for lint-like static analysis". But I'd really love to see this move toward
>> full functionailty.
> Once this proposal is in place you may try to adapt it for that purpose.
> But I'm not holding my breath, and I think we're better off with an
> imperfect proposal that can make it into 3.5 than with waiting until the
> ideal all-encompassing proposal is written.

makes sense, but hopefully it will be an imperfect proposal that can evolve
inot a more-perfect one in the future.

> But in the case of Python, the performance thing is entirely unproven, and
> the focus on it is a hindrance to trying to get any type system at all
> introduced.

Cython makes all the difference in the world for certain types of code. How
is that unproven?

> Nobody writes enough tests though, and type checking catches a different
> category of issues (shallow or not) than tests.

well, hard to argue that catching more bugs isn't a good thing.

On the other hand, dynamic typing does impact performance in a way that
>> effects my code -- so I tun to Cython (and sometimes C, C++, Fortran) to
>> address those issues. (maybe JIT compilation will one day meet this need,
>> but it hasn't yet).
>> So if there is type specifying, I want i to solve these problems.
> How?

I meant that the new type specifying system should be usable by a static or
JIT compiler to generate more optimized code -- i.e. Cython (or numba,

But where I'm lost is the utility of static analysis that is not used to
>> either provide run-time type checking OR compile optimized code (either JIT
>> or ahead-of-time). It seems that your entire system would have to be fully
>> type-hinted to get the type safety. But once you've done that, why not just
>> use a static language?
> However, gradual typing, for dynamically-typed languages, takes a
> different position. It claims that if you can type-check *some* of your
> program, the added type safety for that part helps find bugs. It's not a
> black or white situation. Just like a linter will find some bugs (after you
> wade through the false positives, tuning the linter options locally and
> globally to get a decent yield), a type checker of the kind proposed here
> will find some bugs (after you spend some time adding type annotations to
> part of the program).

Again, hard to argue that catching more bugs isn't a good thing. But
thanks, this makes it more clear to me what' meant by 'gradual typing"

I'm not sure that will satisfy the "enterprise" folks that really want
static typing checking, but they can keep using Java, I guess.

I do wonder how much this will "infect" Python, and folks will add all this
completely unnecessary type hinting that will just make it harder to use
libraries off the shelf.

On the other hand, if run-time type checking is provided, then you could
> use that at the boundaries of your code base (kind of like Cython does) and
> get both the safety and performance benifits.
> But it sounds like it is Cython's job to do the checking at these
> boundaries. Isn't this similar to the way Python extensions written in C or
> C++ have to do type checking at the boundary between Python code and the
> extension?

exactly -- all cython really does is write a C extension for you --
auto-generating all that boilerplate.

> The specification of these checks should be defined by Cython.

Sure, but they are almost always a direct result of type, so all I do when
I write cython is specify type. And as you point out about gradual typing,
I don't need to specify type at all, Cython is perfectly happy working with
python objects and leaving the type checking to run time.

But just as you can now run any (most, anyway...) python code through
Cython, or would be great to be able to run any type annotated code through
Cython, and hopefully get some benefit from the type annotations, and not
have to essentially add redundant information.

> I've read the MyPY FAQ, which does address these issues to some extent,
>> but doesn't really make a compelling case to me, anyway.
> It did to me. :-)

I'm getting close with your additional notes...

I guess the gist here is that I think if Python is going to have an
>> official type hinting system, it should leave the door open to compile time
>> and run-time type checking. A good test case might be: can it be used for
>> Cython? But this thread seems to be indicating that that is not the goal,
>> and indeed, that it's almost an anti-goal. I hope I'm wrong about that.
> TBH I think the question of whether it can be used for Cython is still
> very much open. Why couldn't Cython take code that says a certain parameter
> has type List[int] and generate code from it?

it probably could -- I think it's a good idea for us to start playing with
that sort of thing.



Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150118/ff5ca54b/attachment.html>

More information about the Python-ideas mailing list