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

[Guido van Rossum]

On Thu, Jan 22, 2015 at 7:10 AM, Ed Kellett <edk141 at gmail.com> wrote:

> On Thu Jan 22 2015 at 14:53:56 Brett Cannon <brett at python.org> wrote:
>>
>> If you read one of Ed's earlier emails it sounds like he thinks you need
>> the @no_type_hints decorator even if you don't provide *any* annotations,
>> which is incorrect (the decorator is only to signal that annotations you
>> did specify  are not type hints; not specifying any annotations signals the
>> same thing). Heck, the decorator isn't even technically necessary if the
>> linter or IDE you are using that can process the type hints chooses to
>> treat unrecognized annotations as Any instead of throwing an error or
>> something.
>>
>
> I feel like I've been significantly misunderstood. To be clear, I'm
> talking about using @no_type_checks or whatever the decorator is called for
> code I have that *already uses annotations*.
>

Or you could just refrain from running the type checker. The checker is not
built into CPython. It will be a separate program, run voluntarily, that
points out issues, just like a linter. Support you run the pep8 program (a
linter mostly for whitespace and naming conventions) and it tells you that
your lines are longer than 79 chars. What are you going to do? Reformat
your code to fit? You could, but nobody will force you. You could just
ignore those warnings, or change pep8's configuration file to disable that
message, or just *not run pep8 at all*. SImilar for other linters (e.g.
pyflakes, pylint) that point out more substantial issues such as unused or
undefined variables.

Type checking will either fail, or become ubiquitous to the point that
> passing type checking is a prerequisite to being considered "good" for any
> Python module. Should the latter happen, I'll have to break my code for
> past or future Python versions, no?
>

I doubt that is how it will work out. There's a reason we call it *Gradual
typing*. You as a Python developer (or a team of collaborating developers
for a given project) can choose where you think you will benefit from
getting parts of your code type-checked, and where you don't think it is
worth it.

Again, this is the same as for linting tools. When you're writing a
half-hour hack to scrape your old mailbox, you're probably not going to
care about a type checker (you run your script and fix it until it works,
and then you move on).

When you're planning to write a 100,000 line application over a year's time
with a team of six programmers you might agree that your code follows the
strictest style guides, passes a linter with zero warnings, or, in the
future, that it type-checks without warnings. (You should probably also
agree on unit testing and integration testing. And you need a code review
process. And revision control. But I digress.)

If you're in the latter situation there are usually some compromises you
have to make -- e.g. your team may not all agree on the line length, but
it's better to pick one and stick to it than to continually bicker about
it. Similar for type hints -- you may have to agree on how important they
are for your project and and adjust your habits accordingly.


> Personally, I'd like to believe that this proposal and the echochamber
> that's surrounded it has all been just a bad dream, but given that it's
> almost certainly going to make it into Python at this point, it'd be nice
> not to have to make good code bad just to maintain compatibility with it.
>

This paragraph (and a some words you wrote earlier) feels really offensive
to me. I am doing the best I can. I have listened to an *enormous* amount
of feedback and if you read back earlier discussions (going back to I
believe September or October 2014) or skim the typehinting issue tracker
<https://github.com/ambv/typehinting/issues> you'll find that I am taking
the feedback very seriously.

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.

Even there, the problem could also be solved by having a way to configure
the type checker to ignore annotations in certain packages (or to only
check code in specific directories).


> Since type hints already depend on the 'typing' module anyway, what
> exactly would be wrong with the type checker defaulting off unless it is
> imported?
>

I've considered that, but I find it limiting. It is quite likely that a
module can be fully annotated with type hints without ever needing to
reference the typing module. For example, all argument types may be simple
built-in types (strings and numbers) or user-defined classes. I think it
would be unexpected if type hints that were present in a module would be
ignored by the type checker unless the typing module was imported. (Also,
perhaps ironically, most linters will complain about modules that are
imported but not used. :-)

But this is an area where we may be able to cater to different preferences
by passing the type checker different flags or configurations. So I don't
want to make a big thing out of this, and if people think it's useful, this
can well be an option.

Finally. In the distant future there may be more agreement about the use of
annotations for type hints, and users will start asking library authors to
change their code. But that's no different than other evolution of the
language -- it won't happen overnight, you will get ample warning
(DeprecationWarning :-), and the principle of supply and demand will apply.
Heck, if you're not using Python 3, you're safe until 2020.

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