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

281–290 of 581 posts

Re: Python developers are embracing type hints

#281

Post by zelphirkalt »

9dev wrote: post #225
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…

That's the same complaints people had about TypeScript in the beginning, when libraries such as Express used to accept a wide range of input options that would be a pain to express in types properly. If you look at where the ecosystem is now, though, you'll see proper type stubs, and most libraries get written in TS in the first place anyway. When editing TS code, you get auto-completion out of the box, even for deep…

Because the flexibility has been a boon and not a problem. The problem only comes when you try to express everything in the type system, that is third party (the type checkers for it) and added on top.

Re: Python developers are embracing type hints

#283

Post by MrJohz »

mjr00 wrote: post #78
MrJohz wrote: post #75

Earlier quoted context omitted.

How is "responds to the `__add__` method" anywhere close to equivalent to `Any`?

If your implication is that "implementing __add__ means you can use the + operator", you are incorrect. This is a common Python beginner mistake, but it isn't really a Python type checking issue, this is complexity with Python built-ins and how they interact with magic methods. My suggestion -- don't rely on magic methods.

I guess that's the difference between the Python and the TypeScript approach here. In general, if something is possible, valid, and idiomatic in JavaScript, then TypeScript attempts to model it in the type system. That's how you get things like conditional types and mapped types that allow the type system to validate quite complex patterns. That makes the type system more complex, but it means that it's possible to use existing JavaScript patterns and code. TypeScript is quite deliberately not a new language, but a way of describing the implicit types used in JavaScript. Tools like `any` are therefore an absolute last resort, and you want to avoid it wherever possible.

When I've used Python's type checkers, I have more the feeling that the goal is to create a new, typed subset of the language, that is less capable but also easier to apply types to. Then anything that falls outside that subset gets `Any` applied to it and that's good enough. The problem I find with that is that `Any` is incredibly infective - as soon as it shows up somewhere in a program, it's very difficult to prevent it from leaking all over the place, meaning you're often back in the same place you were before you added types, but now with the added nuisance of a bunch of types as documentation that you can't trust.

Re: Python developers are embracing type hints

#285

Post by zelphirkalt »

kketch wrote: post #237
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…

They don’t violate the spirit of the language. They are optional. They don’t change the behaviour at runtime. Type annotations can seem pointless indeed if you are unwilling to learn how to use them properly. Using a giant union to type your (generic) function is indeed silly, you just have to make that function generic as explained in another comment or I guess remove the type hints

Yeah, but then you get into the issues with when and where generic types are bound and narrowed, which can then make it more complicated, at which point one might be better off stepping back, redesigning, or letting go of perfect type hint coverage, for dynamic constructs, that one couldn't even write in another type safe language.

Re: Python developers are embracing type hints

#286

Post by pydry »

novok wrote: post #194
pydry wrote: post #138

Earlier quoted context omitted.

Here we are because: * Types are expensive and dont tend to pay off on spikey/experimental/MVP code, most of which gets thrown away. * Types are incredibly valuable on hardened production code. * Most good production code started out spikey, experimental or as an MVP and transitioned . And so here we are with gradual typing because "throwing away all the code and rewriting it to be "perfect" in another language" has…

I've found the transition point where types are useful to start even within a few hundred lines of code, and I've found types are not that restrictive if at all, especially if the language started out typed. The rare case I need to discard types that is available usually, and a code smell your doing something wrong. Even within a recent toy 1h python interview question having types would've saved me some issues and c…

The transition to where type hints become valuable or even necessary isnt about how many lines of code you have it is about how much you rely upon their correctness.

Type strictness also isnt binary. A program with lots of dicts that should be classes doesnt get much safer just because you wrote : dict[str, dict] everywhere.

Re: Python developers are embracing type hints

#287

Post by TZubiri »

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…

So the type is anything that implements the index function ([], or __getitem__), I thnink that's a Sequence, similar to Iterable.

>from typing import Sequence

>def third(something: Sequence):

> return indexable[3]

however if all you are doing is just iterate over the thing, what you actually need is an Iterable

>from typing import Iterable

>def average(something:Iterable):

> for thing in something:

> ...

Statistically, the odds of a language being wrong, are much lower than the programmer being wrong. Not to say that there aren't valid critiques of python, but we must think of the creators of programming languages and their creations as the top of the field. If a 1400 chess elo player criticizes Magnus Carlsen's chess theory, it's more likely that the player is missing some theory rather than he found a hole in Carlsen's game, the player is better served by approaching a problem with the mentality that he is the problem, rather than the master.

Re: Python developers are embracing type hints

#288

Post by Marazan »

Hackbraten wrote: post #196
Marazan wrote: post #136

My view on typing in Python (a language I have used for decades) is that if I wanted types I would use a language designed from the ground up with strong and consistent typing built-in. Not bolt on a sort of type system which actively fights against the way I use the language on a day to day basis. I use plenty of statically typed languages, Python's type hinting does not bring me joy.

> Not bolt on a sort of type system which actively fights against the way I use the language on a day to day basis. Can you help me out with an example of a Python usage pattern against which the type system seems to be fighting?

Ok, so this is just one of many examples but the most immediate one is where I don't care about the immutable sanctity of the variable I have just declared.

I often use Python for data munging and I'll frequently write code that goes

  foo = initial_value
  ...
  foo = paritally_cleaned_up_value
  ...
  if check:
   foo = fianllylikethis
  else:
   foo = orlikethis
Where the type of the value being assigned to foo is different each time. Now, obviously (in this simplistic example that misses subtleties) I could declare a new variable for each transformation step or do some composite type building type thing or refactor this into separate functions for each step that requires a different type but all of those options are unnecessary busy work for what should be a few simple lines of code.

Re: Python developers are embracing type hints

#289

Post by TZubiri »

pansa2 wrote: post #241
kketch wrote: post #237

Earlier quoted context omitted.

They don’t violate the spirit of the language. They are optional. They don’t change the behaviour at runtime. Type annotations can seem pointless indeed if you are unwilling to learn how to use them properly. Using a giant union to type your (generic) function is indeed silly, you just have to make that function generic as explained in another comment or I guess remove the type hints

> They don’t violate the spirit of the language. They are optional. That in itself violates the spirit of the language, IMO. “There should be one obvious way to do it”.

How so? There is one way to do it. If you want typing, you use type hints. You wouldn't say that, say, functions are unpythonic because you can either use functions or not use them, therefore there's two ways to do things, would you?

Re: Python developers are embracing type hints

#290

Post by huflungdung »

adalacelove wrote: post #118
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.

People adapt to the circumstances. A lot of Python uses are no longer about fast iteration on the REPL. Instead of that we are shipping Python to execute in clusters on very long running jobs or inside servers. It's not only about having to start all over after hours, it's simply that concurrent and distributed execution environments are hostile to interactive programming. Now you can't afford to wait for an exceptio…

[dead]
Post reply on HN