6 ms·

When I read the twitter replies, it doesn't make me optimistic for the future of typed python. I don't work with Python often, so I don't know what the "truth

by skohan 6y ago

When I read the twitter replies, it doesn't make me optimistic for the future of typed python. I don't work with Python often, so I don't know what the "truth on the ground" is, but it seems like having a language divided between several different type-checking implementations is going to be a nightmare for things like interoperability of frameworks. I'm imagining a future 5 years down the road where some poor python developer has to use some "polyfill" solution because they want to import a library which was developed with a type-checking solution which is no longer main-stream, or because the type-checkin solution they're using has breaking changes with respect to previous versions.

deleted 6y ago
[deleted]
philwelch 6y ago
Python 3 type annotations are part of the language spec. Whether you use mypy or a different library for type checking shouldn’t necessarily make a difference to the code.
- ali_m 6y ago
  Type annotations may be part of the language spec, but the way they are enforced is not. Different type checking libraries have made different design choices (leniency vs strictness, type inference vs gradual typing etc.). Although these differences don't matter at runtime, they do mean that code which passes one particular type checker might fail with another.
  - davnicwil 6y ago
    Is the solution here just to skip type checking the code of dependencies, and just check the types at the interface with your own code using your tool of choice? Or is it more complex than that?
    - jraph 6y ago
      I think so. When typing checking a project, its dependencies don't get type checked as well as far as I know. Type errors in dependencies are kind of not relevant for you, and many dependencies are not type-annotated anyway.
      - ali_m 6y ago
        Well you probably do still want the type checker to at least look at the public interfaces of any libraries you depend on, since you want it to enforce that you're calling into them correctly.
        jraph 6y ago
        Absolutely. It should probably not report errors that are not in your code, by default anyway, but still extract information about typing relevant to you as much as it can.
    - neilparikh 6y ago
      I think that mostly works, but it's still possible that different tools assign different semantics for the same syntax, which could then interact in a weird way if the library author wrote the interface annotations with Tool A's semantics in mind, while you ended up checking them against your code with Tool B. I think the type systems are simple enough that this is probably a theoretical concern, and won't come up often in practice.
  - throwaway81523 6y ago
    There actually seems to be no story about inductive types (e.g. trees) in Python and this appears due to well known theoretical difficulties combining subtyping (required for OO) and type inference (?). I.e. it is a hard problem. There are a few long term open mypy github issues about it, and some hacky workarounds, but no real answer. This is also why languages like Haskell (with good support for inductive types) tend to not have OO. I'm not exactly familiar with the issues, but there is some PLT literature about it, by Anton Setzer and others.
    - joshuamorton 6y ago
      Can you elaborate on this? Forward refs and recursive types are accepted on most places that isn't NewType, so you can make them, but not in a one liner.
      - throwaway81523 6y ago
        Sorry about the slow reply but I just noticed your question. Haskell supports recursive types just fine. The issue I'm mentioning is that it is hard to express those types in MyPy, which is a static typechecking add-on for Python, not Haskell.
midrus 6y ago
The ecosystem is already pretty split on several fronts, not just typing. Python 2 vs 3, async vs blocking, packaging tools, etc. I left python 3 or 4 years ago and not planning to go back (basically the company I was working for mandated they were not going to ever upgrade to python 3 because of the effort required and thus stopped all migration related projects). The language is nice, and frameworks such as Django are great, but the mess the ecosystem has become is not something I miss.
- AlphaSite 6y ago
  Python 2 is pretty dead at this point.
  - e3k 6y ago
    2.x dead? Not really: lots of 10 year old projects are in maintenance or even actively developed. Migrating several hundred thousand lines of code bases with few people and many dependencies (some of them not maintained, not ported to 3) are not trivial. These will stay for years still. Actually it is very sad, that significant new tools are basically useless on 2.x (e.g. vscode: lots of waiting on completion, or jumping to definition - if it works at all).
- guitarbill 6y ago
  I agree that the ecosystem is a bit messy, but it's more of a function of how long Python has been around, and how successful it has been. Newer languages have the benefit of hindsight. Take `go fmt` or `cargo fmt`. black is the de facto autoformatter, but it's still an optional dependency. Maybe like virtualenv it'll eventually be integrated into the standard library/distro. That would help. With other stuff, the split you describe could be a real problem, although for the majority of Python users, using mypy and poetry is fine. > basically the company I was working for mandated they were not going to ever upgrade to python 3 because of the effort required and thus stopped all migration related projects If you're actually serious, this is intriguing to me. Business-wise, I have never seen the math shake out this way. When we've done sizings/estimated developer hours and ROI, it's always been more economic to slowly migrate to Python 3 vs a rewrite, even if the dev team is also already using and well-versed in another language. If you're able to provide more details, please do. It's so rare to have a high-quality discussion about this.
