On Wed, Sep 7, 2016 at 9:56 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>
> Exactly - in a dynamic language like Python, running a typechecker is
> a form of testing, rather than a necessary part of getting the code to
> work in the first place.
>
The average programmer such as myself will expect that if I write code
specifying the type of a variable or whatever it should *do
something*. It's code, I wrote it, it should be interpreted.
Assuming PEP 526 is implemented, suppose as a very new programmer I write
foo: dict = 0
(If anyone thinks even new programmers wouldn't write that, you've
never taught an introductory programming course.)
It takes very little programming experience to know that is flat out
wrong. I cannot think of any other programming language with type
notation where this would not be immediately flagged as an error. But
Python will silently accept it? That's the kind of one liner people
put on presentation slides when they want to make fun of how bad
programming languages like JavaScript are.
A more subtle example that came up recently on one of the lists (which
I cannot attribute it properly right now):
c : complex = 1.0
My C compiler is smart enough to figure out it should add an imaginary
zero to the RHS. As an average programmer, I'd expect that Python
would be at least as smart and likewise convert 1.0 into a complex
value. Or it could raise an error saying that the RHS is not a complex
number. Given the code I've written, either makes sense.
What I would not expect is for the interpreter to silently assign a
scalar 1.0 to c and continue. That's just ... WTF?
Type annotations are code, not tests.
--
cheers,
Hugh Fisher
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
