6 ms·

I don't get how this optional static typing works. I had a quick look at [1], and it begins with a note saying that Python's runtime doesn't enforce types, leav

by GTP 2y ago

I don't get how this optional static typing works. I had a quick look at [1], and it begins with a note saying that Python's runtime doesn't enforce types, leaving the impression that you need to use third-party tools to do actual type checking. But then it continues just like Python does the check. Consider that I'm not a Python programmer, but the main reason I stay away from it is the lack of a proper type system. If this is going to change, I might reconsider it. [1] https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html

deleted 2y ago
[deleted]
wk_end 2y ago
The interpreter does not and probably never will check types. The annotations are treated as effectively meaningless at runtime. External tools like mypy can be run over your code and check them.
- cwalv 2y ago
  It checks types .. it doesn't check type annotations. Just try: $ Python >>> 1 + '3'
davepeck 2y ago
Third party tools (mypy, pyright, etc) are expected to check types. cpython itself does not. This will run just fine: python -c "x: int = 'not_an_int'" My opinion is that with PEP 695 landing in Python 3.12, the type system itself is starting to feel robust. These days, the python ecosystem's key packages all tend to have extensive type hints. The type checkers are of varying quality; my experience is that pyright is fast and correct, while mypy (not having the backing of a Microsoft) is slower and lags on features a little bit -- for instance, mypy still hasn't finalized support for PEP 695 syntax.
zitterbewegung 2y ago
Optional static typing is just like a comment (real term is annotation) of the input variable(s) and return variable(s). No optimization is performed. Using a tool such as mypy that kicks off on a CI/CD process technically enforces types but they are ignored by the interpreter unless you make a syntax error.
- nine_k 2y ago
  A language server in your IDE kicks in much earlier, and is even more helpful.
  - zitterbewegung 2y ago
    I haven't used an IDE that has that but it is still just giving you a hint that there is an error and the interpreter is not throwing an error which was my point.
    - kortex 2y ago
      That's true of most compiled languages. Unless we are talking about asserts, reflection, I think type erasure, and maybe a few other concepts, language runtimes don't check types. C does not check types at runtime. You compile it and then rely on control of invariants and data flow to keep everything on rails. In python, this is tricky because everything is behind at least one layer of indirection, and thus virtually everything is mutable, so it's hard to enforce total control of all data structures. But you can get really close with modern tooling.
      - cwalv 2y ago
        >> and the interpreter is not throwing an error which was my point. > That's true of most compiled languages True of most statically typed languages (usually no need to check at runtime), but not true in Python or other dynamically typed languages. Python would have been unusable for decades (prior to typehints) if that was true.
sveiss 2y ago
The parser supports the type hint syntax, and the standard library provides various type hint related objects. So you can do things like “from typing import Optional” to bring Optional into scope, and then annotate a function with -> Optional[int] to indicate it returns None or an int. Unlike a system using special comments for type hints, the interpreter will complain if you make a typo in the word Optional or don’t bring it into scope. But the interpreter doesn’t do anything else; if you actually return a string from that annotated function it won’t complain. You need an external third party tool like MyPy or Pyre to consume the hint information and produce warnings. In practice it’s quite usable, so long as you have CI enforcing the type system. You can gradually add types to an existing code base, and IDEs can use the hint information to support code navigation and error highlighting.
- quotemstr 2y ago
  > In practice it’s quite usable It would be super helpful if the interpreter had a type-enforcing mode though. All the various external runtime enforcement packages leave something to be desired.
  - setopt 2y ago
    I agree. There are usable third-party runtime type checkers though. I like Beartype, which lets you add a decorator @beartype above any function or method, and it’ll complain at runtime if arguments or return values violate the type hints. I think runtime type checking is in some ways a better fit for a highly dynamic language like Python than static type checking, although both are useful.
