[Python-ideas] PEP 484 (Type Hints) -- first draft round
abarnert at yahoo.com
Wed Jan 21 00:23:41 CET 2015
On Jan 20, 2015, at 14:57, Devin Jeanpierre <jeanpierreda at gmail.com> wrote:
> On Tue, Jan 20, 2015 at 3:06 AM, Steven D'Aprano <steve at pearwood.info> wrote:
>> On Tue, Jan 20, 2015 at 07:59:40PM +1300, Greg Ewing wrote:
>>> Stephen Hansen wrote:
>>>> Then you have decorators and
>>>> ... whatever you call that line? What's the difference?
>>> The difference is that the :: annotations would *not* be
>>> evaluated a run time. There's currently no way to get
>>> that with a decorator, or anything else in the language,
>>> short of abusing comments or string literals.
>>> Yet it's what you really want for static type checking.
>> Then I guess Python won't have static type checking.
>> I think Guido has been very clear that he has little interest at this
>> stage (if ever) about introducing a Java/Pascal/Haskell style statically
>> typed compiler to Python.
> Fortunately, Greg wasn't suggesting that. You seem to be
> misunderstanding the phrase "static type checker". It means something
> that checks types, statically. Like mypy. Greg's complaints make sense
> in that context (and I agree with him.)
As I understand it (and please correct me if I'm wrong), Greg is making a very simple point:
If type annotations are only for static type checking, as done by something like MyPy, they, by definition, have no use at runtime. But annotations are about storing information with functions at runtime. So the proposal is inherently storing useless information at runtime. (And it's also preventing anyone else from storing useful information there, but that's not the main issue.)
But I think there's a hole in the premise. Python's key strength is good debug-ability and amazingly powerful introspection. (I mean Python's _two_ key strengths are...) Information that has no runtime meaning to the interpreter may still have meaning to the user who's debugging code, or interactively exploring it. The fact that inspect.signature returns the parameter and return types is useful information to that user, even if there really is nothing you can do with it programmatically.
You could ask why not just always use strings for the annotations. After all, MyPy obviously already has to be able to handle that, and to a human debugging the code and printing out the annotation there's no real difference. But the reason there is pretty obvious: the quotes are extra characters that get in the way of reading the function definition, and 90% of the time they're unnecessary. Think of being able to use a compile-time expression instead of an equivalent string as syntactic sugar--not necessary, but still nice.
More information about the Python-ideas