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

561–570 of 581 posts

Re: Python developers are embracing type hints

#561

Post by hnlmorg »

mixmastamyk wrote: post #555
hnlmorg wrote: post #549

Earlier quoted context omitted.

My point is if you don’t know what types you need, then you can’t be trusted to write the function to begin with. So you don’t actually save that much time in the end. typing out type names simply isn’t the time consuming part of prototyping. But when it comes to refactoring, having type safety makes it very easy to use static analysis (typically the compiler) check for type-related bugs during that refactor. I’ve sp…

Right after hello world you need a list of arguments or a dictionary of numbers to names. Types. Writing map = {}, is a few times faster than map: Dictionary[int, str] = {}. Now multiply by ten instances. Oh wait, I’m going to change that to a tuple of pairs instead. It takes me about three times longer to write equivalent Rust than Python, and sometimes it’s worth it.

Rust is slower to prototype than Python because Rust is a low level language. Not because it’s strictly typed. So that’s not really a fair comparison. For example, assembly doesn’t have any types at all and yet is slower to prototype than Rust.

Let’s take Visual Basic 6, for example. That was very quick to prototype in even with “option explicit” (basically forcing type declarations) defined. Quicker, even, than Python.

Typescript isn’t any slower to prototype in than vanilla JavaScript (bar setting up the build pipeline — man does JavaScript ecosystem really suck at DevEx!).

Writing map = {} only saves you a few keystrokes. And Unless you’re typing really slowly with one finger like an 80 year old using a keyboard for the first time, you’ll find the real input bottleneck isn’t how quickly you can type your data structures into code, but how quickly your brain can turn a product spec / Jira ticket into a mental abstraction.

> Oh wait, I’m going to change that to a tuple of pairs instead

And that’s exactly when you want the static analysis of a strict type system to jump in and say “hang on mate, you’ve forgotten to change these references too” ;)

Having worked on various code bases across a variety of different languages, the refactors that always scare me the most isn’t the large code bases, it’s the ones in Python or JavaScript because I don’t have a robust type system providing me with compile-time safety.

There’s an old adage that goes something like this: “don’t put off to runtime what can be done in compile time.”

As computers have gotten exponentially faster, we’ve seemed to have forgotten this rule. And to our own detriment.

Re: Python developers are embracing type hints

#562

Post by LudwigNagasena »

jkrejcha wrote: post #491
knome wrote: post #347

Earlier quoted context omitted.

>why not a protocol type it was a sin that python's type system was initially released as a nominal type system. they should have been the target from day one. being unable to just say "this takes anything that you can call .hello() and .world() on" was ridiculous, as that was part of the ethos of the dynamically typed python ecosystem. typechecking was generally frowned upon, with the idea that you should accept any…

I disagree. I think, if the decision was made today, it probably would have ended up being structural, but the fact that it isn't enables (but doesn't necessarily force) Python to be more correct than if it weren't (whereas forced structural typing has a certain ceiling of correctness). Really it enabled the Python type system to work as well as it does, as opposed to TypeScript, where soundness is completely thrown…

TypeScript sacrificed soundness to make it easier to gradually type old JS code and to allow specific common patterns. There is no ceiling for correctness of structural typing bar naming conflicts.

Re: Python developers are embracing type hints

#563

Post by zbentley »

seniorsassycat wrote: post #73
zbentley wrote: post #72

Earlier quoted context omitted.

The best docs are the ones you can trust are accurate. The second best docs are ones that you can programmatically validate. The worst docs are the ones that can’t be validated without lots of specialized effort. Python’s type hints are in the second category.

Do you have an example of the first?

When I wrote that, I was thinking about typed, compiled languages' documentation generated by the compiler at build time. Assuming that version drift ("D'oh, I was reading the docs for v1.2.3 but running v4.5.6") is user error and not a docs-trustworthiness issue, that'd qualify.

But now that I'm coming back to it, I think that this might be a larger category than I first envisioned, including projects whose build/release processes very reliably include the generation+validation+publication of updated docs. That doesn't imply a specific language or release automation, just a strong track record of doc-accuracy linked to releases.

In other words, if a user can validate/regenerate the docs for a project, that gets it 9/10 points. The remaining point is the squishier "the first party docs are always available and well-validated for accuracy" stuff.

Re: Python developers are embracing type hints

#564

Post by zelphirkalt »

Balinares wrote: post #316
zelphirkalt wrote: post #281

Earlier quoted context omitted.

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.

It's a boon if the goal is to write code then go home. It's a loaded footgun if the goal is to compose a stack and run it in production within SLO. Python type hints manage to largely preserve the flexibility while seriously increasing confidence in the correctness, and lack of crashing corner cases, of each component. There's really no good case against them at this point outside of one-off scripts. (And even there,…

I think with types there is a risk of typing things too early or too strictly or types nudging one to go in a direction, that reduces the applicability and flexibility of the final outcome. Some things can be difficult to express in types and then people choose easier to type solutions, that are not as flexible and introduce more work later, when things need to change, due to that inflexibility or limited applicability.

Re: Python developers are embracing type hints

#565

Post by chpatrick »

scuff3d wrote: post #557
chpatrick wrote: post #554

Earlier quoted context omitted.

Happily using both in production here, guess I'm just hallucinating.

I'm not saying you _can't_ do it. You could write production software in Bash if you really wanted to. I'm saying there are much better options.

I don't think writing your frontend in Rust instead of TypeScript or your computer vision pipeline in Java would be better at all. We rewrote our frontend in GHCJS (Haskell) at one point and it was a colossal waste of time.