nine_k 2y ago
At MPOW most Python code is well-type-hinted, and mypy and pyright are very helpful at finding issues, and also for stuff like code completion and navigation, e.g. "go to the definition of the type of this variable". Works pretty efficiently. BTW, Typescript also does not enforce types at runtime. Heck, C++ does not enforce types at runtime either. It does not mean that their static typing systems don't help during at development time.
- GTP 2y ago
  > BTW, Typescript also does not enforce types at runtime. Heck, C++ does not enforce types at runtime either. It does not mean that their static typing systems don't help during at development time. Speaking of C here as I don't have web development experience. The static type system does help, but in this case, it's the compiler doing the check at compile time to spare you many surprises at runtime. And it's part of the language's standard. Python itself doesn't do that. Good that you can use external tools, but I would prefer if this was part of Python's spec. Edit: these days I'm thinking of having a look at Mojo, it seems to do what I would like from Python.
  - kortex 2y ago
    https://github.com/python/mypy https://github.com/python/mypy > Python itself doesn't do that The type syntax is python. MyPy is part of Python. It's maintained by the python foundation. Mypy is not part of CPython because modularity is good, the same way that ANSI C doesn't compile anything, that's what gcc, clang, etc are for. Mojo is literally exactly the same way, the types are optional, and the tooling handles type checking and compilation.
    - GTP 2y ago
      > Mojo is literally exactly the same way. No, because in Mojo, type checking is part of the language specification: you need no external tool for that. Python defines a syntax that can be used for type checking, but you need an external tool to do that. GCC does type checking because it's defined in the language specification. You would have a situation analogous to Python only if you needed GCC + some other tool for type checking. This isn't the case.
VeejayRampay 2y ago
python will never be "properly typed" what it has is "type hints" which is way to have richer integration with type checkers and your IDE, but will never offer more than that as is
- hot_gril 2y ago
  It is properly typed: it has dynamic types :)
  - GTP 2y ago
    Then we have very different ideas of what proper typing is :D Look at this function, can you tell me what it does? def plus(x, y): return x+y If your answer is among the lines of "It returns the sum x and y" then I would ask you who said that x and y are numbers. If these are strings, it concatenates them. If instead you pass a string and a number, you will get a runtime exception. So not only you can't tell what a function does just by looking at it, you can't even know if the function is correct (in the sense that will not raise an exception).
    - hot_gril 2y ago
      When is the last time you had a bug IRL caused by passing the wrong kind of thing into plus(x, y), which your tests didn't catch?
      - GTP 2y ago
        It never happened to me, because I don't use Python ;) On a more serious note, your comment actually hints at an issue: unit testing is less effective without static type checking. Let's assume I would like to sum x and y. I can extensively test the function and see that it indeed correctly sums two numbers. But then I need to call the function somewhere in my code, and whether it will work as intended or not depends on the context in which the function is used. Sometimes the input you pass to a function depends from some external source outside your control, an if that's the case you have to resort to manual type checking. Or use a properly typed language.
hot_gril 2y ago
I think static typing is a waste of time, but given that you want it, I can see why you wouldn't want to use Python. Its type-checking is more half-baked and cumbersome than other languages, even TS.
- baq 2y ago
  Typescript is pretty much the gold standard, it’s amazing how much JavaScript madness you can work around just on the typechecking level. IMHO Python should shamelessly steal as much typescript’s typing as possible. It’s tough since the Microsoft typescript team is apparently amazing at what they do so for now it’s a very fast moving target but some day…
  - hot_gril 2y ago
    Well the TS tooling is more painful in ways. It's not compatible with some stuff like the NodeJS profiler. Also there's some mess around modules vs "require" syntax that I don't understand fully but TS somehow plays a role.
- GTP 2y ago
  I instead think that the lack of static typing is a waste of time, since without it you can have programs that waste hours of computation due to an exception that would have been prevented by a proper type system ;)
- nine_k 2y ago
  I used to think like that until I tried. There are areas where typing is more important: public interfaces. You don't have to make every piece of your program well-typed. But signatures of your public functions / methods matter a lot, and from them types of many internal things can be inferred. If your code has a well-typed interface, it's pleasant to work with. If interfaces of the libraries you use are well-typed, you have easier time writing your code (that interacts with them). Eventually you type more and more code you write and alter, and keep reaping the benefits.
  - 2y ago
