4 ms·

Actually type hinting was released with 3.5. I've been using it for a while now, and while there's occasional bugs, I love it (I was able to crash my program at

Actually type hinting was released with 3.5. I've been using it for a while now, and while there's occasional bugs, I love it (I was able to crash my program at runtime because of a type declaration, which isn't supposed to happen). The difference here is the ability to add type annotations to variables without needing to use a comment to declare it. I'm also pretty excited for the formatted string literals and secrets module! https://docs.python.org/3.6/whatsnew/3.6.html https://docs.python.org/3.6/whatsnew/3.6.html

happy-go-lucky 10y ago
Interesting. https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/ > It should also be emphasized that Python will remain a dynamically typed language, and the authors have no desire to ever make type hints mandatory, even by convention.
- squeaky-clean 10y ago
  Yeah, the typing (in theory) makes no actual changes to the runtime code. It's just for linters like mypy to warn you when you write code that goes against your own type declarations. However because it's added directly into your code, it does have a slight runtime effect. Casting types calls a function (which should just be a no-op function), as well as defining TypeVars. The crashes I got at runtime aren't because of the typing module preventing code from running due to types, it was just a bug in the runtime part of typing. I'll try to find the github issue to share, but iirc it was related to using Generics with a TypeVar.
  - happy-go-lucky 10y ago
    OK. I'm wondering if this captain: str # Note: no initial value! changes the norm: Python's names don't have associated types but values do. I know there's no such thing as variable declaration and variable initialization in Python.
    - masklinn 10y ago
      > I know there's no such thing as variable declaration and variable initialization in Python. That is not quite true, the first assignment is an implicit declaration, and will set up a slot in the enclosing code object, which is why you get an UnboundLocalError if you use a name before it's first assigned to: >>> def foo(): ... a ... a = 3 ... >>> foo() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in foo UnboundLocalError: local variable 'a' referenced before assignment but a NameError if you use a name which is not assigned to at all: >>> def foo(): ... a ... >>> foo() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in foo NameError: name 'a' is not defined In the latter case the slot doesn't exist at all in the lexical context, while in the former there is a slot set up but it has no value associated to it.
      - happy-go-lucky 10y ago
        I agree, but these are problems with Python's implicit variable declaration.
        masklinn 10y ago
        That's orthogonal to my demonstration that there is in fact "such a thing as variable declaration and initialisation in Python", given that the cases of an undeclared variable and a declared but unassigned to variable both exist with very different errors.
    - squeaky-clean 10y ago
      It doesn't affect runtime at all (except when it does :P, but that's a bug). So there is a difference between what's valid in mypy, and what's valid in "real" Python. Typing does associate type with the names as well, which isn't necessary for legal Python (but is often cleaner). For example, mypy will yell at you if you do something like this: def add_week_to_day(d: str) -> str: # d arrives as an ISO string, like '2016-12-23' d = datetime.strptime(d, '%Y-%m-%d') d = d + timedelta(days=7) return d.strftime('%Y-%m-%d') Because d was original defined as a str, and now I'm re-using it as a datetime. This is of course perfectly valid Python, and will work at runtime. But mypy prefers you use a different name for the different types.

happy-go-lucky 10y ago

Interesting. https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/ > It should also be emphasized that Python will remain a dynamically typed language, and the authors have no desire to ever make type hints mandatory, even by convention.

squeaky-clean 10y ago
Yeah, the typing (in theory) makes no actual changes to the runtime code. It's just for linters like mypy to warn you when you write code that goes against your own type declarations. However because it's added directly into your code, it does have a slight runtime effect. Casting types calls a function (which should just be a no-op function), as well as defining TypeVars. The crashes I got at runtime aren't because of the typing module preventing code from running due to types, it was just a bug in the runtime part of typing. I'll try to find the github issue to share, but iirc it was related to using Generics with a TypeVar.
- happy-go-lucky 10y ago
  OK. I'm wondering if this captain: str # Note: no initial value! changes the norm: Python's names don't have associated types but values do. I know there's no such thing as variable declaration and variable initialization in Python.
  - masklinn 10y ago
    > I know there's no such thing as variable declaration and variable initialization in Python. That is not quite true, the first assignment is an implicit declaration, and will set up a slot in the enclosing code object, which is why you get an UnboundLocalError if you use a name before it's first assigned to: >>> def foo(): ... a ... a = 3 ... >>> foo() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in foo UnboundLocalError: local variable 'a' referenced before assignment but a NameError if you use a name which is not assigned to at all: >>> def foo(): ... a ... >>> foo() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in foo NameError: name 'a' is not defined In the latter case the slot doesn't exist at all in the lexical context, while in the former there is a slot set up but it has no value associated to it.
    - happy-go-lucky 10y ago
      I agree, but these are problems with Python's implicit variable declaration.
      - masklinn 10y ago
        That's orthogonal to my demonstration that there is in fact "such a thing as variable declaration and initialisation in Python", given that the cases of an undeclared variable and a declared but unassigned to variable both exist with very different errors.
  - squeaky-clean 10y ago
    It doesn't affect runtime at all (except when it does :P, but that's a bug). So there is a difference between what's valid in mypy, and what's valid in "real" Python. Typing does associate type with the names as well, which isn't necessary for legal Python (but is often cleaner). For example, mypy will yell at you if you do something like this: def add_week_to_day(d: str) -> str: # d arrives as an ISO string, like '2016-12-23' d = datetime.strptime(d, '%Y-%m-%d') d = d + timedelta(days=7) return d.strftime('%Y-%m-%d') Because d was original defined as a str, and now I'm re-using it as a datetime. This is of course perfectly valid Python, and will work at runtime. But mypy prefers you use a different name for the different types.