Re: [Python-ideas] Proposal: Use mypy syntax for function annotations
I fully support formalizing Python 3's annotations for type checking. I wrote - and use daily - my own type checker called obiwan https://pypi.python.org/pypi/obiwan Its a runtime type checker, and if enabled will check and enforce types on every call. I support the wider adoption and standardization of static type checkers, but runtime checkers are still wanted for very dynamic code and for checking external data e.g. I use obiwan for validating JSON. One small detail is that I feel the obiwan annotations are more pythonic than the mypy examples given. E.g. instead of: from typing import List, Dict def word_count(input: List[str]) -> Dict[str, int]: ... It would be: def word_count(input: [str]) -> {str, int}: ... Obiwan does not check types within functions; I was unwilling to try and overload comments! You can invoke obiwan to check things explicitly, but these are more as assertions. Anyway, when I look at the mypy in-function annotations (where comments are overloaded) I am cautious. It would be far nicer if we had annotations as part of the language instead, e.g. instead of: result = {} #type: Dict[str, int] It would be: result = {} -> {str, int} where we use the -> arrow again. I can see pros and cons for any implementation (as we'd want the annotation to be both to declare a type and to check a type, and want the annotation to be attached to the variable forever etc) so this would need a full PEP treatment and possibly be configurable as asserts are. But proper annotation support in the language rather than overloading comments would definitely be my preference. /Will /Will
When discussed on reddit programming ("proggit" as its called), there were plenty of people saying they really didn't like the mypy syntax: http://www.reddit.com/r/programming/comments/2disob/proposal_for_python_type... (Declaration: I am the author of obiwan https://pypi.python.org/pypi/obiwan and I got a lot of upvotes on that proggit thread when I promoted the obiwan style instead) On 14 Aug 2014 13:16, "willvarfar@gmail.com" <willvarfar@gmail.com> wrote:
I fully support formalizing Python 3's annotations for type checking.
I wrote - and use daily - my own type checker called obiwan https://pypi.python.org/pypi/obiwan
Its a runtime type checker, and if enabled will check and enforce types on every call.
I support the wider adoption and standardization of static type checkers, but runtime checkers are still wanted for very dynamic code and for checking external data e.g. I use obiwan for validating JSON.
One small detail is that I feel the obiwan annotations are more pythonic than the mypy examples given.
E.g. instead of:
from typing import List, Dict
def word_count(input: List[str]) -> Dict[str, int]: ...
It would be:
def word_count(input: [str]) -> {str, int}: ...
Obiwan does not check types within functions; I was unwilling to try and overload comments! You can invoke obiwan to check things explicitly, but these are more as assertions.
Anyway, when I look at the mypy in-function annotations (where comments are overloaded) I am cautious. It would be far nicer if we had annotations as part of the language instead, e.g. instead of:
result = {} #type: Dict[str, int]
It would be:
result = {} -> {str, int}
where we use the -> arrow again. I can see pros and cons for any implementation (as we'd want the annotation to be both to declare a type and to check a type, and want the annotation to be attached to the variable forever etc) so this would need a full PEP treatment and possibly be configurable as asserts are.
But proper annotation support in the language rather than overloading comments would definitely be my preference.
/Will
/Will
On Sun, Aug 17, 2014 at 12:13:24PM +0200, willvarfar@gmail.com wrote:
When discussed on reddit programming ("proggit" as its called), there were plenty of people saying they really didn't like the mypy syntax:
http://www.reddit.com/r/programming/comments/2disob/proposal_for_python_type...
(Declaration: I am the author of obiwan https://pypi.python.org/pypi/obiwan and I got a lot of upvotes on that proggit thread when I promoted the obiwan style instead)
My thoughts on the obiwan style? Quicker, easier, more seductive. Easily they flow. But once you start down the dark path, forever will it dominate your destiny. *wink* Your example: [mypy] def word_count(input: List[str]) -> Dict[str, int]: [obiwan] def word_count(input: [str]) -> {str, int}: Now consider that annotations are just expressions. Inside or outside of a function parameter definition, Dict[str, int] is exactly the same thing: it's an abstract type. I should be able to use it at runtime: isinstance(x, word_count.__annotations__['return']) But obiwan's style (like the old Jedi himself) twists the truth around. The return annotation is only a type from a certain perspective, but in reality it is an instance of a concrete class, not an abstract class. It's not even a dict. {str, int} is a set, but obiwan uses it to represent a dict. (Although maybe that's a typo, and you meant to write {str: int}.) -- Steven
participants (3)
-
Greg Ewing -
Steven D'Aprano -
willvarfar＠gmail.com