NegativeK 2y ago
Python's typing must accommodate Python's other goal as quick scripting language. The solution is to document the optional typing system as part of the language's spec and let other tools do the checking, if a user wants to use them. The other tools are trivially easy to set up and run (or let your IDE run for you.) As in, one command to install, one command to run. It's an elegant compromise that brings something that's sorely needed to Python, and users will spend more time loading the typing spec in their browser than they will installing the type checker.

by GTP 2y ago

deleted 2y ago

[deleted]

wk_end 2y ago

The interpreter does not and probably never will check types. The annotations are treated as effectively meaningless at runtime. External tools like mypy can be run over your code and check them.

cwalv 2y ago
It checks types .. it doesn't check type annotations. Just try: $ Python >>> 1 + '3'

davepeck 2y ago

Third party tools (mypy, pyright, etc) are expected to check types. cpython itself does not. This will run just fine: python -c "x: int = 'not_an_int'" My opinion is that with PEP 695 landing in Python 3.12, the type system itself is starting to feel robust. These days, the python ecosystem's key packages all tend to have extensive type hints. The type checkers are of varying quality; my experience is that pyright is fast and correct, while mypy (not having the backing of a Microsoft) is slower and lags on features a little bit -- for instance, mypy still hasn't finalized support for PEP 695 syntax.

zitterbewegung 2y ago

Optional static typing is just like a comment (real term is annotation) of the input variable(s) and return variable(s). No optimization is performed. Using a tool such as mypy that kicks off on a CI/CD process technically enforces types but they are ignored by the interpreter unless you make a syntax error.

nine_k 2y ago
A language server in your IDE kicks in much earlier, and is even more helpful.
- zitterbewegung 2y ago
  I haven't used an IDE that has that but it is still just giving you a hint that there is an error and the interpreter is not throwing an error which was my point.
  - kortex 2y ago
    That's true of most compiled languages. Unless we are talking about asserts, reflection, I think type erasure, and maybe a few other concepts, language runtimes don't check types. C does not check types at runtime. You compile it and then rely on control of invariants and data flow to keep everything on rails. In python, this is tricky because everything is behind at least one layer of indirection, and thus virtually everything is mutable, so it's hard to enforce total control of all data structures. But you can get really close with modern tooling.
    - cwalv 2y ago
      >> and the interpreter is not throwing an error which was my point. > That's true of most compiled languages True of most statically typed languages (usually no need to check at runtime), but not true in Python or other dynamically typed languages. Python would have been unusable for decades (prior to typehints) if that was true.

sveiss 2y ago

The parser supports the type hint syntax, and the standard library provides various type hint related objects. So you can do things like “from typing import Optional” to bring Optional into scope, and then annotate a function with -> Optional[int] to indicate it returns None or an int. Unlike a system using special comments for type hints, the interpreter will complain if you make a typo in the word Optional or don’t bring it into scope. But the interpreter doesn’t do anything else; if you actually return a string from that annotated function it won’t complain. You need an external third party tool like MyPy or Pyre to consume the hint information and produce warnings. In practice it’s quite usable, so long as you have CI enforcing the type system. You can gradually add types to an existing code base, and IDEs can use the hint information to support code navigation and error highlighting.

quotemstr 2y ago
> In practice it’s quite usable It would be super helpful if the interpreter had a type-enforcing mode though. All the various external runtime enforcement packages leave something to be desired.
- setopt 2y ago
  I agree. There are usable third-party runtime type checkers though. I like Beartype, which lets you add a decorator @beartype above any function or method, and it’ll complain at runtime if arguments or return values violate the type hints. I think runtime type checking is in some ways a better fit for a highly dynamic language like Python than static type checking, although both are useful.

nine_k 2y ago

At MPOW most Python code is well-type-hinted, and mypy and pyright are very helpful at finding issues, and also for stuff like code completion and navigation, e.g. "go to the definition of the type of this variable". Works pretty efficiently. BTW, Typescript also does not enforce types at runtime. Heck, C++ does not enforce types at runtime either. It does not mean that their static typing systems don't help during at development time.

