It kind of looks like a band-aid. Could you elaborate on why I would use, say, mypy as opposed to Golang if I don't need the benefits of a scripting language?
edit: I can understand why mypy would be useful to refactor an existing (large) project to bring forth type safety guarantees as you go forwards, but surely for new projects there are other languages of choice if type safety is what you want?
1) It's faster to write the initial proof of concept with a dynamic language
2) It's common that the proof of concept becomes sufficiently big/stable that it turns into the final codebase
3) Gradual typing makes the path from PoC to real codebase smoother, instead of re-implementing in another language.
Point 1 is contentious of course, but that argument isn't relevant here. It is believed, and that belief becomes practice.
An example of point 2 might be OSH of the oil shell, which doesn't use mypy I believe, but was originally written in python with the intent to rewrite in C++, and eventually decided it was too costly to rewrite (somehow he decided that ripping apart the python VM would be the more fruitful path... and apparently he's making good progress there).
So basically, the usecase of mypy is when you're making the decision of continuing with python, or rewriting. Sometimes rewriting was part of the strategy from the start, other times a script just grew into a full-fledged program over time, but mypy's primary goal wouldn't be to introduce from the start.
Another usecase I've personally done is having the typing available to me from the start, but not actually making use of it until I reached a particularly nasty section of code. And so that particular chunk becomes (reasonably) statically typed, while the rest of the program remains standard python.
Although in that case I used a library that enforced typechecking at runtime rather than mypy (the library was typeguard iirc), which I only enabled on test runs (it slowed down the program significantly).
Indeed there may be a plethora of valid reasons to pick another language over python for some project. But that wasn't the question.
Mypy supports generics, protocols, (via extensions) dependent types, and user-defined covariance rules. Its leaps and bounds more powerful than go's type system.
Pytype adds type inference to that list. You end up with a type system that's closer in power to Scala's or Haskell's than Java or Go's.
If you truly believe that a dynamic language like python can have type safety, then imagine what a language like Go can achieve.
Python already has deviated too much from where it started and mypy offers too little to justify the verbosity.
So I guess we'll see what the future holds for them.
Literally exactly the same thing, but no more.
Mypy and Go's compiler have the exact same information available at compile time. Python stops being a dynamically typed language when you add Mypy. It becomes statically typed. Calling it "dynamic" is like calling C++ "dynamic" because C++ doesn't have access to run-time type information (usually).
Actually that's not true, due to the increased expressiveness of Mypy's type system, it has more information available. Mypy has more information. It can do stronger analysis. Go has less information, it can't do as much. Go can make language (syntax) changes to improve this. Python has been very smart, and the type system is implemented as normal objects using the normal syntax. Adding new types, even "special" ones (like Union or Interface) doesn't require modifying the language itself, but can be done only with modifications to a fairly nimble standard library module.
This allows python's type system to evolve much more quickly than Go's has shown itself capable of.
>Python already has deviated too much from where it started and mypy offers too little to justify the verbosity.
But python's type system offers more than Go's, and isn't particularly more verbose, so what are you saying here about Go's type system?
I will leave this tidbit here:
i, found = 0, False # type: int, bool
In any case, I find these new "typing" features very awkward, overly verbose and not the reason that I chose python in the first place. If I am to write all this non-pythonic stuff to be 10x+ slower, less memory efficient, awful at concurrency and still not having solved the packaging/deployment situation... I will just use Go. Or any other language in that league, that offers so many more nowadays.
That's actually
i, found: Tuple[int, bool] = 0, False
As for the rest of your comment, I think that's been well discussed. There are a variety of non-typing reasons to use go over python. But if you are about type safety you're probably better off with modern python than modern go.
Right. Ok we have a problem with definitions. No this is obviously not normal syntax.
Unless we take it to mean "whatever new syntax python introduces is normal syntax, since it supports it!", which is tautological and not very useful.
I'm gonna say something, strictly so you can understand where I'm coming from, not to offend you.
You sound very young. And by "young", I mean so young to not remember that Python was always about "duck typing" and not about strict types. I still have books on my bookshelf that tried to dissuade you from using "issinstance(foo, sometype)". So no, it's not python or normal syntax.
Yes, Python now is safer than older Python. But I had 99 problems with Python and that wasn't one of them :(
You, speaking as if Python is progressing so fast while Go is standing still, feels disingenuous. Go fixed their dep/packaging woes in a few years, Python is not even close. Go is adding generics. Go becomes faster in almost every release.
Changing Python into something that doesn't resemble python, its values, or the reasons that people chose it in the first place doesn't make sense, nor does it make it "Python".
I don't want Python to become Haskell, Rust or Go. No one ever chose python for its typing system! Rather its lack of it.
Anyway, there's no accounting for taste and to each their own.
Cheers
I think you're confusing an idea with an implementation. Bugs can be fixed. If mypy is useful, it will remain useful and slightly more stable.
It can't be faster. It can't consume less memory. It can't stay still.
So they add auxiliary features. No matter how much they downvote you, you're right.
For a new project it doesn't make sense to not use Go, or something similar, if you're going down that road.
I'm glad that they are doing it, because it's contributed hugely to the Python ecosystem -- especially making it easier for other companies to make the switch to Python 3.
I highly recommend mypy for new and current python3 users. It's one of the biggest and best reasons to be using python3 (not that you should need any more :) )