61–70 of 82 posts
Yes, there are two things about introducing types that the author finds annoying. So don't do those two things, and use type annotations for all the rest.
The type annotation system and mypy are designed to give you benefits even if you don't fully annotate everything -- that's the starting point of nearly all existing python code bases.
I recently added type annotations to my Python 3.7 project and found it very helpful. Just the process of adding the annotations caught a handful of bugs! Some things I found useful: 1. from __future__ import annotations As I mentioned in another comment, this lets you write annotations naturally without worrying about when something gets defined. 2. typing.TYPE_CHECKING is only True while type checking. This allows…
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.
> mypy has no trouble understanding this, but it’s unfortunately not valid Python code. You can’t refer to Node within the Node class. No, the workaround is to stringify "Node". class Node(Object): def add_sub(self, sub: 'Node'): ... def get_subs(self) -> Sequence['Node']: #Or maybe 'Sequence[Node]' works just fine. As of python3.7, this stringification is done by automatically under a from future import, and will ev…
> But you should still annotate your public apis. The good thing about inference (especially with a REPL) is you can write it without the annotation, and then use the inferred type (in Haskell, I usually find that when I resist the temptation to explicitly annotate types, the actual types are more general than I would have specified.)
Inferred, loose parameter types are great, because while I think it's good to know the differences between iterator, generator, iterable, sequence, container, and so on, it's difficult, and inference will give you the loosest one. But with return values, the inferred type will be the tighest, in other words your function will return a Dict (or worse, a defaultdict) instead of a Mapping or MutableMapping. You almost always want a Mapping.
Earlier 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.
Annotations in comments or in type stubs are supported in python2 (you can look at typeshed for typing.Text and conditional py2/3 stuff). There's also some other cases, but they're...unique.
Try Kotlin. Syntax is similar to Python (but better), but it's actually just Java, with all the supporting ecosystem. Kotlin is just syntactic sugar.
Well, from [1], I'd say syntax is closer to C.
Why 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?
Scala: Python + dataclasses [+ mypy] offers a programming experience close to pragmatic Scala. The tradeoff becomes: * worse performance * lack of immutable vectors, alleviated via style conventions * rarely, awkward lambdas vs. * wide pool of people familiar with the language * lack of JVM lockin: Scala native is not there yet, the library ecosystem is all JVM. * [good] batteries included * much better reflection *…
>Kotlin: JVM lock-in
You know OpenJDK has been available for over a decade, right?
Earlier quoted context omitted.
> Swift: Apple lock-in. Swift runs on Linux and has done since it was made open source in 2015, a year after its initial announcement. Windows support is being worked on but, for the time being, it runs fine in WSL. No lock in.
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.
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 version of Swift.
Otherwise, it's fairly healthy — lots of computational libraries, database, web, etc. Plus, Swift pretty much has direct compatibility with C and Python libraries without needing to wrap anything.
I 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.
> rather substantial 3.7 codebase What size codebase is substantial?
The first issue is fixed by just using a string. Yes, you can't do Sequence[Node], but you can do Sequence["Node"]. The docs talk about this here ("class name forward references"): https://mypy.readthedocs.io/en/stable/kinds_of_types.html#cl...
For Python 3.7, you can do: from __future__ import annotations This will defer the parsing of annotations until after the file has been parsed, allowing you to use the actual symbol instead of a string.
I really like using and writing type annotated Python, but every time I do, I wonder if I should just use a language where all the annotation time I put in gets me actual runtime improvements.