What's the status with numpy types? I find two projects, https://github.com/machinalis/mypy-data/tree/master/numpy-my... and https://github.com/numpy/numpy-stubs but neither looks very complete and neither has been updated recently.
A Failed Experiment with Python Type Annotations
71–80 of 82 posts
Re: A Failed Experiment with Python Type Annotations
#72I would have to disagree with this post (first point is actually inaccurate and the second I could go either way on). Type annotations/mypy, especially when coupled with dataclasses/pydantic has been very helpful in maintaining a rather substantial 3.7 codebase.
I agree. I'm currently working on a project containing 45k lines of Python code and we have really benefited from having type annotations.
Re: A Failed Experiment with Python Type Annotations
#73Why would you keep Python if you want static typing? I mean, there are several modern, performant (more than Python actually) statically typed languages. Rust, Go, Kotlin, Scala, Swift… All of them are mature and have a good library ecosystem. So, except if you need some math/AI/ML packages available only for Python, why bother? Choose the right tool for the job, no?
Getting a whole team to try out static typing on a language that they already know is far easier than getting a whole team to learn an entirely new language.
Re: A Failed Experiment with Python Type Annotations
#74Earlier quoted context omitted.
How's the cross-platform library ecosystem? My distant sentiment is that the bulk of libraries are tied to / provided by Apple, but I'd be happy to be proven wrong.
Cross-platform stuff is mainly non-GUI since the main thrust of the cross-platform scene seems to be server-side Swift, and most of the GUI stuff is targeted to iOS (although with Project Catalyst, that's all implicitly valid macOS code now). I expect we may see some third-party, cross-platform reimplementations of SwiftUI very soon once the appropriate language features are set in stone and ship with the next versio…
> Plus, Swift pretty much has direct compatibility with C and Python libraries without needing to wrap anything.
Could you please elaborate on this point?
Re: A Failed Experiment with Python Type Annotations
#75Earlier quoted context omitted.
Cross-platform stuff is mainly non-GUI since the main thrust of the cross-platform scene seems to be server-side Swift, and most of the GUI stuff is targeted to iOS (although with Project Catalyst, that's all implicitly valid macOS code now). I expect we may see some third-party, cross-platform reimplementations of SwiftUI very soon once the appropriate language features are set in stone and ship with the next versio…
> Plus, Swift pretty much has direct compatibility with C and Python libraries without needing to wrap anything. Could you please elaborate on this point?
C compatibility is one of the original design goals for Swift and is used extensively for the Linux version, for making Swift wrappers around existing libraries, and the Objective-C bridge on macOS. If using Xcode, one would use a bridging header; otherwise, one can use Swift Package Manager to wrap C libraries for use in Swift projects.
Swift recently gained the features needed to call Python code. You can either use the Python module from Swift for Tensorflow or the PythonKit library, both of which allow calling Python code from within Swift.
The features used to allow calling Python from Swift can also be used for other dynamic languages, so there may be the ability to call Ruby and other languages' libraries in future as well.
Re: A Failed Experiment with Python Type Annotations
#76Earlier quoted context omitted.
If your code doesn't need to be py 2/3 compatible it's fine to annotate using str. But if you do, typing.Text and bytes is better.
Am I missing something? Annotations aren't supported by Python 2 so if you're using them then you never need to worry about Python 2/3 compatibility.
mypy supports comment-based annotations for Python 2. https://mypy.readthedocs.io/en/latest/python2.html
Re: A Failed Experiment with Python Type Annotations
#77The first point can be rather easily circumvented by using strings as forward references and it only takes a bit of googling to figure that out. The second doesn't seem remotely like a deal breaker to me. Half the reason for having type annotations is to provide a description of what a function or method does at a glance. This is idiomatic even in hardcore functional languages like Haskell. With return type inference…
It seems to me that type inference would be silly in this case. Type suggestion during mypy checks might be useful though.
Function x does not specify a type, but returns SomeHelpfulTypeString. We recommend you use that.
Put it behind a flag and call it a day. Maybe even have a way of requesting type suggestions for functions during development
Re: A Failed Experiment with Python Type Annotations
#78What's possibly so cumbersome about defining return types? It does seem a little embarrassing that the annotations don't even support circular references.
Author of the subj didn’t even bother to Google that issue, which is solved by the way.
Re: A Failed Experiment with Python Type Annotations
#79I feel baking type annotations on top of dynamic, late binding languages is fundamentally misunderstanding what they are about. Python might not go as far as say, smalltalk, but if you're picking a dynamic language just accept the runtime dynamism and don't program against it.
Or well, accept the dynamism and use type declarations as automated declarative teat coverage, at the very least.
Re: A Failed Experiment with Python Type Annotations
#80What's possibly so cumbersome about defining return types? It does seem a little embarrassing that the annotations don't even support circular references.
Circular references like that are called "recursive types" in formal type theory. They are one of those big issues that academics like to write papers about. Even if you just want to write a practical interpreter, and choose to gloss over the issues, they will still come back in some disguised form and either by requiring some sort of implementation kludge, or just by creating weird edge cases.
And how is that an issue for type checking, would you elaborate?