Hacker News Reader

Comment by ReflectedImage | Hacker News Reader

Monorepos require static typing as a first class citizen of the language.

"And there is nothing wrong with using a type checker for your Python type annotations."

There is a lot wrong with that. Python is a dynamically typed language. If you are using a static type checker on a dynamically typed language, you are not taking advantage of the dynamic nature of the language.

You are basically not writing Python code at all. This means you get all the disadvantages of using a dynamically typed language with none of the benefits.

In summary, you have a made a very poor engineering decision.

View on HN

This is a terrible take. Using type annotations doesn’t mean Python is no longer a dynamically typed language

If you enforce them then you can't do duck typing, this means adding lots of boilerplate code to your code base, increasing the amount of bugs, since bugs are proportional to the total number of lines of code in the project.

Typing related bugs that aren't caught in unit testing are very rare.

Any additional bugs per lines of code, which would be less in a strictly typed language anyway, is worth the structure you get from a typed language.

I disliked JavaScript and love python. Typescript has replaced python as my labor of love language for now but a typed python in a similar manner would be great

Typing doesn't remove many bugs from Python code (probably about 1 bug per year). It's statisically insignificant.

JavaScript is a bad language and adding stuff to it makes it better. The same isn't true for Python.

> If you enforce them then you can't do duck typing,

This is a little misleading as mypy and pyright both support structural typing.

> If you enforce them then you can't do duck typing, this means adding lots of boilerplate code to your code base, increasing the amount of bugs, since bugs are proportional to the total number of lines of code in the project.

You can still do duck typing. Python's Protocol and TypedDict do that for objects and dicts, respectively. Python also has sum types. I've added type annotations to thousands of lines of legacy code and rarely have I had to change any logic to accommodate.

> Typing related bugs that aren't caught in unit testing are very rare.

Not true at all. Unless you're writing unit tests that cover every possible code path, your unit tests will miss stuff. And I'd argue that 100% test coverage is a Herculean effort to write and maintain, and isn't worth it. Static analysis gives you tons of checking for free. The biggest benefit is forcing you to properly handle function arguments that could be None. Are you always checking that values aren't None before using them?

Static analysis using static typing gives you almost nothing at all in practice.

It searches for a very narrow and rare set of bugs, which hardly ever happen.

Typing really exists to help a compiler, it's not a code correctness tool in the way you envision.

It absolutely is a code correctness tool. If I have a function that should only accept a string then static analysis will error in all the places that pass anything else. As long as you validate your inputs (i.e. request validation) then the type annotations are representative of the runtime types

This guy is full of terrible takes. Like his claim that typing catches "one bug a year".

> You are basically not writing Python code at all.

I really dislike this take. I believe Python is about rapid iteration, doing more of functionality with less code, and enjoying the process of programming. You know what I enjoy? Easily knowing what features (methods, attributes, keys) an object has. You know what I really don't enjoy? Having to dig through reams of source code to figure out what attributes I can use, or what *kwargs a function takes.

Nothing about duck typing prohibits saying `def func(duck: Duck)`, because maybe it's a French duck and has .coin() instead of .quack().

Also also, how is static typing completely incompatible with dynamic features? Usually there exists an abstraction with static types that actually captures the behavior you want. Its rare you want to be able to handle literally anything. Ask oneself, "could this function receive absolutely, truly, anything, or is it just shortcut for not finding the right types?"

You might dislike the take, but it's correct. If I write a side-effect free Python program in Haskell style, that isn't a "real" Python program. Using a static type checker is a similar type of change to the code style.

"Having to dig through reams of source code to figure out what attributes I can use, or what *kwargs a function takes."

Figuring out the attributes and what kwargs a function takes is the role of your intelligent IDE and docstrings. You think you need to static typing for this since you haven't spent the time to learn how Python does these things.

Duck typing says, duck doesn't have a type, not even Duck, anything that quacks is a duck even a 115 ton truck.

> You think you need to static typing for this since you haven't spent the time to learn how Python does these things.

I've been writing python for over 15 years and use Pycharm extensively. Please don't make assumptions about other users' experiences without evidence.

IDEs absolutely do not infer what fields *kwargs take, let alone what types those fields are. I'm not talking named fields, I mean literally

    def func(*args, **kwargs): ...

Afaict, no IDE and no type system can help you there, in python, save for some really arcane type inference magic on every single call site.

> duck doesn't have a type, not even Duck

It absolutely does, if Duck is a protocol. If you have some object, and you call .quack(), it implements the Quacker interface, even without inheriting BaseDuck. You can still statically type it no problem, and it'll take a Truck no problem, so long as Truck.quack() is defined. Almost everything has a type, it just takes some effort to uncover it.

That's an IDE problem, with sufficently powerful code inspection, the fields can still be found. It is not the developers' job to manually add that type of information into their source code.

Ahh so if a method on an object dynamically adds in the quack() method at runtime, does the object spontaneously change type?

> Ahh so if a method on an object dynamically adds in the quack() method at runtime, does the object spontaneously change type?

Yes, actually.

This is an antipattern in the vast majority of use cases. There are far better patterns out there than just sticking a method on an object, and I detest codebases that do this sort of thing. It's almost always someone who uses the phrase "pythonic" unironically way too much, writing these sorts of things, and a nightmare to debug.

There's less problem with doing something like

    def quackerizer(foo: Any) -> Quacker:
        foo.quack = lambda...
        return foo

Still kinda odd, but at least you are doing a formal cast.

> That's an IDE problem, with sufficently powerful code inspection, the fields can still be found.

Ok, name one. Pycharm and vscode don't currently do it afaik. Maybe some vscode plugin, haven't used vscode much.

Reply on news.ycombinator.com