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

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

uninformativ.de

Post reply on HN
Print view View original

201–210 of 597 posts

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

#201

Post by zmgsabst »

ImprobableTruth wrote: post #172
zmgsabst wrote: post #111

Earlier quoted context omitted.

Yep — I use mixed annotations on my Python code because as the person I’m responding to pointed out, they catch many small type errors. Dataclasses have been awesome. I’m also generally pro-types, but I think it’s worth having a discussion about this type system in the context of Pythonisms. - - - - - If you’re using “any” for most of your types, then it’s not providing value — an untyped statement implicitly has the…

Sure, but the idea behind gradual typing is that 'Any' should only be temporary. IMO if you're serious about it, stable code should at least pass strict type checking, if not completely forbid even explicit Any. >There’s a reason I brought up the JSON example: loading and manipulating JSON of varying structure is something I do a lot at work. Do you have a specific example that you find troublesome? For JSON with a f…

Your suggestion to “use a recursive union type” and that being “ugly … if your type checker doesn’t … support recursive types” being required to support varying JSON is my point:

Python types don’t support a common Pythonism used frequently in my work.

In fact, you admit that even fixed JSON can be difficult without a 3rd party library.

You’re lecturing me like I don’t understand types without realizing that you repeated my point about a gap in the current type system.

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

#202

Post by seti0Cha »

the_af wrote: post #86
seti0Cha wrote: post #79

Earlier quoted context omitted.

I just started using type hinting in Python and I love it. Maybe it's your tooling? I'm using neovim with LSP and pyright and the experience is very much like writing code in a Java IDE. As I code, it informs me where there are mistakes or pieces of code that need to be updated, catches typos, reminds me about forgotten imports, etc. It makes refactoring way easier because as you change signatures or object types it…

I want automated type checking outside the IDE. I want something that will catch other programmer's mistakes, not just mine. Without enforcing a specific IDE.

LSP support exists for many editors so you are not tied to a specific IDE. It can catch other programmers mistakes if you run it against their code. It doesn't turn Python into a statically typed language, but it's a lot better than nothing.

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

#203

Post by woojoo666 »

AnimalMuppet wrote: post #134
the_af wrote: post #58

Earlier quoted context omitted.

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 i…

Yes and no. C will let you do things like: *(unsigned long*)0xFFFFFF14 = 0x749235f8; It will not let you do things like: *0xFFFFFF14 = 0x749235f8; or char* s = "abc"; *(unsigned long*)0xFFFFFF14 = s; It also won't let you call thing.method without thing.method definitely existing. Best of all, all of these are enforced at compile time. Now, C absolutely will let you convert an int to a pointer, or a char to an int, o…

All true but all rather irrelevant to their point

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

#204

Post by folkrav »

Bedon292 wrote: post #176
sevensor wrote: post #157

Earlier quoted context omitted.

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

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.

I like the validation scripts being available in a repo so I can run them locally before pushing to CI, but I also often use WIP commits and quick fixups and then rebase before opening the PR, so pre-commit hooks are really annoying to my workflow. I more often than not just do `git commit --no-verify` or simply delete the git hook in `.git`, then just run it myself before pushing. Anyway CI will catch it, so I don't see much value in forcing it on individual machines.

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

#205

Post by lolinder »

gorgoiler wrote: post #162

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…

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.

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

#206

Post by heavyset_go »

civilized wrote: post #44
ledauphin wrote: post #20

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 b…

> 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 wor…

> 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 ()
    ----> 1 foo + 1

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

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

#207

Post by oefrha »

ledauphin wrote: post #50
dtech wrote: post #41

Earlier quoted context omitted.

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.

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 tha…

You can type Python dicts, see typing.TypedDict. It’s still lacking though, totality is all or nothing until py311, that is to say, TypedDict’s are either Required or Partial in TypeScript parlance. And you don’t get Pick, Omit, etc.

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

#208

Post by meatmanek »

kirbyfan64sos wrote: post #181
phailhaus wrote: post #67

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…

> 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: http…

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.

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

#209

Post by whimsicalism »

folkrav wrote: post #198
whimsicalism wrote: post #189

Earlier quoted context omitted.

I disagree with your last line, especially for Optional (Union in python is basically useless IMO).

Isn't `Optional[T]` just sugar for `Union[T, None]`?

Touché. I guess a common pattern I find myself doing for Union types is having if statements checking if something is of a type using reflection. When checking if it is none, it is more elegant.
Post reply on HN