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

[Chris Barker]

On Fri, Jan 16, 2015 at 12:08 PM, Guido van Rossum <guido at python.org> wrote:

> Yes, the PEP tries to gently push an agenda where annotations are only
> used for Python type hints.
>

Type hints, as opposed to arbitrary other uses, or type _hints_ as aopposed
to run-time of compile time static typing?

Cython, providing both of those, for example.

I don't know what to answer for Cython -- doesn't it have its own syntax
> for declaring C types?
>

yes:

cdef int i

or:

def func( int i ).

There is also a decorator-based system, for "pure python

But I think it would be nice it it could use the same syntax as other
systems, particularly if there is an official one.


> If Cython uses annotations with different meanings, perhaps for Cython
> files the Python annotations could be put in stub files.
>

I think we're good there.

But I think Stephan's issues is that currently cython allows both C and
Python type names:

cdef int i
cdef list a_list

but where the names conflict, the C name is assumed (int, float, others?)

Given C's typedef, I'd say we should just have Cython use unique names --
i.e. c_int -> int, etc. But that all requires that no one decides to write
a new python type called c_int. Though I'm not sure it's really a problem
to reserve names for Cython.

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. 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.

In fact, after reading the PEPs, I still don't really see the point of
static type analysis that does not lead to compile time or run-time type
checking. Maybe someone could provide the motivation for that, oradd alink
to the PEP where that is.

My question:

I see two clear advantages to static typing: type safety and performance.

As a proponent of Python (and thus dynamic typing), I have argued a lot
that static type checking does indeed catch a lot of bugs, but they are
generally shallow bugs -- easy to test for, and easy to understand and fix
-- thus I don't much need that. However, I can see how it's a "good thing",
and maybe important for "Enterprise" systems.

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.

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?

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.

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.

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.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

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/1c635762/attachment.html>