Re: [Python-ideas] Typecheckers: there can be only one

[Nick Coghlan]

On 8 September 2016 at 19:46, Hugh Fisher  wrote:
> On Thu, Sep 8, 2016 at 8:00 AM, Paul Moore  wrote:
>>
>>> Type annotations are code, not tests.
>>
>> Not in Python they aren't.
>
> The interpreter certainly thinks they're code rather than comments or
> docstrings, even before PEP 526. I type this into my Python 3.4
> interpreter:
>
 def foo(x:itn):
 ... return x
>
> and the interpreter raises a NameError because 'itn' is not defined.
>
> Annotations look like code, they're mixed in with names and operators
> and literals and keywords, and all the standard syntax and semantic
> checks are applied.

This is why I quite like the phrase "type assertions", particularly
for the variable annotation form - as with assert statements,
annotations are tests that you can write inline with your code rather
than necessarily putting them in a different file.

That doesn't make them not tests - it just makes them inline
self-tests instead of external ones.

The fact that assertions are checked by default (but can be turned
off), while annotations are ignored by default (but can be checked
with the appropriate optional tooling) has more to do with the
relative maturity of the typecheckers than it does anything else - at
this point in history, you still need to be on the lookout for bugs in
the typecheckers themselves, rather than assuming that because a
typechecker complained, there must be something wrong with the code.

Folks with the kinds of problems that typecheckers solve are likely to
be prepared to put up with the inconvenience of also dealing with bugs
in them. By contrast, folks that just want to run some Python code
that they already know works well enough for their purposes will want
Python to keep working the same way it always has. (Hence why all of
the typechecker developers chiming into these discussions point out
that they always err on the side of *not* complaining about *correct*
code, even if that increases their chances of missing some situations
where the code is actually wrong)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Typecheckers: there can be only one

[Hugh Fisher]

On Thu, Sep 8, 2016 at 8:00 AM, Paul Moore  wrote:
>
>> Type annotations are code, not tests.
>
> Not in Python they aren't.
>

The interpreter certainly thinks they're code rather than comments or
docstrings, even before PEP 526. I type this into my Python 3.4
interpreter:

>>> def foo(x:itn):
>>> ... return x

and the interpreter raises a NameError because 'itn' is not defined.

Annotations look like code, they're mixed in with names and operators
and literals and keywords, and all the standard syntax and semantic
checks are applied.

-- 

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/

Re: [Python-ideas] Typecheckers: there can be only one

[Nick Coghlan]

On 8 September 2016 at 07:31, Hugh Fisher  wrote:
> On Wed, Sep 7, 2016 at 9:56 PM, Nick Coghlan  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?

It wouldn't surprise me in the least if education focused environments
like the Mu text editor and potentially even Jupyter Notebooks decide
to start running a typechecker implicitly, as many IDEs already do
that. That way, if students do add type annotations (even if they're
missing from all of the example code presented), they'll be enforced
automatically.

That's a decision to be made by instructors and development
environment developers based on their assessment of their target
audience though, it isn't something that needs to be baked into the
core runtime design.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Typecheckers: there can be only one

[Sven R. Kunze]

On 08.09.2016 00:00, Paul Moore wrote:

On 7 September 2016 at 22:31, Hugh Fisher  wrote:

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.

Reading the documentation should correct that mistaken expectation.


If you need to read the documentation in order to understand a product, 
something's wrong. Especially given the simplicity of the examples.


Some smartphones are delivered without a manual because they are 
considered to be as intuitive as breathing or walking.



Type annotations are code, not tests.

Not in Python they aren't.


Unfortunately, that's not true. :)


Sven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Typecheckers: there can be only one

[Ivan Levkivskyi]

On 8 September 2016 at 00:00, Paul Moore  wrote:


> > Type annotations are code, not tests.
>
> Not in Python they aren't.
>

Well, to a certain extent. One can try something like this in REPL:

from typing import get_type_hints
import __main__

s: str

class C:
x: int

get_type_hints(C)
get_type_hints(__main__)

Although please remember that the PEP is still provisional and
implementation details may change.

--
Ivan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Typecheckers: there can be only one

[Paul Moore]

On 7 September 2016 at 22:31, Hugh Fisher  wrote:
> 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.

Reading the documentation should correct that mistaken expectation.

> Type annotations are code, not tests.

Not in Python they aren't.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Typecheckers: there can be only one

[Hugh Fisher]

On Wed, Sep 7, 2016 at 9:56 PM, Nick Coghlan  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/