Python’s “type hints” are a bit of a disappointment to me

https://www.uninformativ.de/blog/postings/2022-04-21/0/POSTING-en.html

by zdw • 4 years ago

338 585 4 years ago

galdosdi• 4 years ago

I haven't used python's type hints much yet but I used TypeScript a bunch about a year ago and I have the exact same complaints.

Most of the benefit of types goes away unless _everything_ is typed... my libraries, the libraries my libraries use, etc. I should be able to jump around in and out of library code following types and usages thereof in my IDE, making conclusions that are accurate based on what the types say.

When some of your libraries (or indirect dependencies) don't have types, you can no longer ever make any firm conclusions when exploring a complex codebase based on types. I want to change a method in the Widget type, and my IDE says it's used in 4 places. But in reality, that just means 4 or more places, who knows if there are others.

Adding types to a language that doesn't already have them is very hard for this reason. Until many years pass and they're in universal use, they add little value.

Loeffelmann2• 4 years ago

I think Typescript nowadays has reached critical mass where most packages at least have a @types/* definition. I can't remember the last time I had to use a package that didn't provide types. I had the types be wrong one time though.

ciupicri• 4 years ago

It reminds me of this 5 year old bug in mypy: "int is not a Number?" [1].

[1] https://github.com/python/mypy/issues/3186

benatkin• 4 years ago

It isn't really one though (a lot of reading):

https://stackoverflow.com/questions/69334475/how-to-hint-at-...

I would rather my type checker give me the truth than gloss over it. This issue should be kept open (it is) but they should wait until a good solution is found that doesn't gloss over the discrepancy.

flakiness• 4 years ago

I use the type-annotated python at work and at hobby. I see the point of OP, but I'd say it helps even if it's not perfect or "sound".

Though I agree on its negative impact on the language ergonomics. It removes the joy of writing "scripting language" and as a statically typed language it is far from static-type-native ones.

Now I see it as a tax for compatibility: You enjoy dynamic typing at the beginning of the project, but you have to pay it back once you've grown up to a certain scale.

TypeScript to me feels much more like a native static typed language because it is. Does it help to be a transpiler? Maybe. But I would think that Hejlsberg just has done an astonishingly good work to make it compelling. Python's type annotation is good and completely reasonable, but gradual typing is such a hard problem and being good is probably not enough here.

jmugan• 4 years ago

I love type hints. They make the code so much more readable. I wish they could do more, but knowing what the programmer intended for a variable is huge. Now, when I see code without type hints I think, "Oh man, now I have to dig into everything to know what anything is."

mountainriver6• 4 years ago

Yeah this is such a huge benefit that’s rarely discussed. It wildly increases the understanding of a code base which makes developers more productive and safe

vermarish• 4 years ago

Yeah. I usually don't bother with type hints for local variables, but for parameters and return types, it makes skimming old code so much easier.

jonathan-adly• 4 years ago

100% agree - never really understood the movement behind adding types to Python. Type hints are a useless complexity that yield little return. If you want types, use something else other than Python. The whole thesis behind Python is simple is better than complex.

mjr003• 4 years ago

How is "this function takes a string and returns a float" more complex than "this function takes any data type and returns an unspecified data type"?

Inityx• 4 years ago

On the one hand yeah, I agree with this, but on the other hand you have a lot of enormous software projects written in Python that are decidedly not simple, and would be extremely difficult to completely rewrite in a different language. Type hints do offer some value in this circumstance, by making it easier for disparate groups to modify the same large codebase though static analysis.

bobbylarrybobby• 4 years ago

They're great for autocomplete, but that's pretty much it

forrestthewoods3• 4 years ago

If you want types, use something else other than Python.

Python is still strongly typed.

Me: what type does this argument need to be?

Python: you have to figure that out

Me: I just pass whatever I want?

Python: Oh no. Usually only a single specific type is supported. But you have to guess what it is.

Me: what if I get it wrong?

Python: the program crashes at runtime

lifewallet_dev• 4 years ago

You don't understand what "strongly typed" means... I give you a hint, `"1" == 1` is a type error in Python but "okay" in JavaScript because this one is "weakly typed", you're confusing "dynamic typing vs static typing" with "strongly typed vs weakly typed".

sirsinsalot• 4 years ago

I find it best to see type hinting as "living documentation". Yeah, you can ignore it, it is Python afterall, but if you want the IDE/tools to have better more helpful hints ... use machine readable hint documentation.

I'd argue if your functions are full of type-assert like guards, _then_ use another language!

bb883• 4 years ago

I just saw someone on Twitter post a "IntegerType" class which did exactly this, including capturing the sign -- because he couldn't trust int().

retrac• 4 years ago

useless complexity that yield little return

Typechecking allows certain errors to be detected at typecheck time rather than at runtime. I don't personally consider that useless. E.g. A mistake I just made. I'm working in a language I don't know too well right now with strict static typing. The file read function takes a handle. If I pass it a string of the file name, rather than the handle result from file open, it just doesn't compile. In most dynamic languages, that error would not be detected until it executes.

ReflectedImage3• 4 years ago

The changes you need to make to a Python program to enable it to be type checked result in more bugs being added than the type checker removes leaving you at a net negative.

Type checking is just a really poor way to ensure program correctness until you start using an exceptionally strongly typed language like Haskell.

You use types in C / C++ / Java because the compiler needs them to work not because it's a good idea.

Lendal2• 4 years ago

I tried mypy when I first started into type checking in Python back when I was trying to do Python in VS Code and I discovered that mypy is a time-sucking anti-productivity disaster that needs to die in a fire.

When I started learning PyCharm though, I discovered that type checking can actually work well in Python and it is not a waste of time at all. So I advise people now that unless you're using PyCharm, do not waste any time on type checking Python. In which case, have at it. I love it. PyCharm is really the only way to do type-checking productively right now.

dgellow• 4 years ago

If you use VSCode and Pylance (Microsoft python language server) you don’t need to setup Mypy, you can enable type checking in user settings and it will use its own engine for type analysis. You have two modes, basic and strict.

I would recommend to try out if you can, the experience is quite good. I personally find “strict” too strict for the current state of python, but “basic” is already very helpful.

The developer experience is still subpar when compared to Typescript but it’s improving fast (but I mean, typescript with VSCode has one of the best developer experience I’ve ever seen).

ainar-g• 4 years ago

Could you elaborate on mypy? I'm not a Python developer (and I really have much more experience with statically typed languages), but if I ever had to maintain a Python codebase, I'd assume that adding mypy and type annotations would be among the first things I'd do, so it's a bit of a surprise to read that.

kstrauser• 4 years ago

I love mypy. It's fine, if sometimes a little alarming when you aim it at a previously-untyped codebase. In my case, it turned up plenty of type errors that probably never became a problem in production, but very well could've. It's also a nice thing to put in a CI pipeline to block new code errors.

Lendal2• 4 years ago

I spent a lot of time trying to configure pypy in VS Code, time that I didn't have to spend in other languages such as TypeScript, and I never did get it working as well as it does in PyCharm. PyCharm comes already configured. You don't have to do anything for typing. Works out of the box. VS Code is like that with TypeScript but not for Python. That was a couple of years back so maybe it's different today. I hear VS Code's PyLance extension works but I've already made the switch to PyCharm. I might try it out later.

pphysch• 4 years ago

I agree treating Type Hints as comments is the way to go. It's a bit nicer to use a library that is fully-hinted than one that is not. But I don't worry about type-hinting my own code, unless it's a particular complicated function signature that other people will be calling.

chis• 4 years ago

Only facts here. I think most large codebases eventually see type hints drift away from reality as individual contributors are more incentivized to hack in `Any` types to make things compile instead of typing every line properly. This is especially common for handling data objects which come in over the network - often they can have a couple different types but people just type it as one thing for simplicity.

Overall I do think type hints are worth it though, for maybe two benefits. They force you to look at the ridiculous types you are using, like `List[Union[None, str, List[Dict[str, str]]]]` which is the sort of thing that happens in codebases all the time. It adds just enough friction to push people to make explicit dataclasses or simplify function returns, which is good. Secondly they help with tracking functions which return None, which is a pain when following callstacks in big codebases.

bb883• 4 years ago

My understanding was large python code bases (think Google) have a large problem. Someone makes a code change and suddenly it becomes difficult to find the scope of type errors in their monorepo. That was the driving force IIRC.

That said, I think pytype makes a lot of sense since it infers types from code, which you can edit by hand and then merge back into the python file when your code is stable.

mountainriver6• 4 years ago

Yup this is the biggest benefit. Working on a large untyped code base is about as bad as it gets

goodoldneon8• 4 years ago

You can disallow `Any` with the `--disallow-any-explicit` option

vesche• 4 years ago

I agree. I'm glad that they're optional. One of the main reasons to use Python is to prioritize development speed over performance AND to prioritize read/write-ability over hand jamming mundane syntax. I understand why some who have a background in typed languages might prefer to use Python with type hints, but it should be understood that they aren't very Pythonic.

forrestthewoods3• 4 years ago

main reasons to use Python is to prioritize development speed

My experience with Python is that it slows development speed to a crawl due to dynamic typing. It’s maybe faster to write the first 1000 lines. But after that it becomes slower and more painful. At least in my experience.

mjr003• 4 years ago

I understand why some who have a background in typed languages might prefer to use Python with type hints, but it should be understood that they aren't very Pythonic.

Completely disagree. The Python community has very rapidly adapted mypy because of widespread recognition that yes, type information is extremely helpful for any code bases larger than a few files and/or worked on by more than a few developers. Every major Python library I can think of now has mypy stubs available. If you're going to dismiss them as "not Pythonic" you may as well dismiss anything other than Python 2.7 as "not Pythonic".

ImprobableTruth8• 4 years ago

Man, the idea that type hints reduce read-ability are crazy to me. It's like if someone told me that they think comments make code less readable.

Like, even if you think that type hints have ugly syntax, prior to them vast most projects just didn't bother with documenting the shape of data, so you had to read source code, guess and experiment. Unless you just don't care about knowing what you're specifically working with (which strikes me as living on the edge), how is it not an ergonomics gain?

goodoldneon8• 4 years ago

Code is way less readable without types. If I see this:

  def create_user(user):
    other_function(user)

Then how do I know what `user` is? Is it a dictionary? An object? If it's an object, where's its class definition? To find the answer I need to search for all the code that calls `create_user`, and then code that calls that code, and then code that calls that code, ad nauseam.

Onboarding into a huge, untyped codebase is brutal

kortex7• 4 years ago

I understand why some who have a background in typed languages might prefer to use Python with type hints, but it should be understood that they aren't very Pythonic.

Okay, this myth that Pythonic == loosey-goosey duck-type-everything slinging dicts and strings nothing static cause that's too slow, really needs to die.

Pythonic is all about pragmatism and parsimony. If that means not typing anything cause it's a 50 line script, do that. If it means the most efficient way for large dev teams to communicate on sprawling code bases is to use rich types, then do that.

Personally, I use types even in the short scripts, because then I can offload keeping track of what type everything is, instead of having to remember yet another user_dict with whatever keys the producer felt like using at the time. It makes autocomplete faster and I'm less mentally fatigued. Less mental fatigue == more pythonic.

s-y-s-y-s• 4 years ago

I've annotated Python typing with a 20/80 approach. I annotate strings, integers, floats, simple list and dict. I don't try to produce complex type specs for lists, dicts, functions.

My company runs some kind of static analysis that checks things. And I get 80% of the benefit with 20% of the work. So start small, and don't expect perfection (yet).

emacs28• 4 years ago

I find type hinting useful as an additional level of documentation, especially for complex projects, and it helps my future self understand my own code more quickly.

Also in my experience it can provide static analysis tools more information and provide autocomplete suggestions in a wider range of coding scenarios.

wardedVibe• 4 years ago

They feel like someone told the Python dev team about Julia's multiple dispatch based on types, and they felt like they had to respond, even though they don't really provide the actual speed and flexibility that motivates their use in Julia.

ledauphin11• 4 years ago

this article is so full of... not-very-educated thoughts on gradual typing in a dynamic language that it's hard to know where to start.

A few concrete criticisms:

1. If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime. However, good news! Python has always been strongly typed, and _does_ enforce types at runtime!

2. A number of the examples given would be _impossible_ to statically type in most compiled languages (those without dependent types). It's hard to know where to go with a critique saying that you can't fully represent heterogeneous values in a dict, given that you can't do this _at all_ in many statically compiled languages.

It seems to fall back on saying "use of the type system requires too much discipline to be useful". This might be an interesting criticism on its own; however many current users of Python can say, from experience, that the required discipline is not a high enough hurdle that it prevents us from using types consistently and correctly.

There is plenty to critique about Python's static typing, but this article would have been better titled "I'm confused about Python's static type system and want somebody to show me how it's actually used in real-world scenarios".

zmgsabst6• 4 years ago

That’s the point though:

Duck typing and heterogeneous dictionaries are (and have been) standard Python.

Adding a type system which doesn’t respect duck typing by trying to access the member even when the types don’t match or which can’t express standard idioms used in Python seems a poor architectural choice.

It’s not saying that Python’s type system is “too much discipline”, but rather that the type system doesn’t encode typical Pythonisms.

Znafon• 4 years ago

Python typing supports duck typing: https://peps.python.org/pep-0544/

and heterogeneously typed ducts: https://peps.python.org/pep-0589/

ImprobableTruth8• 4 years ago

No offense, but have you actually given it a shot? Duck typing is supported and you can get virtually all use cases of heterogenous dictionaries by using union types and duck typing. The article even touches on this.

edit: To be more precise: The article specifically mentions that accessing invalid members give you a type error, but posits that people will probably not bother and just use 'any' instead. How is that not saying 'too much discipline'?

dtech• 4 years ago

It seems to me like Python needs to get Typescript's capabilities (if Python wants to go further this way of course). It solves all these problems very well, and has no problem with 2 and most of the author's objections.

ledauphin11• 4 years ago

Typescript does absolutely fantastic type inference, which mypy definitely does not. I think that's a huge advantage for Typescript over mypy, and it's really foundational to the value it provides.

However, even in Typescript it is nontrivial to _annotate_ these complex types, and in most cases it's still possible to do in Python - you just need to commit to using something like dataclasses rather than pretending that what you have is a `dict`.

Basically, to get the most out of static typing in the world of Python, you do have to write more boilerplate than you would in Typescript, and in particular you need to avoid dicts and prefer various sorts of class-based data containers (again, dataclasses, attrs, namedtuples, etc).

edgyquant2• 4 years ago

The ability to slowly add typed code to an existing database has been a lifesaver. I always hated JS because of callback hell (and the notions around its community) but since I started working with typescript my mind has been changed. I love it

civilized2• 4 years ago

not-very-educated thoughts on gradual typing

This seems like an inaccurate and condescending put-down. What is the definition of "educated" in this context? Is there a book or generally well-known resource?

The author is clearly thoughtful and curious. Near the top of the post he says "what I’m hoping for is that someone will come along and tell me that I got it all wrong. “When you do it as follows, the system works: $explanation” Because, you know, I’d really like to have static typing in Python."

1. If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime. However, good news! Python has always been strongly typed, and _does_ enforce types at runtime!

And yet, the author points out that this is a working program:

  foo: int = 'hello'
  print(foo)

In what reasonable sense can Python be said to "enforce types at runtime" here?

ledauphin11• 4 years ago

This one is self-explanatory.

Can a string be printed? Yes! Then Python is (correctly) allowing typesafe behavior here. Your (incorrect) annotation does not in any way contradict the typesafe-ness of printing a string (or an int). They're both equally printable.

This is just a very, very bad example, plain and simple. It 'looks' bad to a superficial reading, but in practice it demonstrates only what is already known about static typing in Python - it is enforced (or not) separately from the interpreter.

the_af44• 4 years ago

I agree with most of your comment, but I think there's a miscommunication problem here.

When Python "enforces types at runtime" this is the actual types, not type hints. Type hints are not a runtime artifact. The "actual type" here is "string", and enforcing it means Python would not allow invalid operations on it without error'ing. A programming language that will let you do basically anything to any value because it doesn't enforce type safety is of course C. Python is safer than C.

ungawatkt• 4 years ago

For 1, there's some unfortunate but important semantics. Python does not enforce type _Hints_ at runtime, as Hints are in many ways fancy comments. But as pointed out, python is a strongly typed language (at least on the sliding scale of strong to weak), and types are known at runtime (call `print(type(var))` to see them). And calling `1 + 'a'` will result in a TypeError exception, unlike say JavaScript.

I believe this is the relavent passage in the article the GP is referencing, which is incorrect if you take "runtime" to mean something like when the line is executed: "Python is a dynamically typed language. By definition, you don’t know the real types of variables at runtime."

It _is_ however correct to say you don't know the real type _before_ runtime, at least python does not.

ImprobableTruth8• 4 years ago

I think the top comment was less polite than it should be, but I would echo that the post seems to have a bit of a weird understanding of gradual typing?

The Any type is to allow incremental typing. You start out with dynamic code, and progressively 'typify' it by adding more and more annotations, with Any working as a stopgap where for the moment no valid type exists, until you finally have a fully typed program. Inserting Anys because you're lazy is like casting things to Object in Java because you're lazy, abusing it like that is just incredibly sloppy and bad code.

If someone is really struggling with this, simply use a linting rule to ban Any in 'mature' code.

sevensor3• 4 years ago

Python enforces its runtime types at runtime. 'hello' is a perfectly valid argument to print. Python will raise a TypeError if you try to use it to index a list though.

woodruffw6• 4 years ago

In what reasonable sense can Python be said to "enforce types at runtime" here?

Python is both strongly typed and protocol-typed. In the case of `print(...)`, the protocol is that the received parameter responds to `str(...)` (i.e., has `__str__`).

(What Python isn't is statically typed. But "strong" and "static" are completely different typing dimensions.)

linsomniac4• 4 years ago

Python can't be said to enforce types at runtime. AFAIK, it doesn't say that. In fact, the original article starts off with "I'm expecting to be able to run a static analyzer", then it goes on to say "This isn't caught at runtime".

Yes, but is it caught at static analyzer run? Yes, I typed it into vi and ran mypy on it and it said "error: Incompatible types in assignment (expression has type "str", variable has type "int")."

But I didn't have to run mypy on it, my editor told me: "Expression of type "Literal['hello']" cannot be assigned to declared type "int"".

Maybe the word "educated" wasn't the right choice in this case, can you offer a better one? I honestly couldn't make it through the entire article, despite several attempts. It is full of inconsistencies and what seem like wilful misunderstandings to justify the authors conclusion.

Particularly as the author starts off saying "run a static analysis tool" as if knowing that's how you go about it, and then saying "it doesn't catch it at runtime".

heavyset_go2• 4 years ago

In what reasonable sense can Python be said to "enforce types at runtime" here?

    In [1]: foo: int = 'hello'

    In [2]: foo + 1

    TypeError
    Input In [2], in <cell line: 1>()
    ----> 1 foo + 1

    TypeError: can only concatenate str (not "int") to str

d0mine• 4 years ago

Don't confuse strong typing and static typing.

Python is strongly typed. It respects types at runtime e.g., `"1"+1` causes TypeError. Python is not statically typed.

For comparison, C is statically typed but it is weakly typed e.g., printf function has no idea about actual types of its arguments (in particular, errors in the format arg may produce non-sensical results silently).

bayesian_horse26• 4 years ago

The "print" function will take any Python object and call its "__str__" method. Not sure if it will do it to a string, but the outcome would be the same.

As far as I remember, the "__str__" method is present on all objects in some form, so print will happily take any type.

smohare4• 4 years ago

Come on. It’s uneducated because it’s just a naive hot take. The education in this case comes from experience and basic understanding of the underlying issues. The author does not demonstrate possessing either of these attributes.

the_af44• 4 years ago

I can only speak about my own experience:

Most people I know writing Python don't use type hints because they are too much of a hurdle for very little payoff. The tooling that pays attention to type hints is slow as molasses or difficult to use or understand. The type hints themselves are of dubious use.

As a fan and advocate of static typing, I find myself advocating for type hints anyway, but I must agree I often can't reply anything to my coworkers' objections, because Python type hints are truly not that useful.

wronglyprepaid5• 4 years ago

The tooling that pays attention to type hints is slow as molasses or difficult to use or understand.

I use mypy daily on big codebases, it is fine, not fast, but fine.

The type hints themselves are of dubious use.

They tell you when you make type errors, they help you understand what type things should be. The same as in literally every other language with static typing. There is nothing special here, nothing different. python with a static type checker running in strict mode is not fundementally different from Java's static type checking.

As a fan and advocate of static typing, I find myself advocating for type hints anyway, but I must agree I often can't reply anything to my coworkers' objections, because Python type hints are truly not that useful.

What do they lack that would make them useful?

seti0Cha3• 4 years ago

Have you looked at the tools recently? LSP + Pyright is very fast and plugins exist for many editors. Or maybe it's slow on larger codebases or very large files? I don't have that broad an experience yet, but so far it's been very good.

hermitdev• 4 years ago

Personally, I took exception to the following from TFA:

Python is a dynamically typed language. By definition, you don’t know the real types of variables at runtime. This is a feature.

In "you don’t know the real types of variables at runtime", this is just flat wrong. One doesn't know the real type of a variable until runtime. It seems to me the author maybe has a bit of confusion between weak typing and dynamic typing here.

edgyquant2• 4 years ago

I get what they mean though. In a typed language you know the type of a variable at compile time. In dynamically typed languages there is nothing to enforce this and a variable can be passed with any type. So there wording may be off but the point stands.

ModernMech2• 4 years ago

"you don’t know the real types of variables at runtime", this is just flat wrong. One doesn't know the real type of a variable until runtime.

I read the sentence as

  "you don't know the real types of variable at [the start of] runtime"

as opposed to

  "you don't know the real types of variable *during* runtimes"

So I understood the author to mean what you said. Could have been clearer you're right.

umanwizard2• 4 years ago

In fact that quote is almost exactly the opposite of the truth. “Dynamic” literally means “at runtime”.

tonyg3• 4 years ago

One doesn't know the real type of a variable until runtime.

In the program

    def x(f):
        return f(3)

what is the "real type" of `f` at runtime; say, at the instant just before the call to `f`? How can you tell?

If your answer is that `f` has type "function-like", then that's a much weaker kind of a type than even type hints offer, let alone a real type system.

theodorejb• 4 years ago

1. If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime.

Counterexample: PHP is a dynamic language which enforces static type declarations at runtime.

ledauphin11• 4 years ago

Meh. you can do the same thing in Python if you really want - there are dynamic interpreter shims that can do this.

The point is that it is not expected by definition, since by definition, static != runtime.

dgb23• 4 years ago

Fun fact: it will still do type coercion in that scenario without strict mode. And you cannot annotate assignments. Otherwise it’s pretty useful.

cardanome• 4 years ago

1. If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime. However, good news! Python has always been strongly typed, and _does_ enforce types at runtime!

So PHP is not a dynamically typed programming language according to you? It enforces type hints at runtime just fine.

There is nothing in the definition of dynamically typed languages that says they can't use type hints to perform runtime checks.

Jach• 4 years ago

Was going to say the same for some implementations of Common Lisp, notably SBCL, which by default treats type declarations additionally as assertions. Subject to limitations it can use declared types and infer more types at compile time to produce more optimal assembly and give warnings if it detects type errors, or interestingly warnings if it has a chance to use e.g. a fast assembly add on a fixed sized int if you help narrow its inferred type with an explicit declaration one way or another. But unless it can prove a type always holds, it will also by default check declared types at runtime.

Matheus28• 4 years ago

you can't do this _at all_ in many statically compiled languages

What statically compiled language doesn't provide a way (sometimes clunky) to have heterogeneous values in a dict? You can do that with void* in C, even

moonchild• 4 years ago

If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime

What definition is that? Raku is a dynamically language with gradual typing which will enforce those types at runtime (if it cannot do so at compile time).

mjn• 4 years ago

If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime.

I don't think this follows by definition. It's common not to check the static hints at runtime, but a dynamic language could choose to treat them as contracts or assertions. Over in Lisp-land, SBCL will enforce static type declarations at runtime [1], contrary to most other Lisp compilers, at least under the default compilation settings (you can force it to skip the checks by compiling with a low "safety" level). If the compiler can prove that a static type declaration always holds, it will omit the runtime check; otherwise it will compile it into a runtime assertion.

[1] http://www.sbcl.org/manual/#Declarations-as-Assertions

grumpyprole4• 4 years ago

can't fully represent heterogeneous values in a dict, given that you can't do this _at all_ in many statically compiled languages.

This isn't really true. For example, in Java it's Map<K,Object>. For languages without subtyping, existential types are often used. It's quite common to see in infrastructural code, e.g. caching.

daenz• 4 years ago

Opinions like these are frustrating because, although they make valid points, it comes off as "they didn't do 100% exactly what I want, so I'm not using them at all." With many tools, there is a middle ground between using them for everything, and not using them at all. Python's type hints is one of those tools.

When I'm writing code, and a variable or signature is easy to annotate, I'll annotate it. And guess what? MyPy occasionally catches issues with my types and saves me some work. If a type is very complex, I won't bother spending time annotating. The end result is that I have some code that is annotated and prevents simple errors, and other code that isn't, and I didn't spend much time or effort doing it. To me, that's a clear net win.

davidhariri• 4 years ago

Fully agree with this. Type hinting (not checking) is idiomatic to Python. MyPy is a great way to enforce checking. It's great to have the option to use the hints for intellisense only.

throwaway815233• 4 years ago

I've found that even when I write code intended to be statically checked from the beginning, mypy often misses stuff. I was enthusiastic about mypy at first and I still use it, but I'm not sure at this point that it is worth it.

the_af44• 4 years ago

Honest question: what's the point of type hinting without type checking?

I must be mistaken, but I always thought "type hinting" was a synonym of "optional type annotations". But if you're not using those annotations for actual type checking at some point, what are they good for?

mejutoco• 4 years ago

My favourite way to enforce types in python is to use typeguard‘s typechecked decorator. It is checked at runtime but it can be added gradually.

https://pypi.org/project/typeguard/

mirashii• 4 years ago

I actually find that mypy is pretty weak and lacking, even within the python ecosystem. pyright seems to do a much better job at the type checking portion of things.

bastardoperator• 4 years ago

For me, I'm not writing huge programs in python, I may not need type hints/safety right away, or at all, not that I'm against them in any capacity. The problem I see with opinions like these is the assumption that type checking/hinting/safety are a silver bullet.

OccamsRazr• 4 years ago

Yup.

Despite all that, what I’m hoping for is that someone will come along and tell me that I got it all wrong. “When you do it as follows, the system works: $explanation” Because, you know, I’d really like to have static typing in Python.

I want X. Y (which is designed for somthing other than X) doesn't do X. Thus, I don't like Y.

patrick451• 4 years ago

Letting perfect be the enemy of the good is not the same thing as doing a cost benefit analysis. In the authors estimation, the costs outweigh the benefits. You don't seem to be considering the cost of type checking at all.

just-ok2• 4 years ago

Despite this:

Even if the Python runtime did check all the type hints at runtime, then it would still be too late. I don’t want a fancy type exception at runtime. That already exists (most of the time). I want to know about type mismatches in advance.

You should check out Typeguard [1], which lets you add a @type_checked decorator to anything and get runtime type checking that's far better than e.g. a random blowup when you split() on an integer. It does introduce a significant amount of overhead, but it's still useful during development alongside type hints to avoid some of the pitfalls from this article.

In another vein, Any should definitely be used sparingly. For the foo() function outlined in the article, Union[str, int] offers more precision. In fact, you could even argue that using Any is a code smell.

Overall, though, I agree with most of the sentiment in this article. I find myself using type hints more as documentation than anything else, since their true ability to prevent type-related runtime bugs is very limited. Documentation has the same qualms the author outlines, anyway:

You can not be sure that they are correct. [...] They waste mental energy when reading code, they create new maintenance burdens, and they are potentially deceiving: You cannot trust them.

But they're still slightly better than docstrings...

[1] https://typeguard.readthedocs.io/en/latest/userguide.html

riyadparvez• 4 years ago

There's also bear-type for runtime type checking: https://github.com/beartype/beartype.

pydry2• 4 years ago

I've been perplexed as to why this hasnt been built in to the python runtime since day 1.

captainmuon2• 4 years ago

Do you know if there is a way to do runtime type checking in the whole program with typeguard, beartype or something else? As far as I know you have to go through and add decorators manually. Typeguard had a profiler hook that almost got it right, but is being removed. Ideally I would want to say 'python3 -m typecheck myprogram.py' and it would run typechecking everything in my code (but maybe not in library code).

just-ok2• 4 years ago

I believe you're describing MyPy? http://mypy-lang.org/

IshKebab3• 4 years ago

Yeah they're pretty bad but they are still better than nothing. If you are in the unfortunately position of having to use Python I would recommend using them.

I would also strongly recommend using Pyright (the default checker in VSCode) over MyPy. It's so much better, and the author is really responsive on Github.

But yeah, in general trying to use type hints in Python is like trying to discuss philosophy in a mental asylum.

ActorNightly2• 4 years ago

The whole reason Python and JS surpassed most all other languages is specifically because you can write code fast, without worrying about strict definition of data structures.

The issues with python code bases aren't from a lack of strict typing or type support, but from a lack of a good testing framework.

IshKebab3• 4 years ago

JS is popular because it's literally the only language web browsers support.

Python is popular because it's very beginner oriented, so it's the first language a lot of people learn. It's modern BASIC.

Neither of those things mean that writing dynamically typed code is a good idea. The idea that you can write dynamically typed code faster isn't even true once you get past a couple of hundred lines.

raverbashing2• 4 years ago

Type hints work fine. They are hints (that are checkable through tools)

But as a general rule: You don’t know if there really is a tool in place to check them.

Cool. So you just go and do stupid stuff if no one is looking?

Check it yourself. They're probably there for a reason. If you think they're not needed, then sure, take them out.

Most of this turned out to be wrong and it threw me off the track during my debugging session.

Here's an idea: Then why don't you fix it. If I see code that's wrong or bad, I go and fix it. It's your responsibility as well

Now maybe try acting like they're anything but type hints (and I'm very glad Guido insisted it is optional and flexible - the last thing the world needed is for Python to get consumed by Java type checking pedantry where the compiler needs you to annotate every single thing)

And every time I do something in Python that would be "impossible" in Java I'm glad I'm not bound by the small-minded type pedantry of Java.

wvenable• 4 years ago

Can't you just type something as `object` in Java and make anything possible?

raverbashing2• 4 years ago

It might be possible for some cases, yes. But not for function pointers. And you don't get duck typing.

tsupiroti• 4 years ago

I find it reasonable that Python doesn't enforce the type checking. The owners of each project can choose how much to enforce it and how.

Defining such style rules and validations is necessary with almost every language. A codebase where developers are allowed to use any C++ feature or browser API will become very messy as it grows.

nickysielicki• 4 years ago

Yes, they lack teeth. But what’s the alternative?

* fork the language again? We just got out of Python2 hell.

* Docstrings, like we had before they were introduced?

They won’t catch all bugs, but with minimal effort they’ll catch some bugs, and if you make an effort to really dig in, it’ll catch most bugs. To me, to accomplish that overnight on a language with millions of existing lines, that’s a big win.

wronglyprepaid5• 4 years ago

Yes, they lack teeth. But what’s the alternative?

In what way do they lack more teeth than Java with Object, Go with interface{}, C++/C with void*?

reikonomusha12• 4 years ago

Idiomatic C and Go programs aren't labeling everything with those types, and the language implementation enforces those types at compile time.

Since types are optional in Python, it's necessarily true that an "Any"-like type is prioritized since it's the default. Moreover, cpython doesn't check anything when it bytecode-compiles.

Any-by-default and no-built-in-checking feels pretty defanged to me.

NewEntryHN• 4 years ago

TL;DR: type hints are a disappointment to me because they're only hints.

POiNTx• 4 years ago

Don't let perfect be the enemy of good. Type hints are usefull especially in large codebases. I find myself using them with minimal effort and they can catch bugs that otherwise wouldn't be catched.

mindwok• 4 years ago

Exactly. The article has some valid criticisms of the weirdness of type hinting, but type hinting is a pretty large paradigm shift added to a 20+ year old language. Yes it will have shortcomings, but in my opinion has made working with large Python codebases actually possible. It’s a good thing.

goodoldneon8• 4 years ago

Totally agree. Mypy isn't perfect but it's so much better than no type annotations

nine_zeros13• 4 years ago

In my experience, people with less experience with object oriented programming will end up creating lots of objects only to create types. These objects have no business use case, nor do they aid in any encapsulation. These objects are made just to help typing. Nuts!

Python type hinting is like moving backwards in time because the amount of time devs take to "hint", takes away the main reason for using python, that is faster development. Might as well code in Java at this point.

noitpmeder3• 4 years ago

This has to be a troll comment. The overhead of typing is literally _nothing_ compared to the amount of time it takes to sift through code to figure out

a) what types a function/class accepts as arguments and b) what types are returned.

If you don't check it then I agree it's useless. However, working with libraries that are typed is an _insane_ productivity boost over working with untyped libraries.

ReflectedImage3• 4 years ago

Typing in Python is generally a code smell.

Typing encourages a large number of bad coding practices. If you can apply typing to a Python program then you are not taking advantage of the dynamic nature of the language to write simpler and shorter code.

In Python world, unit tests cover what is normally handled by typing.

nine_zeros13• 4 years ago

This is a snippet from the python codebase, written by a type nazi

SessionInfoType = Union[AuthzQuerySessionInfo, AuthnReqSessionInfo]

Notice how it is doing a union of two objects. Do you know what those 2 objects are? Those are types as well. They have no business use case.

AuthzQuerySessionInfo = TypedDict( "AuthzQuerySessionInfo", {"name_id": Any, "came_from": Any, "issuer": Any, "not_on_or_after": Any, "authz_decision_info": Any,}, total=False, )

AuthnReqSessionInfo = TypedDict( "AuthnReqSessionInfo", { "ava": Union[dict, None], "name_id": Any, "came_from": Any, "issuer": Text, "not_on_or_after": Union[int, bool], "authn_info": list, "session_index": Any, }, total=False, )

RequestCookieType = TypedDict( "RequestCookieType", { "request_id": Text, "came_from": Optional[Text], "public_id": Text, "is_mobile": Union[Literal[True], Text], "c_challenge": Text, "c_challenge_method": Text, }, total=False, )

So now. not only do we have dicts that represent above data, we also have TypedDicts created specially for types.

To rub salt on the wound, the callsite with these types now looks like

session_info = authresp.session_info() session_info = cast(SessionInfoType, session_info)

WTF!! If we have to see a codebase littered with TypedDicts just to satisfy type annotations and then have to cast everything to that type - why not just wrap it in a class and call it a day?

When I see garbage like this, I seriously question the productivity improvement brought about by python type annotations. I certainly end up spending an inordinate amount of time unraveling nested unions of types all over now. Considering switching to a team that uses Golang.

bb883• 4 years ago

It feels really good to see a program compile without warnings or errors. You then know that you got it right.

I don't know about that. So many C/C++ programs have core dumped in my life and needed to be valgrinded to debug memory issues, or went past the bounds of a pointer, or overwrote the stack, or... whatever.

And you still don't get correctness without unit tests.

I'm not saying types aren't valuable, but they're not a crutch to program correctness like people seem to think they are.

albertzeyer• 4 years ago

Just the type hints were wrong.
warnings of IDEs are simple to ignore

This is unusual. In my experience, of codebases I have worked with or have seen, when there are type hints, there are almost all perfectly correct.

Also, you can setup the CI to check also for IDE warnings. For example, we use this script for PyCharm: https://github.com/rwth-i6/returnn/blob/master/tests/pycharm...

The test for PyCharm inspections only passes when there are no warnings.

Although, I have to admit, we explicitly exclude type warnings because here we have a couple of false positives. So in this respect, it actually agrees with the article.

But then we also do code review and there we are strict about having it all correct.

Yes, I see the argument of the article that the typing in Python is not perfect and you can easily fool it if you want, so you cannot 100% trust the types. But given good standard practice, it will only rarely happen that the type is not as expected and typing helps a lot. And IDE type warnings, or mypy checks still are useful tools and catch bugs for you, just not maybe 100% of all typing bugs but still maybe 80% of them or so.

Isn’t it better to detect at least some errors than to detect none at all?
You can not be sure that they are correct. As such, you must always treat them as if they were wrong.

I don't get this argument. Isn't this the case for all other code as well? Most code has not been formally verified to work 100% correct. So you assume always all code is wrong? This doesn't make sense.

They [type hints] waste mental energy when reading code

How? The author even acknowledges that you could just treat them as code comments if you like. By that argument, all code comments waste mental energy?

throwaway815233• 4 years ago

I don't get this argument. Isn't this the case for all other code as well? Most code has not been formally verified to work 100% correct. So you assume always all code is wrong? This doesn't make sense.

It isn't that you have to assume the code is wrong (you always have to assume that code is wrong). It's that even though you write type hints and they pass mypy, you still have to assume that the code has type errors. That is, mypy doesn't rigorously check that the program's types match its annotations. It only approximately checks that.

In (some) other languages, the type checker is 100% sound, so if your program passes type checking, you can be completely sure that the types all match. Opportunities for the code to be wrong are thus limited to mismatches between the types and the desired behaviour.

ZoomZoomZoom• 4 years ago

What I want is this: Some language that’s as easy to use as Python and it should be compiled and with good static typing...

Well, there's always Nim. [0]

...but it should also not be compiled because then it wouldn’t be as easy to use as Python anymore. Whoops?

Eh, there's Nimscript? [1]

0. https://nim-lang.org/

1. https://nim-lang.org/docs/nims.html

PMunch• 4 years ago

Not sure what the compiled != easy to use bit comes from anyways. If anything I'd say that part of Nim makes it easier to use, I don't have to worry about whether or not the target has Python installed.

MrJohz• 4 years ago

As someone who's very used to Typescript, I find these complaints very interesting, because they're often common for Typescript newcomers as well. However, I think they - quite understandably - misunderstand the purpose of these tools, and so get disappointed when the tools don't do what they want or expect.

I think the traditional view of types is that they're about declaring something to do with the memory layout of a particular variable. Maybe not always directly, but I think most people have this kind of intuition that an int is an int, a string is a string, a struct is a struct (and a particular, explicit one at that). In Java with subtyping, things get a bit more complex, but it's usually fine.

That's generally not a good way to approach Typescript/mypy. Typescript, for example, is absolutely unconcerned with whatever value lives inside a particular variable. It's very possible in Typescript to create types that can't even ever exist at runtime (type brands are a good example of this). The compilation process for Typescript is basically just stripping the types away as if they were comments, and leaving the Javascript behind.

What Typescript is is a slightly more complicated linter that requires annotations. The types you put in are basically just labels. When writing Typescript, your goal is to give every type a label, and then run a program that tells you if all of those labels are compatible with each other. If there is a label mismatch (you've used label "number" but you've done operation "push" on it) then the linter will simply tell you you've done something wrong. Moreover, these annotations can be very loose - annotate something as `any` (or `Any` in Python) and the linter will accept anything done to it. This means that you can always break free of the linter and tell it that you know best (which is true - it is probably impossible to statically validate whether a given Javascript program will throw an error or not, so any linter will have some cases where it prohibits a valid program - the programmer requires the power to override the linter).

Viewing Typescript and mypy in this context helps a lot, I find. It explains why casting doesn't throw runtime errors (a cast is simply a lint annotation saying that a particular expression has a particular label). It explains why JSON isn't validated when it's parsed (you're just starting that the data has a particular label/shape - it's up to you to ensure that that's true, but you can do that check however you like, including not at all if you're very confident in the quality of your data).

This raises the question about which process is better: one where types get transformed into real data structures where all code is kept valid at runtime, or one where the types act only as assertions for a linter validating whether the code ought to remain valid. In my experience, a lot of it depends on how valuable you find the dynamism in languages like Python and JavaScript. If it's very important for you, then traditional typechecking approaches are probably not very viable because no static type system can ever cover all correct Python programs. However, levels plus a linter will resolve most programme correctly, and still give the necessary overrides to allow for other options.

So when it comes to the questions in the article, I think the author would do a lot of good to approach Python type hints from the perspective of a linter that requires annotations.

phailhaus2• 4 years ago

Python's type system is a disappointment, but I don't think this article does a great job of explaining why. My biggest gripes:

1. There is no way to get typing like dataclasses without writing your own mypy plugin. The syntax is simply not expressive enough to do it. This means that if you want to be productive with a library like Pydantic, you also have to add the mypy plugin to your dependencies and add it to your mypy config. Otherwise, no typing.

2. You cannot compose types. There is no way to say "hey this type is the same as this dictionary here, except the keys are all optional." If you're trying to type a RESTful API, your only option is to repeat yourself and carefully keep all your types in sync.

3. To this day, there is still no way to express optional keys. Not "Optional" keys, but keys that can be left out of your dictionary. The closest you can get is this weird hack where you can set `total=False` in your TypedDict, which makes all keys optional.

I really wish Python learned from Typescript, but it's too late at this point. Too many half-baked measures have already made it into the spec.

kirbyfan64sos• 4 years ago

There is no way to get typing like dataclasses without writing your own mypy plugin. The syntax is simply not expressive enough to do it. This means that if you want to be productive with a library like Pydantic, you also have to add the mypy plugin to your dependencies and add it to your mypy config. Otherwise, no typing.

This would be solved by PEP 681, which originates from (and is already used in) pyright: https://peps.python.org/pep-0681/

3. To this day, there is still no way to express optional keys. Not "Optional" keys, but keys that can be left out of your dictionary. The closest you can get is this weird hack where you can set `total=False` in your TypedDict, which makes all keys optional.

This is solved by PEP 655, which introduces NotRequired: https://peps.python.org/pep-0655/

It's implemented in mypy 0.930: https://mypy-lang.blogspot.com/2021/12/mypy-0930-released.ht...

I really wish Python learned from Typescript, but it's too late at this point

Personally, I feel like it's partly just entirely different styles: Python relies on a mix of nominal and duck types, whereas JavaScript is much more focused on structural typing. As a result, there are a lot of things like TypedDict that are absolutely essential for JS to even function but a decent bit less so in idiomatic Python code (keeping a significant amount of dicts around uses much more memory than objects, I recall a PyCon talk explicitly mentioning this too).

meatmanek• 4 years ago

Even without NotRequired, you've been able to have some-keys-optional-and-some-keys-required for a long time by putting the required keys in one TypedDict, then adding the optional keys in a subclass with total=False: https://mypy.readthedocs.io/en/stable/more_types.html#mixing...

It's not exactly elegant (hence PEP655), but it works just fine.

RhysU2• 4 years ago

If you have a dictionary with heterogenous, optional keys then I believe you have a struct-like class. If you have any constraints on the keys beyond a homogeneous domain and a homogeneous range then you have a struct-like class.

phailhaus2• 4 years ago

Avoiding classes has a couple of benefits:

1. It reduces the overhead to use your interface. Your users don't have to import your struct classes, and can just pass in bare dictionaries. If Python's typing was more effective, these dictionaries would also be type checked to make sure you're calling the library's APIs correctly.

2. It deliberately closes off the option of adding state or initialization logic. Classes let you do way more than just encode a struct, and as a codebase grows they have a tendency to become more complex just because they can (like a gas filling its container). This makes APIs harder to maintain and work with. Sometimes, all you need is "raw structs".

goodoldneon8• 4 years ago

Agreed. Also, Mypy's dict inference is too broad, making TypedDict a little less useful. For example, the following code raises a Mypy error even though `foo` conforms to `Foo`:

  import typing
  
  class Foo(typing.TypedDict):
      a: int
  
  def do_thing(value: Foo) -> None:
      return
  
  foo = {"a": 1}
  
  # error: Argument 1 to "do_thing" has incompatible type "Dict[str, int]"; expected "Foo"
  do_thing(foo)

But TypeScript can figure it out:

  interface Foo {
      a: number
  }
  
  function doThing(value: Foo): void {
      return
  }
  
  const foo = { a: 1 }
  
  doThing(foo)

bayesian_horse26• 4 years ago

This is a misunderstanding of the Python type system. In the Typescript example you are depending on "foo" being structurally compatible to the "Foo" interface.

In the Python case, "foo" and "Foo" might look structurally compatible, but they aren't. "Foo" isn't just a type, it's an object of type "class". You can for example print(Foo), you can't console.log(Foo). "foo" is not an instance of the Foo class. What you are looking for is "dict[str, object]".

ledauphin11• 4 years ago

I'm a big fan of mypy and static typing as a concrete improvement to Python, but this criticism is so superior to the original article that all I can say is bravo.

Typescript's type system, of course, had and has the advantage of being a clean sheet design with an intermediate compilation step, so the comparison is hardly apples to apples. But there's no denying that I wish frequently that Python could have opted for a more powerful static type system.

xarope3• 4 years ago

I'm surprised there's no mention of pydantic or other type systems. I started with type hints, and find that the discipline of using types invaluable, especially when coding public API backends for which validation is a strong necessity, whether semi-static (ala mypy) or runtime.

wronglyprepaid5• 4 years ago

How is a grype with static typing that it is not enforced at runtime? This comes up like once a week, have these people never used statically typed languages?

The fact that you can put nonsensical types wherever you want and still get a working program has consequences.

Working is questionable, but nothing in C++ prevents this at runtime either, nothing in JVM prevents this at runtime, static typing is not runtime typing, it should not be, it is not the USP.

There is an Any type and it renders everything useless

Java has object, C++/C has void*, Go has interface{} - none of these render the type system useless, and Python's type system makes it a lot easier to write correct code than Go's type system or C's type system.

shultays• 4 years ago

Difference between any and object, void* and interface{} is you can't really do anything with the second. Sure you can store something on an "object" type but you need to cast it back to do anything which discourages usage of it (and add runtime checks, usually)

While in python you can mark something as "any" and continue using it as is.

dataangel• 4 years ago

Mypy checking is actually really good, and you can give it flags to make it super strict. Setting it up in CI is the same work as setting up any other linter. The only fault I had with it was 3rd party libs not providing hints often enough.

smu3l• 4 years ago

What is the precise definition of static typing? Both the article and many comments in this thread refer to static typing or static type hints in Python. But as I've always understood it, static typing means that types are checked and enforced at compile time. And if python is not compiled, the notion of static typing in python does not make sense. So do I have it wrong? Or is the term ambiguous?

ledauphin11• 4 years ago

static in this case can be understood to mean simply "prior to (or separate from) runtime". In other words, it's based on what you can check _without_ running the code.

It's worth noting that nearly every statically-typed language currently in existence has two separate "type systems" - the static type system which is the formal type system offered to the programmer, plus a runtime type system enforced, at minimum, by the processor (e.g. you cannot divide by 0) that is ultimately different from the static type system. The 'question' in most cases is "how closely does the runtime type system match the static type system?" In many if not most languages, the answer is "not very".

tialaramex• 4 years ago

It's worth noting that nearly every statically-typed language currently in existence has either two separate "type systems"

Either that or... ? You should probably complete this thought.

I don't think the distinction you've claimed make much sense, but perhaps you had an alternative which you just never explained.

reikonomusha12• 4 years ago

Python is compiled, just not to machine code.

LAC-Tech• 4 years ago

Did the mypy task in your build pipeline silently break?

Haven't used python in years... you have build pipelines now?! Why? Javascript refugees who can't shake their webpack stockholm syndrome?

abalaji• 4 years ago

I don't think the OP was referring to build pipelines, but rather continuous integration pipelines. Build in the sense: lint, install deps, and run tests.

rurp2• 4 years ago

After working in Python without type hinting for quite some time before joining a team that uses it heavily, I was pretty skeptical about how useful it would be give the many rough edges I had read about. After using both approaches for a while I think that type hints are both very flawed and surprisingly useful.

Yes MyPy and type hinting in general has many limitations, rough edges, and occasionally baffling behavior. Despite all that, I think it is helpful for pretty much any Python project. Type hinting does catch a lot of potential issues and the syntax is very simple. I tend to fill in the types even on a first pass at some code since they help so much in tracking various interactions.

I think the bottom line is that something doesn't have to be great in order to be useful.

Humphrey2• 4 years ago

While I love the idea behind Python's type hints, they are merely a shadow of the success of TypeScript.

Like the author, I've mostly given up on adding type hints in my Python code. I now only use them when I want to help my IDE find autocomplete suggestions.

Whereas TypeScript was a game changer for JavaScript. I used to hate JavaScript, but somehow TypeScript has become one of my favourite languages! How has the advent of Typing has changed my opinion on these two very similar languages?

- JavaScript without types is a mess, whereas Python comparatively was much better, esp since it does runtime duck type checks.

- Python type hints are much similar to Flow type hints in JS, which I tried, but ditched for the same reasons as Python type hints.

- I was hesitant to try TS's all in approach, cause it was harder to introduce into a project, but after having converted a number of projects to TS, I can see that going all-in is a much better approach than just adding hints as you go.

- TS does checks at many more levels. Eg, if a property is optional or could have different types, it is a syntax error if I don't check the value is valid before use.

- TS does an amazing job of auto-detecting types, so most of the time you don't need to specify types, and it enforces these just as if you declared them.

- TS has reached the critical mass were most popular packages now include type definitions, I very rarely have to add @types/* anymore. This means you get full intelisense on all 3rd packages! I spend a lot less time referring to documentation now!

In hindsight, compiling out types is a great work flow. TypeScript is so good that it has made me enjoy Python less. If there was ever a Python equivalent to TS which reached a critical mass of support, I'd jump all-in in a heartbeat.

Frotag• 4 years ago

This is exactly my experience. I've also found that Python's type annotations for even basic stuff like are way clunkier to write.

For example an optional requires a typing.Optional import or a an ugly "| None" instead of a question mark like TS has. And good luck trying to annotate some complex / nested json, you'll need a bazillion intermediary classes.

goodoldneon8• 4 years ago

There's a subtle difference between TS' question mark and union. The question mark means "this argument is optional", which can be different than "this argument can be undefined".

The following code is valid:

  function foo1(value?: number) {}
  
  foo1()

But the following code will raise a type error:

  function foo2(value: number | undefined) {}
  
  foo2()

In practice, that rarely becomes problematic. But it's good to know the difference

hannofcart• 4 years ago

To be fair, you're comparing a static typed language that transpiles to JS with a type annotation system for a dynamic lang.

Pylint is closer to Flow than Typescript.

Humphrey2• 4 years ago

Oh of cause -- and I suspect TS only became so good because it had the freedom to be a new language.

remram• 4 years ago

The fact that we can't have a type for JSON really does make it look like a toy.

ImprobableTruth8• 4 years ago

This is (for now) a limitation of mypy, not of the type system. Pyright and Pyre both can type JSON since they support recursive type aliases.

ok1234562• 4 years ago

Use pydantic then. Then you get type checking and validation for your json blobs.

bayesian_horse26• 4 years ago

In my opinion type checking in Python is a lot less necessary, which throws off the cost/benefit calculation. And the cost/benefit ratio also varies with the size of the codebase, team and other things.

Let's emphasis the "gradual" part. The more libraries are carrying type annotations, the more helpful IDEs will be and the easier it is to type-check your own code.

fulafel• 4 years ago

The realities of the browser platform have indeed created a unique environment where many nice languages have appeared that compile to JS. Besides TypeScript there's Elm, ReasonML, ClojureScript, and many more.

There are a some competing languages for the Python runtime as well: https://github.com/vindarel/languages-that-compile-to-python

TomBombadildoze• 4 years ago

There are many complaints in this discussion about inaccuracies in the post but you've actually captured the essence of the problem--type hints just don't solve the problem well.

My team began using type hints and aggressively applied mypy to new code starting a couple years ago and it _has_ helped immensely. However, we also started doing some work in Typescript around the same time and the difference in developer experience and code quality is pretty clear. Typescript is just a better solution to the problem of adding type information to a dynamic language.

What's especially frustrating is living through the design and early life of asyncio (Guido, you should have adopted the gevent model), then getting excited about typing, only to find it is also not very good. What's _especially_ frustrating is that Typescript existed two years before PEP 484 was published, so the core developers had ample time to seek inspiration elsewhere, and they came up with a sub-standard solution.

Python needs a Typescript analogue, with a compiler that targets vanilla Python.

Animats• 4 years ago

That's about what I said when the idea was first proposed. Actual type declarations, both enforced and used to guide code generation and optimization, would be fine.

Part of the problem is that, in the minds of many, Python == CPython. PyPy, which is a real compiler, is viewed as "nonstandard". For PyPy, type information, although not in type hint form, would be useful. But type hints, as currently defined, are not. See the commentary on type hints at [1].

[1] https://doc.pypy.org/en/latest/faq.html

simonw• 4 years ago

"You don’t know if there really is a tool in place to check them."

Every project I interact with that uses type hints runs mypy as part of CI - and I can see that they're setup to do that by looking at the CI configuration (which these days is usually done using GitHub Actions).

I wouldn't add type hints to a project without also configuring mypy for it.

sevensor3• 4 years ago

Precisely. We don't merge unless the result passes mypy.

Bedon2926• 4 years ago

We use pre-commit and you can't even commit until it passes mypy. It can be a bit frustrating sometimes, but overall it has saved us from a lot of issues.

Diggsey2• 4 years ago

I work on a project that uses type hints but not mypy. To be fair, we used to use mypy, but there was just too much code that it couldn't check (sqlalchemy models, schematics models, some custom models, essentially lots of different data-modelling types!) Maybe it's improved since then, but it just wasn't mature enough at the time.

However, type annotations still make the code so much easier to work with, because they serve as documentation and are understood by the IDE. When I hit "." I actually get correct autocompletion because of the type annotations. When I want to know what a function returns I don't need to dig through multiple levels of function calls.

The article seems to be suggesting that because the type annotations might be wrong that they are worthless, which seems like a ridiculous argument. Any documentation can be wrong, but clearly having documentation that is 99% accurate is better than not having it at all.

nas2• 4 years ago

I've found that it's pretty easy to slowly enable mypy checking. You can mark modules with "type:ignore" to make mypy ignore them. Then, you can move to marking individual statements with "type:ignore". Finally, you can start marking modules with "mypy: disallow-any-generics" at the top. That requires that functions are annotated with types.

In a large code base, our team has found type annotations and mypy to be quite helpful. If you are writing a quick-and-dirty script, forget about wasting time with type annotations. However, for long-lived and important code, it seems to be worth adding the types.

Another thing I noticed, if your type annotations are hard to write, e.g. lots "Union", "Optional" or deeply nested type expressions, it's probably a sign that your code is poorly designed. Think about what types you actually want to consume and return. Define new containers using dataclasses or attrs to keep the types simple, if required.

Bedon2926• 4 years ago

There are still a lot of libraries without hints, so mypy has to be told to ignore them in the setup.cfg file. Last I checked, sqlalchemy still isn't so good with mypy. So we have it ignored. But mypy is still great overall.

evrydayhustling• 4 years ago

Yes. The reason type checking is separate from the interpreter is that python is an ecosystem, not a language. Even if you like static typing, 99% of projects benefit from other code that lacks typing. Type hinting puts you in control of where types are enforced while allowing you to use duck-typed code. The cost is that you have an extra step in your build chain - but CI, IDEs and other automation all but negate that cost.

oefrha2• 4 years ago

MyPy isn’t the only checker of course, there’s also Microsoft’s Pyright, among others. Pyright is fast and natively integrated in Microsoft’s Pylance VSCode extension, so these days I use Pyright’s type checking in real time even when I can’t be bothered to set up MyPy (no difficult, just not important for, say, <1000 line scripts). I default to strict mode for stuff that’s not too dynamic.

https://github.com/microsoft/pyright

https://marketplace.visualstudio.com/items?itemName=ms-pytho...

gorgoiler2• 4 years ago

I never liked how go makes you fix all your types before letting you run a program.

Suppose I wanted to hack something up and run it, just as a new idea? Maybe change a library function that is called in 20 places, but I only want to test it in one call site. Nope! Go forces you to polish up your turd of an idea in all 20 call sites before you can see that your algorithm / model / refactoring is nonsense. If you back out of the idea then all that turd polishing was a waste of time.

The mypy-python workflow, on the other hand, lets me write my nonsense, see that it was a bad idea, then throw it away without eating up more time than I needed to with satisfying all the type checking ceremonial stuff. Much nicer. It’s a linter that follows the “make it work, then make it right, then make it fast” iterative workflow that I’m used to.

Alas, I suppose if I wasn’t an imposter in the programming world, I would be able to dream up my changes and think them through in my head properly before committing them to my text editor. Maybe I wouldn’t even need to do that because my ideas are just great all the time instead of 50/50 between ok and terrible. I’m not smart like that, and it felt like go went out of its way to rub it in.

Maybe I used go wrong. I haven’t touched it in a decade. Is there a “hey ho your types are all out of sync but let’s try and compile anyway” option?

lolinder3• 4 years ago

There's a big difference between Python's types and and Go's: in Python they're only there to check correctness while in Go they're there to tell the compiler how to lay out the machine code. If the compiler ignored types in Go it wouldn't just throw an error message at runtime, the behavior would be completely undefined.

gorgoiler2• 4 years ago

That’s interesting.

The hacky-developer option I’m after is the ability to cull pieces of code if they do not type check, I guess.

valcron10002• 4 years ago

The only compiled language that I know that supports this kind of development is Haskell by enabling '-fdefer-type-errors'

bmn__• 4 years ago

Is there a “hey ho your types are all out of sync but let’s try and compile anyway” option?

"typed holes" in some programming languages

lolinder3• 4 years ago

Typed holes are slightly different: they allow you to write the types but not the code.

ironman1478• 4 years ago

This article has a really strange tone. For example, there is this section "There is an Any type and it renders everything useless". Yeah, so does C with (void*). Just because somebody is abusing a tool doesn't mean the tool is wrong. Any is valid with dealing with a dictionary type that is deserialized from some file. If somebody is just injecting Any into their code because they don't know what they are doing, educate them.

The takeaway that type hints are worse than doing nothing just doesn't comport with my experience where the type hinting has caught very legitimate subtle bugs one code that was infrequently used. I wonder if the author would make the same argument for TSAN, UBSAN, or ASAN? Coverity? Or other annotation systems that help outside of the compiler? These tools are godsends, but do have false positives if their scope is understood.

awinter-py• 4 years ago

possibly orthogonal, but fastapi's use of type hints to parse params + payloads for REST is life-changing

with the exception of some edgy form / upload issues, it's been bulletproof for me

fastapi feels like something the universe wanted to exist and type hints are a natural DSL for it

sevensor3• 4 years ago

The way to think about gradual type annotations is not like types in C. You're not saying "this variable is 8 bytes that we're going to interpret as a floating point number." What they do is let you express constraints on the behavior of your program, and then run another program to check whether those constraints have been violated.

Suppose you start with the function

    def foo(bar, baz):
        if bar > baz > 0:
            return bar / baz
        return "bar is not bigger"

And this is what you want the function to do, for some reason. But by the time you start writing other code, you've forgotten about the unusual "bar is not bigger" case, and you just assume you're always getting a number back. This could turn into a runtime exception somewhere else in your code because a field in some object somewhere now has a value of the wrong type, but you've never run into it so you don't know about the ticking time bomb.

Now you start adding type annotations to foo:

    def foo(bar: float, baz: float) -> float:
        ...

And when you check the types, mypy yells at you, and you realize you actually need to write this:

    def foo(bar: float, baz: float) -> Union[float, str]:
        ...

At this point mypy starts informing you about all the places you failed to handle the "bar is bigger" return value, and you go and fix them. You keep going until all of the constraints you've put on your code are consistent. You don't have to completely type everything for this to be useful, nor is it particularly important to check this stuff at runtime, because all mypy is doing is telling you that the code you've written satisfies the assumptions you're telling it about.

ModernMech2• 4 years ago

This is the kind of thing that happens when a language that used to be niche starts gaining more widespread use. People from other languages come along and want the niceties they enjoy to exist in the new language they are learning. The same thing happened to JavaScript; it used to just be a browser language for running scripts, and then it turned into a server side language with a module system and everything else. There were a lot of growing pains involved in that transition.

Now people who use other languages are coming to Python and thinking "Wouldn't it be great if..." and that's how Python the language is going to evolve. But we're going to have to go through this interim phase of awkward adolescence before type annotations mature as a feature.

czardoz• 4 years ago

This article captures a lot of the rationale behind why we're building Static Python within Cinder: https://github.com/facebookincubator/cinder#static-python

linsomniac4• 4 years ago

Honestly, I've recently written a few 300-500 line programs in Python using type hints and I'm never going back. And I'm not even using mypy often, if ever.

My editor now has a fairly deep understanding of my code, and can tell me of all sorts of surprising errors I'm making before I run the code. There have been a few times where I found an error, went into the editor and saw I had missed a error message about that line. Shout out: Using LunarVim with LSP and TreeSitter.

The other thing I'm enjoying is that libraries can use them to make things happen more automatically. I believe it was Typer (the CLI argument parsing library) where if you declare an argument to a function as "files: List[Path]", it understands that the argument will take one or more files, or "-" to mean stdin. If you just say "file: Path", it understands it is a singular file.

I was curious about type hints when they first came out, wasn't really expecting to use them but they seemed cool, but now I'm totally sold.

totony• 4 years ago

My editor now has a fairly deep understanding of my code, and can tell me of all sorts of surprising errors I'm making before I run the code.

I agree this is useful, but to me the most useful feature of types are the self-documentation. It's crazy the difference between a non-typed library with shitty documentation vs a typed library with shitty documentation.

kadoban3• 4 years ago

The types on stitty-documented code often do depend on the types actually being checked though. Otherwise you need to author to be diligent in their types, but if they're bad in their other docs, that seems unlikely.

pvillano• 4 years ago

type hints are documentation, and machine readable documentation to boot!

np_tedious• 4 years ago

I'm not even using mypy often, if ever.

Hopefully your CI does?

linsomniac4• 4 years ago

Not yet, but that might be coming. I have one personal project set up to run mypy as a pre-commit, but I'm not (quite) ready to force that on my coworkers.

Spivak8• 4 years ago

It's not really as necessary as you think -- making mypy/pyright pass your CI ends up being a lot of busy work to make the type checker happy when, to me, all the value is realized when it's used as a development aid. If your test suite passes that's honestly more than good enough.

gkhartman• 4 years ago

I use them for the same reason. I've started sprinkling them into projects where I can. Other devs on the team seem to like seeing them, but have higher inertia when it comes to writing them.

mountainriver6• 4 years ago

Not typing is kinda a crazy way to write programs when you think about it. It can be beneficial in certain niche use cases like data science where code is always terrible. For everything else, types are a huge boon for the developer and everyone consuming their work

waitlist• 4 years ago

I think data science is a perfect example in favor of types -- the code is often terrible because of the lack of typing. Pandas has notoriously poor developer ergonomics, and I recall painfully poring over type errors across the board -- lists, dataframes, numpy arrays, etc. are all iterables, so they can be interchanged in some contexts, but not in others.

Had I had MyPy back when I was working in data science, I would've saved countless hours and headaches.

bayesian_horse26• 4 years ago

Have you tried it? Python has gained most of its popularity before type hints, and I would (wildly) guess 99% of Python programmers don't even use type checking at all.

Static typing is completely viable and I hear those arguments mostly from those who didn't use Python for a long time. The added productivity makes up for a little more debugging while the program is running.

I'd also posit that many Python codebases are somewhat less "untyped" than one might assume. Django for example does a lot in its ORM and Form classes to make sure the right stuff goes in the right slot.

antipaul• 4 years ago

As a data scientist, you make a strong point.

For me, python is mostly a calculator, and it seems faster to try a calculation and immediately see if it runs and/or looks correct, rather than try to implement type hints et al (though I still use type hints occasionally).

eweise3• 4 years ago

Totally agree. I'm on a project using python for the first time and really can't believe how horrible it is to not have type checking, especially given that it takes time to run the code as a glue job.

wheelerof4te13• 4 years ago

Yeah, especially types like:

  List[Tuple[Tuple[str, int, str], Tuple[int, float, float]]]

Oh, so I am supposed to make my own data structures now, just for typing?

How about no?

bageljr• 4 years ago

Actually depending on the LSP, you are using a type checker since Pyright is its own type checker and Pylsp has a mypy plugin

kgbcia• 4 years ago

same, started using Objects and Classes more to get type hint support

yowlingcat• 4 years ago

Have you (or anyone else on this thread) used retype or MonkeyType? We have a codebase right now that's mostly lacking type hints. But, now that we have added automatic flaking into our build (and pre-commit hooks), I'd like to get some more mileage out of that toolchain we just invested into, but it would be a hassle to go back and add type hinting to everything.

What I'd like to do is integrate something into our pre-commit hooks.

majormajor• 4 years ago

But as a general rule: You don’t know if there really is a tool in place to check them. You especially don’t know this when you join a new project, but it’s also a little hard to tell afterwards. Did the mypy task in your build pipeline silently break? Maybe mypy is misconfigured? Maybe it spits out errors but does not cause build jobs to actually fail? What if mypy has a bug? What if mypy is not even complete and doesn’t cover all cases?

This seems like an extreme overstatement and a sign of a very weird team environment.

Are you not running your linting and validation locally?

Heck, when dealing with some poorly-typed external code, I run mypy manually to help me figure out what the stupid types I need to assign even are. This is far from ideal, but in lieu of a better solution, it works for me.

I just find the idea that people would be adopting typed Python and then completely ignoring the type-related tooling a bit wild.

And sure, libraries can have bugs, you can open yourself up to big holes with Any... and in cases where I'm super worried about things like that, I'm generally not using Python. But I'd rather use Python with type hints + use the tooling in a sane way then not use the type hints at all.

linsomniac4• 4 years ago

Hot take: If you think for a moment about the feature name, "type hints", many (all) of the objections the author has become clear.

It is not called "static typing". It's called "type hinting". Based largely on the name, I wouldn't expect it to error at runtime if you tell me 'hello' is an int. That's just a type hint. I WOULD expect a static analysis to flag is, and mypy indeed does.

reikonomusha12• 4 years ago

Aren't they called "annotations" by PEP 484?

Annotating certainly sounds stronger than hinting, but one must dive in and read the PEP to see they in fact do nothing except stash away metadata in a dunder attribute.

valcron10002• 4 years ago

If you're willing to drop all dynamic stuff and deal with a smaller library ecosystem I would highly recommend trying Haskell. At some point I feel like it's Python 5

dgan3• 4 years ago

I kinda wish OCaml had more traction

markus_zhang• 4 years ago

I'm using it sparsely. But how do I use it for external lib? Sometimes it's kinda difficult to know what exactly the type is.

moelf• 4 years ago

My personal "disappointment" is: it doesn't do anything for the runtime with all the extra work and headache. I.e. it feels like Julia but without the elegance of multi-dispatch and performance.

dlivingston• 4 years ago

Time-to-first-plot would like a word.

reikonomusha12• 4 years ago

That hardly has to do with type checking, and instead their compiler design.

faangiq• 4 years ago

Python type hints plus vscode is like god mode.

voz_• 4 years ago

Use pyre.

travisgriggs• 4 years ago

I have found optional typing to be a great example of an 80:20 trade off. I add type annotations to the easy stuff. I get a huge bang for that. I find that once I go past the “easy” annotations, I get less and less back from that. Between the IDE and my own annotations it catches 95% of trivial type errors.

jsmeaton3• 4 years ago

Adding type hints to Python has increased my productivity by at least a factor of 10. They allow you to reason about code in a local function without having to track back up dozens of call sites to ensure you're getting what you think you're getting. That alone is worth the price of admission. Both when editing code or reviewing someone else's. It's fantastic, particularly in a very large code base.

The editor experience only increases that factor as you can navigate a lot more freely. Even for small code bases type hints are a revelation. Knowing if something is nullable or not, alone, has caught 100's of bugs in waiting.

Most of the complaints here feel like attacking a strawman, particularly the ones arguing what's the point if you're not running mypy. Run mypy! It's like saying what's the point of writing unit tests if you don't run the test suite. For any sufficiently large code base you absolutely should be running mypy with any plugins for your framework of choice added.

For heterogeneous dictionaries use `dict[str, object]` and then you're forced to use the existing duck-typing mechanisms you're used to. Or, you refactor into better types and/or structures.

Is there friction? Sometimes. You don't have to annotate everything. If the cost is too prohibitive for a particular structure or function, ignore it. Sometimes there are mypy bugs that make writing correct code impossible. # type: ignore[reason] that sucker. Don't throw the baby out with the bath water.

We use a flake8 linter to enforce that all new or modified functions at least annotate their return type which makes interacting with functions quite a bit nicer, and encourages all devs to at least do the minimum. Usually you find that most args are appropriately typed at the same time.

tootie• 4 years ago

I'm baffled by people loving type hints in python when strongly typed languages have been widely available for so long. This is why people liked java and c#.

minism• 4 years ago

Same thing happened to the JS world with typescript (though typescript seems more powerful than python type annotations).

Its fine though - I'm glad the culture is trending towards understanding that strong typing saves you time rather than causes you extra time. This is true even for very small and simple programs, and even if you're the only developer.

coder543• 4 years ago

There are way more differences between Python and Java than just "having explicit types". If that was the only difference, your comment would make more sense.

I would even go so far as to say that Java's type system is the very one that left such a bad taste in people's mouth that many people swore off explicitly typed languages for a decade or two. It really was that bad, especially before the last few years. It added a lot of extra boilerplate for minimal practical benefit. People used Java because it was fast, cross-platform, and less likely to go horribly wrong than unmanaged languages like C and C++. I doubt very many people used it because they just loved typing tons of boilerplate or because they thought the type system was good enough to catch tons of errors.

The type systems in Rust, TypeScript, and other more recent languages are far more expressive (and capable of catching real-world bugs) than what Java offered. If you think Java has a good type system... things have come a long way since then. Java gets updated continually, and some people will surely jump at my comment and claim things are great these days, but, no. Java is not up to par, even today. C# has done a better job of keeping up, in my opinion, but even it still lacks extremely useful features like proper Sum Types.

I don't have much experience with Python's type hinting, so I can't comment as directly there.

aix1• 4 years ago

Python is, and has always been, a strongly typed language.

Do you mean "statically typed"?

jsmeaton3• 4 years ago

I really like C# and have done a bunch of work with it in the past! But I also love Python for reasons other than just static vs dynamic typing.

To be honest, I think a lot of Python [or arbitrary dynamic language] developers can be quite sloppy, throwing dictionaries around everywhere because it's easy and leading to some really hard to read code. Type hints guide people away from that sloppiness while still allowing access to most of the features that make dynamic languages so useful and expressive.

It's a best-of-both-worlds situation and I'm here for it.

vegai_• 4 years ago

There's a difference between putting on your own seatbelt and the car forcefully tying you into the chair every time you sit.

smohare4• 4 years ago

You misunderstand the ecosystem. Many folk program in Python because it’s largely forced upon them. It’s often the easiest language to work with for data science, ML Eng, or data engineering, despite many frameworks actually running in the JVM. It’s simply more accessible. The appeal of Python has not been its provenance or design for over 15 years, but rather the ecosystem.

grumpyprole4• 4 years ago

Many languages also demonstrated Python-like succinctness with strong static types and type inference. E.g. OCaml dates back to the 90's and ML dates back to the 70's.

cttet• 4 years ago

If the type system is not powerful enough it will be extra works just to get around the inadequacy.. If c# have some support of sum type and structural subtyping like Python I will be using that... I mean even Haskell does not have proper records.. Python is not definitely the best, but quite nice among the current options.

neves2• 4 years ago

Nice. How do you force types just in the new code?

jsmeaton3• 4 years ago

You can pipe the diff into specific flake8 checkers. Disable the check by default so it's not run over the entire codebase, and have a separate line for running specific checks on just the diff. Eg:

git diff -U0 --relative origin/master... | flake8 --diff --select <custom-codes>

I'll leave the flake8 plugin as an exercise to the reader as ours is intertwined with code I can't share right now.

Too2• 4 years ago

Mypy can be configured to ignore modules based on their names.

Though honestly I think it’s worth it to just bite the bullet and spend a full day or two to go through and fix every single error. After this you will have a much easier time navigating code base. I mean, your “new code” is probably modifications to your old code or calling your old code right? So you want to have at least the boundary between new and old typed. It’s quite satisfying anyway, as you will likely learn and discover tons of bugs on the way.

orf• 4 years ago

The same (and only) way you’d reasonably be able to do it in any other language that uses a series of text files for an input.

File by file.

chombier• 4 years ago

I generally force it on a per-file basis by adding

     # mypy: disallow-untyped-defs

on top of new python files.

Mehdi22772• 4 years ago

My team started with an untyped codebase a year ago. I added a rule to CI that every pr that touches files with type errors must decrease the type errors in touched files by at least 5. When we started we had like 30k type errors. A year later and it’s about 5k left. This was a small wrapper script over mypy/pyright that just called them twice once on master and once on your branch to compare error counts.

I did occasionally get pushback on it but stricter checks will be inconvenience at first and I argued it’d help over time. Now that we’ve had it a year it’s pretty well accepted in same way many would accept run formatter.

nyuszika7h2• 4 years ago

You can use flakehell for that.

eweise3• 4 years ago

Why not just use a statically type language? I really don't understand why python is so popular outside of a few specialized areas.

Spivak8• 4 years ago

Because ecosystems are what makes people productive and languages are just a means to access them. Python's ecosystem is absolutely massive and high-quality.

michaelt• 4 years ago

Ah, but what if I'm a masochist and I want all the verbosity of a statically typed language with none of the benefits?

ok1234562• 4 years ago

It's basically a lisp with better syntax.

ttymck• 4 years ago

Look there's a lot of good, long winded comments here. If anyone is like me and scrolls for an easily digestible one: here's the TLDR.

Eventually you'll get fed up with not knowing what type each argument to an API call needs to be. You'll either get on board with python type hints, or you'll graduate to a typed compiled language, or you'll languish in the trough of python productivity.

goodoldneon8• 4 years ago

Types help to encourage readable code. If it's hard to add type annotations to a function then the function is too complicated. I've seen this with wildly polymorphic functions that needed dozens of overloads to properly type... which means that engineers need to hold all that complexity in their heads

avl999• 4 years ago

I find it interesting how we have come full circle on static typing. When I was in University 2009-2013... and years leading up to it, dynamic typing was becoming the hot thing after years of Java/C/C++ dominance. Statically typed languages were looked down upon and talked about as being analogous to "Enterprise", "suit and tie" type soul crushing software development. We had people fulling in Ruby/Rails bandwagon, Java/C/C++ starting to become deprecated from university curriculum in favor of Python... JS starting to eat the front end and HN startups were talking about how they write their entire stack in a flavor of Lisp.

And now, just a few years later- Rust, Go are two of the hottest languages around, TypeScript is eating JavaScript, Python/Ruby have added static typing constructs, C# continues to do well in its niche and even Java of all languages has become somewhat cool again even though being Oracle product.

It's been an amazing transition to watch in action play out in front of my career, I can't even imagine those who have been in the industry for 30-40years who have probably been through a dozen of these cycles.

reikonomusha12• 4 years ago

Give it a few more decades and maybe we'll come to accept a Hindley-Milner system of the 1970s, like that of Standard ML.

And maybe a few more decades after that to go back to the dynamic typing of the 1950s, like that of Common Lisp. :)

rahimiali• 4 years ago

"What you really want is a compiler, isn’t it?"

The thing is, Python is just as compiled as, say Java. Python converts your code to byte code, then executes that bytecode in its VM. These are the same steps Java takes.

So this "whoops" doesn't work for me: "Some language that’s as easy to use as Python and it should be compiled and with good static typing, but it should also not be compiled because then it wouldn’t be as easy to use as Python anymore. Whoops?".

The reason the typing in Python is lax was entirely a choice. Maybe not a good choice, but it certainly has nothing to do with "compiled" vs "interpreted".

maxloh• 4 years ago

There is mypyc and Cython, which compile Python to high performance machine code.

kortex7• 4 years ago

That's not really a good definition of compiled. Interpreted vs compiled is very much more a continuum than it was however many years ago when these terms originated - you had compiled ALGOL and interpreted BASIC, and little in between.

Rather, you have to look at it like an attribute based categorization:

Compiled:

- types known at compile time

- limited runtime features like stack traces, introspection

- working closer to primitive data types

Interpreted:

- dynamic, with lots of indirection

- wrapped data types (eg PyObject) vs primitives

- rich runtime with stack traces, introspection, monkey patching

bayesian_horse26• 4 years ago

A type checker doesn't make a statically typed language. Also, yes, the program will "run" with failed type assertions.

Compare this with Typescript, where by default the compiler will refuse to compile the code when type errors are encountered. But there are other Typescript compilers that are faster and don't typecheck at all, they just strip the syntax.

If you want the strict behavior, you need to prevent the program from running when typechecking fails. That is entirely possible with mypy.

smohare4• 4 years ago

This article was written by someone who doesn’t read or write much Python, obviously. Why is it on HN?

revskill• 4 years ago

Because many people on HN don't read or write much Python.

nurettin• 4 years ago

Maybe the title should have been "mypy has a bug and I'm going to spin it into a language problem because I don't like Any"

theptip• 4 years ago

I didn’t really connect with any of these objections. Python type hints are very permissive and you need to turn them up in strictness to get enforcement. No big deal for me.

But moving between a TS and Python codebase, I just find TS much easier to work with. Maybe it’s that type bindings are more widely defined in libraries (though typeshed has quite a few now). Or maybe it’s something about TS being easier to define type vars / infer types in my IDE? I can’t really put my finger on it.

anamax• 4 years ago

Type systems are great for catching representation errors.

However, the important errors that I make are "kind" errors.

Type systems can verify that you're adding two ints, but won't tell you when you add the number of bananas to the number of oranges. Of course, both numbers contribute to the total number of snacks.

tbrownaw• 4 years ago

They're not perfect, but they do make the syntax highlighting and autocomplete work better.

jlrubin2• 4 years ago

my experience with python's optional type system was that the simple stuff works very well, but when you try to go down a type rabbit hole for more advanced stuff involving generics it becomes really unworkable, inconsistent, and hard to dig yourself out of.

but for little things, like just function signatures, it's great!

jlrubin2• 4 years ago

fwiw i was able to successfully port this complex project into rust's type system.

kortex7• 4 years ago

This article is so hopelessly mis-informed, that it's practically hard to read without screaming "that's not how any of this works!" Most of their main arguments - type hints can be wrong, they can be ignored, and they don't inform you in a useful way about program state because of this - all evaporate as soon as you start using the correct tooling.

My stack is pycharm, mypy, pydantic, sqlalchemy stub, several mypy plugins, black, isort, tabNine completion, and a bunch of custom scripts/Make to automate the common tasks. I'm not even sure I'm on the same planet as the author. I can practically spot incorrect type hints, mismatched types, weakly defined interfaces, from orbit, that's how well they are highlighted. Since every type is known, between pycharm and tabnine I can type 2-5 keys and spit out entire lines of code. And since it's all typed, automatic refactor is a breeze.

I remember the dark ages, before type hints. It was rough. I lived in the REPL. Write 3 lines, run, Exception. Write 3 more lines, run, NoneType error. Ad nauseum. Now I write for hours on end and don't wince when I hit execute. And I don't have to go bug coworkers with questions like "hey what keys are in this dict when we redirect from the oauth endpoint".

Sure, I have my gripes, but it's mostly with the lack of power of the type system, like lack of higher kinded types. But I'm confident it'll get there.

Come to the typed side. We have less mental fatigue and screaming at neverending runtime oopsies.

hummingn3rd• 4 years ago

I was curious of seeing if pydantic was mentioned, thanks! We use most of the same tooling as you, I'm always interested in improving our tooling, would you be willing to share your mypy plug-ins names or maybe most useful tools for inspiration?

qayxc• 4 years ago

As long as you don't have to rely on 3rd party libraries, sure, type hints are fine.

Many popular libraries, however, don't have type hints or use them inconsistently (looking at you numpy, pytorch, tensorflow, scipy, ...).

Always great fun to see function signatures that use type hints for the parameters and return Any.

So it really depends what kind of code you write - web frameworks might be fine, data science and ML is definitely not.

Mehdi22772• 4 years ago

You can write type stubs for other libraries. Over past year my team had a 100k line codebase that we’ve gotten mostly typed. But we still use a lot of other untyped libraries like tensorflow. So in past couple months we’ve started adding type stubs to the parts of the api we use. While tensorflow/numpy/etc are massive libraries most people only use a small subset of api. You can write type stubs for the subset you use. It definitely takes time but I find it very helpful to have useful type checking of tensorflow so I bit bullet and started writing stubs. I explored upstreaming them to type shed but got lazy on dealing with CI issue although I hope to revisit it later.

wheelerof4te13• 4 years ago

Type hints are good if you stick to the std + your own code that mostly relies on std.

Otherwise, don't bother.

tonyg3• 4 years ago

My stack is pycharm, mypy, pydantic, sqlalchemy stub, several mypy plugins, black, isort, tabNine completion, and a bunch of custom scripts/Make to automate the common tasks.

Christ. What a mess. With a stack like that, it's a stretch to say you're "writing in Python" anymore.

serial_dev• 4 years ago

Most of their main arguments (...) evaporate as soon as you start using the correct tooling.

You silly! Just use these carefully curated list of 28 different tools (that I got to after years of trial and error) and you'll have a somewhat acceptable tooling and type support in Python.

avianlyric• 4 years ago

To be fair, I don’t think you need that entire stack. Just using VSCode + pyright (which is a one button install in VSCode) + type stubs for libraries your using without native hints, gets you 99% of the benefits.

If you really want, you can even throw in a little pre-commit hit hook that runs pyright and prevents you from commuting code with type errors.

ramraj072• 4 years ago

Wow gatekeeping types out of python are we? Of course the language looks different when typing is enforced, let it evolve.

nerdponx• 4 years ago

That's such a disingenuous argument.

First of all, Black and Isort are literally code formatters that have nothing to do with type hints.

Second, the whole point is that you can actually develop powerful dev tooling for Python now, whereas in the past it was difficult or impossible.

john-radio• 4 years ago

I think the person you're responding to is just trying to be thorough in case it is helpful to someone else setting up python tooling; the only parts of what they wrote that are relevant to type checking are mypy and pydantic.

kortex7• 4 years ago

It's more so "this is my toolchain I use for my own ergonomics, and what you can achieve with the right kit".

Who cares if I'm "writing in python" at all? I'm solving problems. Honestly a good IDE (pycharm or vscode) will give you 80% of the ergonomics.

ramraj072• 4 years ago

Have you tried pytype? Curious if anyones compared it properly To mypy.

Otherwise the exact same stack as yours, we use fast api as well. Also a big fan of using dataclasses everywhere.

da39a3ee2• 4 years ago

You’ve never used a compiled statically typed language. I’m sorry to say it but your comment would sound naive to you if you had. The article is spot on.

igortg2• 4 years ago

My thoughts exactly. Obviously, Python Type hints are an attempt to add type-check to a language "after the fact" and keep it optional. So it's unfair to compare that to a static typed language and conclude that it's bad.

I work with large code bases (100K-1M lines) and can't look back to the time we didn't use Type Hints. Would maybe dismiss it only for scripts or very small projects.

nine_zeros13• 4 years ago

Python types just work. Just use these 30 libraries, spice up your IDE with settings and voila /s.

This is garbage and moving backwards as a programmer. I loved python when it was easy to use with any editor and with few plugins. Now I'm just going to switch to a statically typed language where I don't have to install a zillion plugins to get first class typing.

wheelerof4te13• 4 years ago

This is the crust of the problem.

Python type-hints bind you to a lot of other sister projects of Python, which makes you question if they are even official addition to the language.

I think that's also what the OP's article tries to convey.

Spivak8• 4 years ago

Python type annotations in the language are nothing more then allowing you put any Python expression in the "type slot" and have it be syntatically valid. They don't do anything. All the functionality is 3rd party packages taking advantage of their existence.

cjalmeida3• 4 years ago

As many already said, 99% is just a modern IDE with a one-click-install plugin.

Also, I don't know the grip with productivity tools.

bredren• 4 years ago

I used tabnine from early on but found its capability pretty well subsumed by GitHub copilot.

What has kept you on tabnine?

stackedinserter• 4 years ago

What opensource project is closest to "doing python the right way", in your opinion?

I'm in "python is not suitable for production" camp, would be happy to change my mind.

I remember the dark ages, before type hints. It was rough. I lived in the REPL. Write 3 lines, run, Exception. Write 3 more lines, run, NoneType error.

That's why I switched (back) to typed compiled languages and never went back.

twelve402• 4 years ago

Definitely types, but it's still weaker than in other languages. Just the other day found a maddening bug, where Django ORM query accepted `date` type comparison against a datetime field, and of course that resulted in crazy things in production. Other languages would have caught this compile-time.

ok_dad2• 4 years ago

I use this very strict config with mypy and it's effectively a typed language. I rarely have any errors in runtime now, at least from type-related problems like assigning 'vals = 3' and later trying to call 'vals.append(4)'. I sometimes use 'Any' because it's basically required for things like loading JSON or retrieving the results from a GET request, but I have several strictness settings that ensure I never pass around wild Any values and I try to keep their use to within a single function or method and always return a well-typed value. Sure it's all in my IDE right now, but if I import 1 or 2 packages suddenly my well-typed Python code starts to act more like a typed language in runtime, too!

    disallow_any_unimported = true
    disallow_any_expr = true
    disallow_any_decorated = false # true if you never plan to use Any
    disallow_any_explicit = false # true if you never plan to use Any
    disallow_any_generics = false # true if you never plan to use Any
    disallow_subclassing_any = true
    disallow_untyped_calls = true
    disallow_untyped_defs = true
    disallow_incomplete_defs = true
    disallow_untyped_decorators = true
    no_implicit_optional = true
    warn_redundant_casts = true
    warn_unused_ignores = true
    no_warn_no_return = true
    warn_return_any = true
    warn_unreachable = true
    strict_equality = true
    strict = true

aswerty• 4 years ago

Type hints are a god send in Python if you want to use the language for anything beyond scripting (or single developer code bases).

Without type hints you don't realise how crazy your data structures get in Python. Trice nested dictionaries getting passed around, or pandas running wild across your code base, and on it goes. Instead with type hints we now have insight and can have meaningful discussions on the data structures flowing through our system.

Our team is yet to adopt mypy into our build systems, but hopefully we will introduce it soon.

nwatson• 4 years ago

PyCharm with type-hinting and "inspections" (which include pseudo-static analysis for appropriate type use) have only added to the awesomeness of great code navigation, refactoring, auto-completion, code-formatting, etc.

If you're going to have type-hints, you need pseudo-static analysis.

nyuszika7h2• 4 years ago

and in new versions of your type checker, you have to make sure that they didn’t change their meaning and that they didn’t introduce new flags that you really, really should use.

That's what the --strict flag is for, which the author even quietly uses in a later example without explaining it. Though it may be too noisy to immediately turn it on in some projects.

As for the example of getting something returned from the network that has a mismatching type, there's no way mypy could guess that. You'd have to add an explicit `isinstance(foo, int)` check or use a runtime type checker.

The author does have a point that people might simply use wrong type hints if they don't have a proper type checker set up though. I've seen so much code with `any` instead of `Any`, `[foo]` instead of `list[foo]`, etc. as type hints. Using something like pre-commit and/or editor plugins to run mypy automatically while editing is probably the best. But it's true that even then, without --strict or equivalent, you can too easily satisfy the type checker by simply annotating something as a `dict` or `list`, without explicitly using `Any`.

Still, I don't think this means we shouldn't use type hints at all. It could definitely be more beginner-friendly, but most of the mentioned issues can be addressed with proper configuration.

physicsguy• 4 years ago

I like type hints, but trying to retrofit it into an existing project I’ve found difficult, because you end up with Union[type1, type2, type3] in some places.

t435622• 4 years ago

Correctness in Python is all about unit tests - if you don't bother with them then you're playing with fire (and of course I often "play with fire").

Type hints .... well they help the IDE to autocomplete which is great. They also help you to get the order of parameters in a function/method call correct which is useful if the parameters aren't all the same type!

I converted a medium sized project to type hinting once. The original author wrote no tests and obviously didn't design it to be testable so I was looking for some small way to make it less horrendously unmaintainable. Every test run of the source took hours and there would be some trivial syntax error or whatever right at the end.

Type hints weren't so difficult and I hoped that they would "staunch the bleeding" while I tried to get it into testable shape. In this case they did almost nothing - didn't help me stop a single bug - probably because most types were "str" but that's not the fault of the hinting system as an idea, right? It's just an unprofitable load of work in particular situations.

Static typing fans are always going to be disappointed by Python and it's great because there are other languages for them. For the rest of us we can use them where it turns out to be profitable to us.

Unit tests are, however, by 1000x, more important.

arinlen3• 4 years ago

Correctness in Python is all about unit tests - if you don't bother with them then you're playing with fire (and of course I often "play with fire").

But Python does support type hints, and tools like MyPy do use those type hints to evaluate correctness. It seems to me that Python's type hints are indeed Python's way to check for correctness.

Also, unit tests don't verify correctness. They only serve to check whatever small set of ad-hoc invariant developers put up.

t435622• 4 years ago

You can have a program with correct type handling that doesn't work but with unit tests you have a program that works and documentation (in the form of the test) about the ways in which the programmer expected it to work.

That's why I find type hinting to be relatively high effort for relatively low benefit and choose to use it only where I feel it makes life better. The optionality suits me. It's a nice to have but that's all.

runeks• 4 years ago

Python is a dynamically typed language. By definition, you don’t know the real types of variables at runtime.

I think you mean compile-time and not runtime. There’s not much use in knowing the type at runtime, since it only enables you to print a better error before crashing (“Expected type: x, actual type: y” instead of “AttributeError: 'str' object has no attribute 'append'”).

Types are only truly valuable at compile-time, where they can prevent compilation of invalid code. This is the reason many statically typed languages use type erasure, which removes type information from the compilation output.

In fact, the type-checking phase can happen even earlier than the compilation phase. This is useful e.g. in an IDE, where you care about type errors but not necessarily about running your program.

davidatbu• 4 years ago

I disagree diametrically with both the general sentiment of the article, and every major point that was made in it.

Every point in this blog post strikes me as either (1) unaware of the tooling around python typing other than mypy, or (2) a criticism of static-typing-bolted-on-to-a-dynamically-typed-language, rather than Python's hints. Regarding (1), my advise to OP is to try out Pyright, Pydantic, and Typeguard. Pyright, especailly, is amazing and makes the process of working with type hints 2 or 3 times smoother IMO. And, I don't think points that fall under (2) are fair criticisms of type *hints*. They are called hints for a reason.

Otherwise, here's a point-by-point response, either recommending OP checks out tooling, or showing that the point being made is not specific to Python.

type hints are not binding.

There are projects [0][1] that allow you to enforce type hints at runtime if you so choose.

It's worth mentioning that this is very analogous to how Typescript does it, in that type info is erased completely at runtime.

Type checking is your job after all, ...[and that] requires maintenance.

There are LSPs like Pyright[2] (pyright specifically is the absolute best, IMO) that report type errors as you code. Again, this is very very similar to typescript.

There is an Any type and it renders everything useless

I have never seen a static-typing tool that was bolted on to a dynamically typed language, without an `Any` type, including typescript.

Duck type compatibility of int and float

The author admits that they cannot state why this behavior is problematic, except for saying that it's "ambiguous".

Most projects need third-party type hints

Again, this is a criticism of all cases where static types are bolted on dynamically typed languages, not Python's implementation specifically.

Sadly, dataclasses ignore type hints as well

Pydantic[3] is an amazing data parsing library that takes advantage of type hints, and it's interface is a superset of that of dataclasses. What's more, it underpins FastAPI[4], an amazing API-backend framework (with 44K Github stars).

Type inference and lazy programmers

The argument of this section boils down to using `Any` as a generic argument not being an error by default. This is configurable to be an error both in Pyright[5], and mypy[6].

Exceptions are not covered [like Java]

I can't find the interview/presentation, but Guido Van Rossum specifically calls out Java's implementation of "exception annotations" as a demonstration of why that is a bad idea, and that it would never happen in Python. I'm not saying Guido's opinion is the absolute truth, but just letting you know that this is an explicit decision, not an unwanted shortcoming.

[0] https://github.com/RussBaz/enforce

[1] https://github.com/agronholm/typeguard

[2] https://github.com/microsoft/pyright

[3] https://pydantic-docs.helpmanual.io

[4] https://github.com/tiangolo/fastapi

[5] https://github.com/microsoft/pyright/blob/main/docs/configur...

[6] https://mypy.readthedocs.io/en/stable/config_file.html#confv...

wodenokoto• 4 years ago

A lot of people saying author isn't smart/educated enough about the topic, but I kinda agree with him, that they are disappointing. From a "normal" programmers point of view, they are weak and don't really safeguard you well enough out of the box.

Apparently you can install and setup a billion 3rd party libraries in your code editor and a CI pipeline to get a really good workflow, but that just shows that you need to be an expert in order to use these.

lars512• 4 years ago

I love the gradual typing approach, and have found it makes codebases better to maintain, even if some libraries like pandas are a total pain.

My biggest gripe is the conflicting warnings between mypy and pyright. Language servers use pyright by default in the editor, but I strongly believe a Python project shouldn't require nodejs as part of its required CI toolchain. So all my projects use mypy in strict mode in CI. Basically this means that mypy is the standard to meet, and that there are persistent warnings in the editor which I have to ignore.

pkrumins• 4 years ago

Python is becoming a Turing tarpit language that’s black-holing on its own syntactic complexity. Soon every single ASCII character will have a special syntactic meaning and the syntax itself will become Turing complete in more than one way, similar to C++ that has already collapsed in syntax hell. JavaScript is following the same path by adding every feature from every other programming language. Soon all programming languages will have exactly the same features where everything is possible but nothing is doable or practical.

dgan3• 4 years ago

Landing in a large-ish python project without type annotations is a pain. Author says that he won't use type annotations because they "can be wrong", well, you only rely on variables names and documentation for that, you have even less chance to get that right.

Is that "line" variable a "LineInvoice" or "InvoiceLine" (yes, two different classes) ? Oh, right, both can be used in this place exclusively because one is subset of the other... sigh

CrLf• 4 years ago

Python's base philosophy is duck typing. Whenever I read complaints like this the root cause is almost always trying to turn Python into something that it isn't instead of embracing what it is (if this isn't feasible, then Python is the wrong choice).

Programming in Python worrying about types instead of behavior reminds me of the quote "you can write FORTRAN in any language".

dgan3• 4 years ago

Well, the problem is more often than not, I am an employee. I won't come to a company and tell them "you have been using that wrong".

So while correct, your statement is void of any actionable advise

lysecret2• 4 years ago

Love typing, if you are writing code with a lot of Data Frame Inputs and Outputs I encourage you to check out Pandera.

lysecret2• 4 years ago

About this section:

Sadly, dataclasses ignore type hints as well

this is excatly what pydantic was made for. As well as its integration with FastApi.

FastApi, is really the most beautiful way, I have seen. To use the python type system to its fullest.

da39a3ee2• 4 years ago

I agree with everything in this article. The fact that nothing is necessarily checking them makes a codebase full of them too misleading. They become cargo culting; and as the article says their special syntactic status makes them look “official”. Typescript is much better since you can’t avoid them being checked. And that’s said as someone who spent the last decade writing Python, in later years with type hints. There’s also a mypy option that is not on by default but that is absolutely required to avoid misleading false negatives: —-check-untyped-defs

whiplash4512• 4 years ago

I would argue that doing this kind of stuff is bad design.

```foo = { 'hello': 'world', 'bar': ['baz'], } ```

Don't put it on the language not to be able to deal with this kind of stuff.

Jiejeing• 4 years ago

The author seems to have unreasonable expectations of the python typing implementation, most of which can be fixed with mypyc and stricter flags. They also did not check the concept of gradual typing which is key to why everything is not strict by default.

I too am disappointed a bit by the type hints because they are not expressive enough for me, and some natural python constructs are hard to express. And because mypy has bugs I encounter from time to time.

igortg2• 4 years ago

www.uninformativ.de

Domain name checks out :)

wheelerof4te13• 4 years ago

The main problem with type hints for Python code is that it changes the way you think about writing Python.

Before, it went something like this:

1) Install Python (if you don't have it already)

2) Install your favorite text editor

3) Write some Python!

Now, it goes something like this:

1) Install Python

2) Install your favorite IDE

3) Install plugins for your IDE

4) Install black, mypy, flake8 plus some other nonsensical "helper" library

5) Don't forget your poetry, gotta have that

6) Be careful to pick only 3rd party libraries that have good type hints..

7) God help you if you try writing something yourself, let your IDE do that.

Type hints make not only your code more complicated and unreadable. They complicate your entire workflow.

tomerv2• 4 years ago

How did you get from type hints to black, not to mention poetry? Seems like you're just complaining about there being a mature ecosystem around Python, and the implicit expectation to use it.

wheelerof4te13• 4 years ago

And here I thought my explanation at the bottom covered this.

Let's try again:

Python has become a mess. It is no longer a simple productive language to get into like it used to be. Now, you are expected to buy into it's ecosystem, like it is C# or Java.

Well, it is not. It's Python and I am truly sad they are killing it with thousand cuts.

tpoacher• 4 years ago

All the problems the author seems to have seem to be problems of "false expectations" rather than type hints lacking value per se.

In which case, I fully declare, publicly, that I am very disappointed with numpy, because it doesnt have good coffee making facilities out of the box.

shreyshnaccount• 4 years ago

I write data science code, it's a mess. Type hints have saved me a lot of time and headache.

twelve402• 4 years ago

I wonder who, ever, thought that weak typing python- or raw js- style, was a good idea? Come to think of it, is there a single redeeming quality of weak typing in those languages other than "easier to wreak havoc and quicker to write crazy buggy shit"?

There is probably that stoic school of thought that if you are forced to walk around a construction site without a helmet, it will make you a more thoughtful and better worker, but... come on

mmcnl• 4 years ago

I actually enjoy the typing in Python. The only problem is lack of support from third-party libraries. I find myself fighting the typing errors so often by adding: # type: ignore. Especially pandas gives so many errors. Type hints are included but they are often just plain wrong.

xvmodvx• 4 years ago

I'm sorry, but I'm writing this response without reading all the previous comments, but with almost 600 directly to it and more comments to a comment I hope it's understandable.

However I did read a good portion of them and I'm confused...I thought Python doesn't use types everything is an object according to their documentation.

Now for my 2 cents, if you don't care, don't read it... a lot of the comments aren't based on facts but opinions and a lack of understanding of the actual language, funny that I write that after my previous sentence huh? :) . Every language has goods and bads, don't think as someone who as a Python programmer or C programmer, just a programmer and use the best tool for the task you're trying to complete. If you've been programming for awhile you should have used a dozen different languages at some point. Don't focus on what the language can do but understanding the underlying concepts and then you can easily use the one that makes the most sense for that project.

Python’s “type hints” are a bit of a disappointment to me

Related Stories