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

[Guido van Rossum]

On Thu, Jan 22, 2015 at 8:45 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> On 1/22/2015 3:05 PM, Guido van Rossum wrote:
>
>> Having got that off my mind, the vast majority of Python code that's
>> been written does not use annotations at all, so there is no reason to
>> change it at all. For code that does use annotation, *nothing* will
>> break at run time -- the code will work unchanged, without any
>> deprecations or slowdowns.
>>
>> The only situation where there may be a desire to change something (the
>> minimal thing being to add a "# type: OFF" comment at the top of a
>> module) is when a library that uses annotations for non-type-hinting
>> purposes is used by an application (or another library) that wants to
>> use type hints, and the user who is running the type checker cannot live
>> with the noise output spewed by the type checker for that library.
>>
>
> I believe the dual-use of annotations problem would be solved if static
> type checkers gave precedence to annotations in stub files.  Putting type
> hints in separate files is *possible* because static checkers do not need
> and will not use a runtime .__annotations__ attribute.  If the presence of
> a stub file meant that annotations in the corresponding .py file were
> ignored by static checkers, then they could still be used in .py files to
> create .__annotations__ for dynamic use.
>

Correct -- if a stub exists the checker should not look at the actual
source code at all. (The current PEP draft is light on stubs but we know we
need to fix this. Patches welcome!)


> I think typing should have a make_stub(inpy, outstub) function to make
> blank stub creation easy.  It would copy all def headers and add ':' and
> '->' where appropriate.  It could have an any=??? option which, when true,
> would add 'any' everywhere.  Running typing as a script (-m) could run
> make_stub.  An all-any stub would eliminate the need even for #type:off,
> and could be added by a user without touching the .py file.
>

That sounds like a useful tool, but why should it be in typing.py? It
shouldn't be needed at run time -- if the code is being run, the stub isn't
needed, and if the code is being type-checked, the code won't be run so the
stub won't be generated.


> I think putting type hints in stub files should be documented as at least
> on a par, if not encouraged, with putting them in .py files.
>

On a par. Stubs are essential for extension modules, and nearly essential
for existing packages (both 3rd party and the stdlib!). But I don't want
people writing new 3.x code having to deal with two files for every module.
I've recently had to do this for C++ and the endless back-and-forth between
.hpp and .cpp files (and the subtleties of what is allowed/required in each
type of file) drove me nuts.


> 1. As with writing tests, only a subset of python programmers will enjoy,
> be willing to, and be good at writing complex type hints.  So stub files
> might be writtin by someone

other than the .py author(s).
>

Yes, especially for existing libraries that is very useful.


> 2. In some cases, type hints intended to be as accurate as possible will
> not be pretty -- or simple.  In a separate file intended for machine
> consumption, aesthetics can more easily be ignored in favor of accuracy.
>

Hm, I'm skeptical about that. We're not writing Haskell types here. Most
type hints are very bread-and-buttery things.


> 3. Users may want to add or customize annotations (perhaps to narrow the
> allowed arguments to conform to policy).  This is better done in a separate
> file.
>

I don't understand this part. Can you clarify, maybe give an example?

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150122/ef36f82a/attachment-0001.html>