Type hinting for Python [LWN.net]

Type hinting for Python

Posted Dec 25, 2014 0:41 UTC (Thu) by josh (subscriber, #17465) [Link] (4 responses)

I agree; given that Python already has syntax for annotating function arguments, why not just add syntax to annotate the LHS of an expression? For instance:

a: Dict[str, str] = {}

To the best of my knowledge, that wouldn't conflict with anything.

Type hinting for Python

Posted Dec 26, 2014 4:22 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (3 responses)

This would require new syntax and therefore be backwards incompatible. Personally, I'd rather docstrings or expression decorators, but I've become so jaded with Python I find it hard to care too much what they do with 3.5 since I'm still fighting to get to 3.0.

Type hinting for Python

Posted Dec 26, 2014 6:06 UTC (Fri) by josh (subscriber, #17465) [Link] (2 responses)

> This would require new syntax and therefore be backwards incompatible.

As in, code written to use types would not work with Python pre-3.5?

That really doesn't seem like a problem. Plenty of code currently requires 2.7 and won't work with 2.6, for instance.

Type hinting for Python

Posted Dec 27, 2014 3:28 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (1 responses)

Python has gotten a lot of flak for breaking compatibility already and it seems they're taking further steps in that direction carefully which I prefer to "eh, you should use the latest anyways". Not everyone has such a luxury :( .

Type hinting for Python

Posted Dec 29, 2014 18:14 UTC (Mon) by iabervon (subscriber, #722) [Link]

Changes where some files that previously would have given syntax errors now don't aren't really a big deal; what they've gotten flak for is changes where files that were previously valid don't do the same thing or are invalid.

In fact, they're technically breaking compatibility more with the comment mechanism, in that a file with comments that are close to being type declarations but aren't quite right for this system will presumably generate whatever effects type mismatches end up having (mitigated somewhat by the fact that doing anything with the annotations won't happen without a proactive step).

Type hinting for Python

Posted Dec 25, 2014 0:46 UTC (Thu) by proski (subscriber, #104) [Link] (3 responses)

I agree. Comments are comments - they are highlighted in a specific way, they are seen as a message from the code author to the human reading the code. It should be possible to declare the type of a variable and comment on its purpose, on the same line.

Code in comments, really?

Posted Dec 25, 2014 1:07 UTC (Thu) by marcH (subscriber, #57642) [Link]

> Comments are comments - they are highlighted in a specific way, they are seen as a message from the code author to the human reading the code.

If only humans were the only potential problem. A lot of "meta" development tools (editors, IDEs, etc.) read comments too. Imagine their confusion now.

Code in comments, what an horror. Not familiar enough with Python for this question, but isn't there some concept of "annotations" as a much better solution here?

Type hinting for Python

Posted Dec 25, 2014 8:47 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

You have to wonder what is so special about this language feature that it has to rely on magic comments, while many other (arguably more significant) language changes to Python have been made in the core language, introducing a backwards-incompatible change if necessary. And what happens when the next language change is considered?

Type hinting for Python

Posted Jan 2, 2015 0:52 UTC (Fri) by smitty_one_each (subscriber, #28989) [Link]

The 'special' nature of it is that Python is trying to have it many ways:
- stay totally dynamic, and not need any type hinting
- don't create incompatibilities
- allow types in for those keen on the feature
Python is a great tool, and the BDFL will settle on something.

Type hinting for Python

Posted Dec 29, 2014 23:40 UTC (Mon) by debacle (subscriber, #7114) [Link]

Same here. I'ld rather accept an incompatible language change than abusing comments for type declaration. At least, backporting such code to Python < 3.5whatever would only mean to remove the declaration. Similar to backporting ANSI C code to K&R.