GTP 2y ago
> BTW, Typescript also does not enforce types at runtime. Heck, C++ does not enforce types at runtime either. It does not mean that their static typing systems don't help during at development time. Speaking of C here as I don't have web development experience. The static type system does help, but in this case, it's the compiler doing the check at compile time to spare you many surprises at runtime. And it's part of the language's standard. Python itself doesn't do that. Good that you can use external tools, but I would prefer if this was part of Python's spec. Edit: these days I'm thinking of having a look at Mojo, it seems to do what I would like from Python.
- kortex 2y ago
  https://github.com/python/mypy https://github.com/python/mypy > Python itself doesn't do that The type syntax is python. MyPy is part of Python. It's maintained by the python foundation. Mypy is not part of CPython because modularity is good, the same way that ANSI C doesn't compile anything, that's what gcc, clang, etc are for. Mojo is literally exactly the same way, the types are optional, and the tooling handles type checking and compilation.
  - GTP 2y ago
    > Mojo is literally exactly the same way. No, because in Mojo, type checking is part of the language specification: you need no external tool for that. Python defines a syntax that can be used for type checking, but you need an external tool to do that. GCC does type checking because it's defined in the language specification. You would have a situation analogous to Python only if you needed GCC + some other tool for type checking. This isn't the case.

VeejayRampay 2y ago

python will never be "properly typed" what it has is "type hints" which is way to have richer integration with type checkers and your IDE, but will never offer more than that as is

hot_gril 2y ago
It is properly typed: it has dynamic types :)
- GTP 2y ago
  Then we have very different ideas of what proper typing is :D Look at this function, can you tell me what it does? def plus(x, y): return x+y If your answer is among the lines of "It returns the sum x and y" then I would ask you who said that x and y are numbers. If these are strings, it concatenates them. If instead you pass a string and a number, you will get a runtime exception. So not only you can't tell what a function does just by looking at it, you can't even know if the function is correct (in the sense that will not raise an exception).
  - hot_gril 2y ago
    When is the last time you had a bug IRL caused by passing the wrong kind of thing into plus(x, y), which your tests didn't catch?
    - GTP 2y ago
      It never happened to me, because I don't use Python ;) On a more serious note, your comment actually hints at an issue: unit testing is less effective without static type checking. Let's assume I would like to sum x and y. I can extensively test the function and see that it indeed correctly sums two numbers. But then I need to call the function somewhere in my code, and whether it will work as intended or not depends on the context in which the function is used. Sometimes the input you pass to a function depends from some external source outside your control, an if that's the case you have to resort to manual type checking. Or use a properly typed language.

hot_gril 2y ago

I think static typing is a waste of time, but given that you want it, I can see why you wouldn't want to use Python. Its type-checking is more half-baked and cumbersome than other languages, even TS.

baq 2y ago
Typescript is pretty much the gold standard, it’s amazing how much JavaScript madness you can work around just on the typechecking level. IMHO Python should shamelessly steal as much typescript’s typing as possible. It’s tough since the Microsoft typescript team is apparently amazing at what they do so for now it’s a very fast moving target but some day…
- hot_gril 2y ago
  Well the TS tooling is more painful in ways. It's not compatible with some stuff like the NodeJS profiler. Also there's some mess around modules vs "require" syntax that I don't understand fully but TS somehow plays a role.
GTP 2y ago
I instead think that the lack of static typing is a waste of time, since without it you can have programs that waste hours of computation due to an exception that would have been prevented by a proper type system ;)
nine_k 2y ago
I used to think like that until I tried. There are areas where typing is more important: public interfaces. You don't have to make every piece of your program well-typed. But signatures of your public functions / methods matter a lot, and from them types of many internal things can be inferred. If your code has a well-typed interface, it's pleasant to work with. If interfaces of the libraries you use are well-typed, you have easier time writing your code (that interacts with them). Eventually you type more and more code you write and alter, and keep reaping the benefits.
- 2y ago

NegativeK 2y ago

Python's typing must accommodate Python's other goal as quick scripting language. The solution is to document the optional typing system as part of the language's spec and let other tools do the checking, if a user wants to use them. The other tools are trivially easy to set up and run (or let your IDE run for you.) As in, one command to install, one command to run. It's an elegant compromise that brings something that's sorely needed to Python, and users will spend more time loading the typing spec in their browser than they will installing the type checker.