6 ms·

> I also find it kind of hilarious that type checking isn't built into the standard python interpreter, but you need a separate tool instead. Agreed, typically

> I also find it kind of hilarious that type checking isn't built into the standard python interpreter, but you need a separate tool instead. Agreed, typically you don't add new syntax to a language only to silently ignore it. I think the plan may be to add runtime checking to the Python interpreter later.

bsenftner 4y ago
> I think the plan may be to add runtime checking to the Python interpreter later. And slow the run time back down several versions.
- flohofwoe 4y ago
  I don't think people select Python for it's performance ;) But the type-checking could be a command line parameter, used only during development.
  - mfgs 4y ago
    It already can be used for development, IDEs such as PyCharm perform quite effective live type checking based on type hints.
    - Jasper_ 4y ago
      Note that PyCharm and mypy's semantics differ in some key ways: https://youtrack.jetbrains.com/issue/PY-54411/Type-checkers-should-move-towards-requiring-the-optional-type-to-be-made-explicit https://youtrack.jetbrains.com/issue/PY-54411/Type-checkers-.... https://youtrack.jetbrains.com/issue/PY-24834/Support-stricter-handling-of-typing.Union-types-similar-to-that-in-mypy https://youtrack.jetbrains.com/issue/PY-24834/Support-strict...
- gpderetta 4y ago
  Usually static types allow for better optimizations, but this is python, so the implementation is probably maximally pessimal.
  - MrJohz 4y ago
    My understanding is that the relationship is a lot more complex than "types = faster code". Types are often necessary for highly efficient code, yes, because the allow you to avoid lots of indirection and just give the hardware the raw numbers and instructions that it wants. But they aren't sufficient - you can't just have types, you also need to guarantee that those types are always the correct ones (i.e. that when I tell you it's an int, it will never be a string). In practice, the performance gains you get from using types are matched by the performance losses from having to validate them. You can solve this by restricting What's possible significantly (you see this, for example, in RPython and Cython, where static types are used more effectively, but come with significant metaprogramming restrictions). But at that point, you're losing a lot of the value of a dynamic language. One of the big reasons that Typescript works so well here is that it has all sorts of escape hatches, so that you can write mostly correct Typescript code, but if you need to write something completely dynamic, you can always just define the arguments and return types and cast everything else to `any`. This is why, even though Cython exists and is much quicker than Python, it tends to only be used to speed up specific sections of code, with the rest of the codebase being dynamic Python glue. The other side of this is that there already is a solution to performance issues in dynamic languages, and that's JIT compilation. Javascript is consistently one of the faster languages for lots of web tasks, and that's in no small part due to the significant effort put into optimising V8 and the other JIT runtimes. The best thing about JIT compilation is that you don't need to write the types at all, because the type information can be read at runtime. Theoretically, you could incorporate type hints into the optimisation process, but this probably won't give as much good information as actually running the code and seeing what types pop out. Of course, the other side of this is to ask what the value of type hints are in the first place. I think a lot of Python developers are used to things like Cython, where types almost exclusively refer to the underlying data formats (i8, i32, u64 etc), but the biggest value to type hints and tools like mypy is not just defining struct layouts, but describing a program's behaviour at a higher level - for example, declaring that a variable can be one of these two types and ensuring that the developer never forgets that. Or defining a closeable resource like a file handle that can't be used after it's been closed. Or making sure that the developer handles each case of an enumeration and doesn't miss anything. The types that are useful for those sorts of things tend not to be so useful for optimisation purposes, but they are _very_ useful for ensuring that code is semantically correct.
codethief 4y ago
> Agreed, typically you don't add new syntax to a language only to silently ignore it. The only new syntax here is variable and function annotations and it allows you to put anything into the annotation, so it makes sense the compiler would ignore them. Type hints are one possible usage of such annotations but they are not part of the syntax (because the types are just regular Python objects).
Jasper_ 4y ago
The reason is that the community decided they needed some form of type annotations, but nobody could agree on which ones or how they should work. So some syntax was added just so the parser wouldn't fall over, but the semantics were left to other projects to "let 100 flowers bloom". This worked about as predictably as you would expect. If you grabbed a random package from pypi, suddenly your choice in typechecker might complain about its API if it wasn't made using the same typechecker as you, so a separate, "standard" choice in typechecking was made called mypy. But they couldn't break older code not using mypy so it's strictly optional.
- uranusjr 4y ago
  > so a separate, "standard" choice in typechecking was made called mypy This distorts reality a bit. Mypy is one of the flowers; Jukka developed the annotation syntax. It got popular enough to become the de facto standard. I would say the strategy worked.

bsenftner 4y ago

> I think the plan may be to add runtime checking to the Python interpreter later. And slow the run time back down several versions.

flohofwoe 4y ago
I don't think people select Python for it's performance ;) But the type-checking could be a command line parameter, used only during development.
- mfgs 4y ago
  It already can be used for development, IDEs such as PyCharm perform quite effective live type checking based on type hints.
  - Jasper_ 4y ago
    Note that PyCharm and mypy's semantics differ in some key ways: https://youtrack.jetbrains.com/issue/PY-54411/Type-checkers-should-move-towards-requiring-the-optional-type-to-be-made-explicit https://youtrack.jetbrains.com/issue/PY-54411/Type-checkers-.... https://youtrack.jetbrains.com/issue/PY-24834/Support-stricter-handling-of-typing.Union-types-similar-to-that-in-mypy https://youtrack.jetbrains.com/issue/PY-24834/Support-strict...
