Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python developers are embracing type hints

pyrefly.org

Post reply on HN
Print view View original

391–400 of 581 posts

Re: Python developers are embracing type hints

#391

Post by mhitza »

Dr_Birdbrain wrote: post #215

I actually don’t like python type hints! At my work we have a jit compiler that requires type hints under some conditions. Aside from that, I avoid them as much as possible. The reason is that they are not really a part of the language, they violate the spirit of the language, and in high-usage parts of code they quickly become a complete mess. For example a common failure mode in my work’s codebase is that some func…

Sounds like the ecosystem needs an "indexable" type annotation. Make it an "indexable" for good measure.

Re: Python developers are embracing type hints

#392

Post by jampekka »

ninetyninenine wrote: post #340
jampekka wrote: post #223

Earlier quoted context omitted.

> There are developers who design apis by trying to figure out readable invocations. These developers discover, rather than design, type hierarchies and library interfaces. My hunch is that the people who see no downsides whatsoever in static typing are those who mostly just consume APIs.

There are downsides. But the upsides outweigh the downsides. I'm not a consumer of APIs. I've done game programming, robotics, embedded system development (with C++ and rust), (web development frontend with react/without react, with jquery, with angurar, with typescript, with js, zod) (web development backend with golang, haskell, nodejs typescript, and lots and lots of python with many of the most popular frameworks…

You are wrong. I learned programming mostly in C++ in the late 90's, and programmed in C, C++ and Java in professional settings for a decade or so, and still do from time to time.

Re: Python developers are embracing type hints

#393

Post by Narushia »

rgovostes wrote: post #93
letmeinhere wrote: post #31

Earlier quoted context omitted.

Yeah post 3.10 you don't need Union, Optional, List, Duct, Tuple. Any still necessary when you want to be permissive, and I'm still hoping for an Unknown someday...

I am glad they improved this but I still like Optional[], and to a lesser extent, Union[]. It's much more readable to have Optional[str] compared to str | None.

I disagree with `Optional`. It can cause confusion in function signatures, since an argument typed as "optional" might still be required if there is no default value. Basically I think the name is bad, it should be `Nullable` or something.

I believe Python's own documentation also recommends the shorthand syntax over `Union`. Linters like Pylint and Ruff also warn if you use the imported `Union`/`Optional` types. The latter even auto-fixes it for you by switching to the shorthand syntax.

Re: Python developers are embracing type hints

#394

Post by Narushia »

maleldil wrote: post #46
letmeinhere wrote: post #31

Earlier quoted context omitted.

Yeah post 3.10 you don't need Union, Optional, List, Duct, Tuple. Any still necessary when you want to be permissive, and I'm still hoping for an Unknown someday...

> hoping for an Unknown someday Wouldn't that just be `object` in Python?

That's what I use it for. If you type something as `object`, static type checkers can just narrow down the exact typing later.

Re: Python developers are embracing type hints

#395

Post by theptip »

mhitza wrote: post #391
Dr_Birdbrain wrote: post #215

I actually don’t like python type hints! At my work we have a jit compiler that requires type hints under some conditions. Aside from that, I avoid them as much as possible. The reason is that they are not really a part of the language, they violate the spirit of the language, and in high-usage parts of code they quickly become a complete mess. For example a common failure mode in my work’s codebase is that some func…

Sounds like the ecosystem needs an "indexable" type annotation. Make it an "indexable " for good measure.

Right, this was my thought.

Can’t you just use a typing.Protocol on __getitem__ here?

https://typing.python.org/en/latest/spec/protocol.html

Something like

    from typing import Protocol

    class Indexable(Protocol):
        def __getitem__(self, i: int) -> Self: ...
Though maybe numpy slicing needs a bit more work to support

Re: Python developers are embracing type hints

#396

Post by ddavis »

zenkey wrote: post #331
Dr_Birdbrain wrote: post #215

I actually don’t like python type hints! At my work we have a jit compiler that requires type hints under some conditions. Aside from that, I avoid them as much as possible. The reason is that they are not really a part of the language, they violate the spirit of the language, and in high-usage parts of code they quickly become a complete mess. For example a common failure mode in my work’s codebase is that some func…

In my experience, the right tooling makes Python typing a big win. Modern IDEs give comprehensive real-time feedback on type errors, which is a big productivity boost and helps catch subtle bugs early (still nowhere near Rust, but valuable nonetheless). Push it too far though, and you end up with monsters like Callable[[Callable[P, Awaitable[T]]], TaskFunction[P, T]]. The art is knowing when to sprinkle types just en…

When you hit types like that type aliases come to the rescue; a type alias combined with a good docstring where the alias is used goes a long way

Re: Python developers are embracing type hints

#397

Post by theptip »

seanparsons wrote: post #110

As a static typing advocate I do find it funny how all the popular dynamic languages have slowly become statically typed. After decades of people saying it's not at all necessary and being so critical of statically typed languages. When I was working on a fairly large TypeScript project it became the norm for dependencies to have type definitions in a relatively short space of time.

Type hints / gradual typing is crucially different from full static typing though.

It’s valid to say “you don’t need types for a script” and “you want types for a multi-million LOC codebase”.

Re: Python developers are embracing type hints

#398

Post by JimDabell »

ninetyninenine wrote: post #349
JimDabell wrote: post #257

Earlier quoted context omitted.

> What I have to have scientific papers for every fucking opinion I have? No, but if you’re going to say things like “increase safety by roughly 2x” then if you can’t even identify the unit then you are misleading people. It’s absolutely fine to have an opinion. It’s not fine to make numbers up. > I'm confident my "anecdotal" metrics with I prefaced with "roughly" are "roughly" ballpark trueish. Okay, so if it’s 1.5×…

>No, but if you’re going to say things like “increase safety by roughly 2x” then if you can’t even identify the unit then you are misleading people. So when I talk about multipliers I have to have a unit? What is the unit of safety? I can't say something like 2x more safe? I just have to say more safe? What if I want to emphasize that it can DOUBLE safety? Basically with your insane logic people can't talk about prod…

Take a step back and look at what you are saying:

> If someone disagrees with me (on this specific topic), it absolutely doesn't mean they are a junior. It means they lack knowledge and experience. This is a fact.

You think it’s impossible for anybody to have an informed opinion that disagrees with yours. You literally think yours is the only possible valid opinion. If that doesn’t set off big warning bells in your head, you are in dire need of a change in attitude.

This conversation is not productive, let’s end it.

Re: Python developers are embracing type hints

#399

Post by pdonis »

mjr00 wrote: post #74
pdonis wrote: post #65

Earlier quoted context omitted.

> The Reddit post falls under the case of "don't know" the type. No, it doesn't. The desired type is known; it's "Addable" (i.e., "doesn't throw an exception when the built-in add operator is used"). The problem is expressing that in Python's type notation in a way that catches all edge cases. > If you want to allow users to pass in any objects, try to add and fail at runtime Which is not what the post author wants t…

> The desired type is known; it's "Addable" (i.e., "doesn't throw an exception when the built-in add operator is used"). The mistake both you and the reddit posts' author make is treating the `+` operator the same as you would an interface method. Despite Python having __add__/__radd__ methods, this isn't true, nor is it true in many other programming languages. For example, Go doesn't have a way to express "can use…

> treating the `+` operator the same as you would an interface method

In other words, you agree that the Python type hint system does not give you a good, built-in way to express the "Addable" type.

Which means you are contradicting your claims that the type the article wants to express is "unknown" and that the article is advocating using "Any" for this case. The type is not unknown--it's exactly what I said: "doesn't throw an exception when using the + operator". That type is just not expressible in Python's type hint system in the way that would be needed. And "Any" doesn't address this problem, because the article is not saying that every pair of objects should be addable.

> "I can't express 'type which supports the '+' operator'" is an insanely esoteric and unusual case

I don't see why. Addition is a very commonly used operation, and being able to have a type system that can express "this function takes two arguments that can be added using the addition operator" seems like something any type system that delivers the goods it claims to deliver ought to have.

> unsupported in many languages

Yes, which means many languages have type systems that claim to deliver things they can't actually deliver. They can mostly deliver them, but "mostly" isn't what advocates of using type systems in all programs claim. So I think the article is making a useful point about the limitations of type systems.

> it's disingenuous to use it as an excuse for why people shouldn't bother with type hinting at all.

The article never says that either. You are attacking straw men.

Re: Python developers are embracing type hints

#400

Post by choomahs187 »

seanparsons wrote: post #308
mhitza wrote: post #208

Earlier quoted context omitted.

I think you're ignoring how for some of us, gradual typing, is a far better experience than languages with static types. For example what I like about PHPStan (tacked on static analysis through comments), that it offers so much flexibility when defining type constraints. Can even specify the literal values a function accepts besides the base type. And subtyping of nested array structures (basically support for comfor…

Not ignoring, I just didn't write an essay. In all that time working with TypeScript there was very little that I found to be gradually typed, it was either nothing or everything, hence my original comment. Sure some things might throw in a bunch of any/unknown types but those were very much the rarity and often some libraries were using incredibly complicated type definitions to make them as tight as possible.

Worked with python, typescript and now php, seems that phpstan allows this gradual typing, while typescript kinda forces you to start with strict in serious projects.
Post reply on HN