canjobear 6y ago
It’s always possible to run code ignoring all type annotations.
heavyset_go 6y ago
There is no semantic meaning given to type annotations by the interpreter. There's no need for polyfill nor are there issues with interoperability of frameworks because, again, type annotations have no semantic meaning. They're like comments, they're only there for developer convenience and can be completely ignored.

by skohan 6y ago

deleted 6y ago

[deleted]

philwelch 6y ago

Python 3 type annotations are part of the language spec. Whether you use mypy or a different library for type checking shouldn’t necessarily make a difference to the code.

ali_m 6y ago
Type annotations may be part of the language spec, but the way they are enforced is not. Different type checking libraries have made different design choices (leniency vs strictness, type inference vs gradual typing etc.). Although these differences don't matter at runtime, they do mean that code which passes one particular type checker might fail with another.
- davnicwil 6y ago
  Is the solution here just to skip type checking the code of dependencies, and just check the types at the interface with your own code using your tool of choice? Or is it more complex than that?
  - jraph 6y ago
    I think so. When typing checking a project, its dependencies don't get type checked as well as far as I know. Type errors in dependencies are kind of not relevant for you, and many dependencies are not type-annotated anyway.
    - ali_m 6y ago
      Well you probably do still want the type checker to at least look at the public interfaces of any libraries you depend on, since you want it to enforce that you're calling into them correctly.
      - jraph 6y ago
        Absolutely. It should probably not report errors that are not in your code, by default anyway, but still extract information about typing relevant to you as much as it can.
  - neilparikh 6y ago
    I think that mostly works, but it's still possible that different tools assign different semantics for the same syntax, which could then interact in a weird way if the library author wrote the interface annotations with Tool A's semantics in mind, while you ended up checking them against your code with Tool B. I think the type systems are simple enough that this is probably a theoretical concern, and won't come up often in practice.
- throwaway81523 6y ago
  There actually seems to be no story about inductive types (e.g. trees) in Python and this appears due to well known theoretical difficulties combining subtyping (required for OO) and type inference (?). I.e. it is a hard problem. There are a few long term open mypy github issues about it, and some hacky workarounds, but no real answer. This is also why languages like Haskell (with good support for inductive types) tend to not have OO. I'm not exactly familiar with the issues, but there is some PLT literature about it, by Anton Setzer and others.
  - joshuamorton 6y ago
    Can you elaborate on this? Forward refs and recursive types are accepted on most places that isn't NewType, so you can make them, but not in a one liner.
    - throwaway81523 6y ago
      Sorry about the slow reply but I just noticed your question. Haskell supports recursive types just fine. The issue I'm mentioning is that it is hard to express those types in MyPy, which is a static typechecking add-on for Python, not Haskell.

midrus 6y ago

The ecosystem is already pretty split on several fronts, not just typing. Python 2 vs 3, async vs blocking, packaging tools, etc. I left python 3 or 4 years ago and not planning to go back (basically the company I was working for mandated they were not going to ever upgrade to python 3 because of the effort required and thus stopped all migration related projects). The language is nice, and frameworks such as Django are great, but the mess the ecosystem has become is not something I miss.

AlphaSite 6y ago
Python 2 is pretty dead at this point.
- e3k 6y ago
  2.x dead? Not really: lots of 10 year old projects are in maintenance or even actively developed. Migrating several hundred thousand lines of code bases with few people and many dependencies (some of them not maintained, not ported to 3) are not trivial. These will stay for years still. Actually it is very sad, that significant new tools are basically useless on 2.x (e.g. vscode: lots of waiting on completion, or jumping to definition - if it works at all).
guitarbill 6y ago
I agree that the ecosystem is a bit messy, but it's more of a function of how long Python has been around, and how successful it has been. Newer languages have the benefit of hindsight. Take `go fmt` or `cargo fmt`. black is the de facto autoformatter, but it's still an optional dependency. Maybe like virtualenv it'll eventually be integrated into the standard library/distro. That would help. With other stuff, the split you describe could be a real problem, although for the majority of Python users, using mypy and poetry is fine. > basically the company I was working for mandated they were not going to ever upgrade to python 3 because of the effort required and thus stopped all migration related projects If you're actually serious, this is intriguing to me. Business-wise, I have never seen the math shake out this way. When we've done sizings/estimated developer hours and ROI, it's always been more economic to slowly migrate to Python 3 vs a rewrite, even if the dev team is also already using and well-versed in another language. If you're able to provide more details, please do. It's so rare to have a high-quality discussion about this.

canjobear 6y ago

It’s always possible to run code ignoring all type annotations.

heavyset_go 6y ago

There is no semantic meaning given to type annotations by the interpreter. There's no need for polyfill nor are there issues with interoperability of frameworks because, again, type annotations have no semantic meaning. They're like comments, they're only there for developer convenience and can be completely ignored.