Re: Python developers are embracing type hints

#566

Post by lexicality »

Narushia wrote: post #552
letmeinhere wrote: post #544

Earlier quoted context omitted.

Exactly, I want it to complain if I try to manipulate the fields/methods of an unknown object.

By default, Mypy warns you if try to reassign a method of any object[1]. It will also warn you when you access non-existent attributes[2]. So if you have a variable typed as `object`, the only attributes you can manipulate without the type checker nagging are `__doc__`, `__dict__`, `__module__`, and `__annotations__`. Since there are very few reasons to ever reassign or manipulate these attributes on an instance, I t…

In my opinion the sheer volume of "close enough" choices is what ruins Python's type system.

It's "close enough" to a usable type system that it's worth using, but it's full of so many edge cases and so many situations where they decided that it would be easier if they forced programmers to try and make reality match the type system rather than the type system match reality.

No wonder a lot of people in the comments here say they don't use it...

Re: Python developers are embracing type hints

#567

Post by mixmastamyk »

hnlmorg wrote: post #561
mixmastamyk wrote: post #555

Earlier quoted context omitted.

Right after hello world you need a list of arguments or a dictionary of numbers to names. Types. Writing map = {}, is a few times faster than map: Dictionary[int, str] = {}. Now multiply by ten instances. Oh wait, I’m going to change that to a tuple of pairs instead. It takes me about three times longer to write equivalent Rust than Python, and sometimes it’s worth it.

Rust is slower to prototype than Python because Rust is a low level language. Not because it’s strictly typed. So that’s not really a fair comparison. For example, assembly doesn’t have any types at all and yet is slower to prototype than Rust. Let’s take Visual Basic 6, for example. That was very quick to prototype in even with “option explicit” (basically forcing type declarations) defined. Quicker, even, than Pyth…

Rust has many high-level constructs available as well as libraries ready and available if you stick to "python-like" things. Saving a "few keystrokes" is not what I described, it was specific: `: Dictionary[int, str]`, this is hard to remember, write, and read, and there's lots of punctuation. Many defs are even harder to compose.

Cementing that in early on is a big pre-optimization (ie waste) when it has a large likelyhood of being deleted. Refactors are not large at this point, and changes trivial to fix.

Re: Python developers are embracing type hints

#568

Post by zbentley »

zbentley wrote: post #563
seniorsassycat wrote: post #73

Earlier quoted context omitted.

Do you have an example of the first?

When I wrote that, I was thinking about typed, compiled languages' documentation generated by the compiler at build time. Assuming that version drift ("D'oh, I was reading the docs for v1.2.3 but running v4.5.6") is user error and not a docs-trustworthiness issue, that'd qualify. But now that I'm coming back to it, I think that this might be a larger category than I first envisioned, including projects whose build/re…

Another example of extremely far towards the "accurate and trustworthy" end of the spectrum: asking a running webservice for the e.g. Swagger/OpenAPI schema that it is currently using to serve requests. If you can trust that those docs are produced (on request or cached at deployment time) by the same backend application instances serving other requests, you'd have pretty high assurance.

Nobody does that, though. Instead they all auto-publish their OpenAPI schemas through rickety-ass, fail-soft build systems to flaky, unmonitored CDNs. Then they get mad at users who tell them when their API docs don't match their running APIs.

Re: Python developers are embracing type hints

#569

Post by pdonis »

mjr00 wrote: post #556
zahlman wrote: post #530

Earlier quoted context omitted.

> your intuition is also incorrect. No, it definitionally isn't. The entire point is that `+` is being used to represent operations where `+` makes intuitive sense. When language designers are revisiting the decision to use the `+` symbol to represent string concatenation, how many of them are thinking about algebraic fields, seriously? And all of this is exactly why you can't just say that it's universally bad API d…

> No, it definitionally isn't. The entire point is that `+` is being used to represent operations where `+` makes intuitive sense. Huh? There's no restriction in Python's type system that says `+` has to "make sense". import requests class Smoothie: def __init__(self, fruits): self.fruits = fruits def __repr__(self): return " and ".join(self.fruits) + " smoothie" class Fruit: def __init__(self, name): self._name = na…

> There's no restriction in Python's type system that says `+` has to "make sense".

There's no restriction in any language that all code has to make sense. You can write nonsense in any language. Sure, particular types of nonsense might be easier to write in Python than in some other languages, but nonsense is still nonsense.

And it's also nonsense to argue that an API designer has to support whatever nonsense a coder can dream up just because it's valid code in that language. The GP post was not talking about algebraic fields or mathematical definitions or what nonsense the language permits, but about API design. The basic issue is that Python's extremely dynamic nature makes some reasonable API designs basically inexpressible. That's just a tradeoff one has to accept when using Python. Every language has tradeoffs.

Re: Python developers are embracing type hints

#570

Post by mixmastamyk »

lukaslalinsky wrote: post #525
dragonwriter wrote: post #514

Earlier quoted context omitted.

> What's the point if runtime ignores them. Ideally, with static checking, the runtime shouldnn’t need to care about types because cide that typechecks shouldn’t be capable of not behaving according to the types declared. Python, even with the most restrictive settings in nost typecheckers, may not quite achieve that, but it certainly reeuces the chance of surprises lf that kind compared to typing information in docs…

The thing is, when typing was being discussed, I was hoping it would lead to JavaScript-like evolution, where the dynamic nature of Python could be restricted if I use the right types, and a JIT compiler could optimize parts of the code, expecting u32 ints instead of PyObjects.

Cython is still around.
Post reply on HN