gpderetta 4y ago
Usually static types allow for better optimizations, but this is python, so the implementation is probably maximally pessimal.
- MrJohz 4y ago
  My understanding is that the relationship is a lot more complex than "types = faster code". Types are often necessary for highly efficient code, yes, because the allow you to avoid lots of indirection and just give the hardware the raw numbers and instructions that it wants. But they aren't sufficient - you can't just have types, you also need to guarantee that those types are always the correct ones (i.e. that when I tell you it's an int, it will never be a string). In practice, the performance gains you get from using types are matched by the performance losses from having to validate them. You can solve this by restricting What's possible significantly (you see this, for example, in RPython and Cython, where static types are used more effectively, but come with significant metaprogramming restrictions). But at that point, you're losing a lot of the value of a dynamic language. One of the big reasons that Typescript works so well here is that it has all sorts of escape hatches, so that you can write mostly correct Typescript code, but if you need to write something completely dynamic, you can always just define the arguments and return types and cast everything else to `any`. This is why, even though Cython exists and is much quicker than Python, it tends to only be used to speed up specific sections of code, with the rest of the codebase being dynamic Python glue. The other side of this is that there already is a solution to performance issues in dynamic languages, and that's JIT compilation. Javascript is consistently one of the faster languages for lots of web tasks, and that's in no small part due to the significant effort put into optimising V8 and the other JIT runtimes. The best thing about JIT compilation is that you don't need to write the types at all, because the type information can be read at runtime. Theoretically, you could incorporate type hints into the optimisation process, but this probably won't give as much good information as actually running the code and seeing what types pop out. Of course, the other side of this is to ask what the value of type hints are in the first place. I think a lot of Python developers are used to things like Cython, where types almost exclusively refer to the underlying data formats (i8, i32, u64 etc), but the biggest value to type hints and tools like mypy is not just defining struct layouts, but describing a program's behaviour at a higher level - for example, declaring that a variable can be one of these two types and ensuring that the developer never forgets that. Or defining a closeable resource like a file handle that can't be used after it's been closed. Or making sure that the developer handles each case of an enumeration and doesn't miss anything. The types that are useful for those sorts of things tend not to be so useful for optimisation purposes, but they are _very_ useful for ensuring that code is semantically correct.

codethief 4y ago

> Agreed, typically you don't add new syntax to a language only to silently ignore it. The only new syntax here is variable and function annotations and it allows you to put anything into the annotation, so it makes sense the compiler would ignore them. Type hints are one possible usage of such annotations but they are not part of the syntax (because the types are just regular Python objects).

Jasper_ 4y ago

The reason is that the community decided they needed some form of type annotations, but nobody could agree on which ones or how they should work. So some syntax was added just so the parser wouldn't fall over, but the semantics were left to other projects to "let 100 flowers bloom". This worked about as predictably as you would expect. If you grabbed a random package from pypi, suddenly your choice in typechecker might complain about its API if it wasn't made using the same typechecker as you, so a separate, "standard" choice in typechecking was made called mypy. But they couldn't break older code not using mypy so it's strictly optional.

uranusjr 4y ago
> so a separate, "standard" choice in typechecking was made called mypy This distorts reality a bit. Mypy is one of the flowers; Jukka developed the annotation syntax. It got popular enough to become the de facto standard. I would say the strategy worked.