MIME-Version: 1.0
In-Reply-To: <MPG.2f35eef1cc884a1b9896b6@nntp.aioe.org>
References: <54c07d04$0$13012$c3e8da3$5496439d@news.astraweb.com> <1939680766443642112.878725sturla.molden-gmail.com@news.gmane.org> <CANc-5Uy3as3J=_h7oJiG4xY9kwSzchmxt=6bKZoEQhc4HHvePA@mail.gmail.com> <mailman.17982.1421951313.18130.python-list@python.org> <6eb91c4b-92ff-44a8-b5a9-6ef04c71f4cb@googlegroups.com> <MPG.2f2b9739d70d7220989688@nntp.aioe.org> <35a40ec6-3763-448b-9ea4-4a233a04979b@googlegroups.com> <54c1ccc8$0$13005$c3e8da3$5496439d@news.astraweb.com> <mailman.18150.1422284487.18130.python-list@python.org> <54c6d7c2$0$12992$c3e8da3$5496439d@news.astraweb.com> <mailman.18178.1422380228.18130.python-list@python.org> <MPG.2f31f0482d3837cb98969f@nntp.aioe.org> <54c83ab4$0$12982$c3e8da3$5496439d@news.astraweb.com> <MPG.2f3318cb4d02fd059896b2@nntp.aioe.org> <mailman.18229.1422469034.18130.python-list@python.org> <MPG.2f340c6ea39d9f3f9896b3@nntp.aioe.org> <54ca5bbf$0$12992$c3e8da3$5496439d@news.astraweb.com> <MPG.2f35eef1cc884a1b9896b6@nntp.aioe.org>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Fri, 30 Jan 2015 14:50:23 -0700
Subject: Re: Python is DOOMED! Again!
To: Python <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.18323.1422654667.18130.python-list@python.org>
Lines: 51
NNTP-Posting-Host: 2001:888:2000:d::a6
Path: csiph.com!usenet.pasdenom.info!bete-des-vosges.org!feed.ac-versailles.fr!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Xref: csiph.com comp.lang.python:84920

On Fri, Jan 30, 2015 at 11:42 AM, Mario Figueiredo <marfig@gmail.com> wrote:
> To be clear, type declarations in Julia, Scala, C have the potential to
> produce side-effects, can result in optimized code and can result in
> compile time errors or warnings. They also affect runtime evaluation as
> you could easily attest if you input a float into a function expecting
> an int, whereas in Python the float will be gladly accepted and will
> only fail at the point in code where its interface won't match the
> statement.

At least for C, as I noted in a previous post, it is simply not true
that they are used for runtime evaluation. For example:

>>> import ctypes
>>> libc = ctypes.CDLL("libc.so.6")
>>> libc.abs(ctypes.c_double(123.456))
2093824448

The C compiler may complain about it, but that's a compile-time static
check, no different from the sort of checks that PEP 484 seeks to add
to Python.

> Meanwhile, type annotations in Python are instead completely ignored by
> the interpreter. They do nothing of the above. They do not participate
> in code generation and execution.

But unlike C, Python lets you easily implement this yourself if you want to.

>>> def runtime_type_check(f):
...   @functools.wraps(f)
...   def wrapper(**args):
...     for arg, value in args.items():
...       if arg in f.__annotations__:
...         if not isinstance(value, f.__annotations__[arg]):
...           raise TypeError("Arg %s expected %s, got %s"
...               % (arg, f.__annotations__[arg].__name__, type(arg).__name__))
...     return f(**args)
...   return wrapper
...
>>> @runtime_type_check
... def add(x:int, y:int) -> int:
...   return x + y
...
>>> add(x="hello", y="world")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 8, in wrapper
TypeError: Arg y expected int, got str

(This could of course be extended for positional arguments and more
complex annotations, but I wanted to keep it simple for the purpose of
the example.)