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

Python types have an expectations problem

medium.com

Post reply on HN
Print view View original

91–100 of 115 posts

Re: Python types have an expectations problem

#91

Post by MrJohz »

xg15 wrote: post #73
MrJohz wrote: post #67

Earlier quoted context omitted.

I'm not sure that's really a practical distinction between Typescript and Python. Most of the practical bundling setups I've seen use a tool like Babel or Esbuild, which doesn't do any type checking - instead the type checking is done as a linting/testing check beforehand, the same as with Python. And as you point out, even if you compile directly with Typescript, it will quite happily compile code that doesn't pass…

> Most of the practical bundling setups I've seen use a tool like Babel or Esbuild, which doesn't do any type checking - instead the type checking is done as a linting/testing check beforehand, the same as with Python. I think the difference is really one of UX (or DX I guess) and availability: Yes, if you already work with a toolchain, there won't be a difference. However, lots of people don't. If you just use the l…

Ah, I see what you mean. I guess it's a matter of framing - to me, choosing to install and run Typescript is the equivalent of choosing to install and run mypy - in both cases, you've added an additional tool above and beyond the default (Javascript and Python, respectively). I guess I don't really see Typescript as a separate language from Javascript in the sense, it's just Javascript with knobs on.

So there isn't really a "minimum" Typescript workflow because by using Typescript, you're already choosing to install additional tools and set up a more complicated workflow (compile then run, as opposed to just running Javascript). And if you'd do that with Javascript, you'd do that with Typescript as well.

(I think it's no coincidence that the long-term plan from the Typescript team is to have type annotations become part of regular Javascript syntax, in the same way that Python includes type annotations out of the box. In both cases, they'd be ignored by the parser and only used as metadata for the purposes of a separate type checking tool. The Typescript team do not see themselves as developing a separate language to Javascript, but rather just a dialect that includes types.)

Re: Python types have an expectations problem

#92

Post by Austizzle »

michaelt wrote: post #58
sevensor wrote: post #49

Earlier quoted context omitted.

Python's type hints are great as machine-checkable statements about constraints on the behavior of your code. It's not strictly true that they're unavailable at runtime. > Don't count on them at runtime here either If you're adventurous enough, you can reflect on the type hints and check things yourself at runtime, but you have to understand that the type hints aren't meant for this and they could well blow up in you…

> It's not strictly true that they're unavailable at runtime. So is it possible for me to enforce type hints at runtime, so my program crashes if a type is ever wrong? How do I turn this checking on?

Not exactly, but if you use something like Pydantic, you can check data at the boundaries of your application/library. If the data passes through the pydantic model, it's safe.

Add static type checking of your code through mypy or pyright, and now you can reasonably guarantee that your code is type safe, and stuff interacting with your code is type safe.

Not perfect, but it's a reasonable approach for important libraries!

Re: Python types have an expectations problem

#93

Post by nickm12 »

ReflectedImage wrote: post #59

Using static typing in Python is a serious mistake. The point of static typing is to allow an compiler to compile your code for performance reasons and nothing else. People do not normally compile Python code with a compiler. Static typing significantly increases code length compared to duck typing, significantly increases development times and significantly increases bug count per delivered software feature. It addi…

I previously worked at Dropbox, which had server codebase consisting of over 2 million lines of (untyped) Python. While I was there, Dropbox introduced type annotations into the codebase and used it as a testing group for Mypy, which was being developed largely at Dropbox, with both Jukka Lehtosalo and Guido van Rossum on staff.

I can say from that experience that pretty much everything you are claiming is wrong. Developers were enthusiastic about adopting type annotations. We found it made code easier to understand, gave better support from IDEs, made refactors easier, and caught bugs earlier.

Type-checking that codebase with Mypy was a technical challenge, but the Mypy team did a tremendous amount of work scale Mypy through caching and other optimizations. It was still slow, taking minutes at times, but way faster than the complete test suite.

Now, I will be the first to tell you not to write a 2Mloc server in Python, but if you happen to have created one, type annotations are huge boon to making it work.

Re: Python types have an expectations problem

#94

Post by nickm12 »

hauntsaninja wrote: post #30
sesgoe wrote: post #8

From my experience working on an older Python codebase, this issue is definitely a headache. It's extremely difficult to gradually adopt typing in an older Python codebase with almost no typing information because the only real "enforcement" option seems to be a CI pipeline running something like `mypy`. This issue compounds in a painful way. Because 99% of your codebase is starting out untyped, you have a couple of…

Lean heavier on a mypy config file. Make heavy use of per-module configuration, in particular, setting per-module ignore_errors = true for modules you’re not yet ready to type check. See https://mypy.readthedocs.io/en/stable/existing_code.html for some more advice.

This is great advice. It's called "gradual typing" for a reason. You should set things up so that your new code has typing enforced and then you gradually add typing to older code opportunistically. I've used Mypy and there are a lot of knobs that let you get more and more strict over time and also apply them on a file-by-file basis.

Re: Python types have an expectations problem

#95

Post by nickm12 »

teddyh wrote: post #3

Summarizing quote: “ Python type hints are a core part of the language, they even have standard library modules (typing), and yet they don’t do anything when used in that language without some external tooling. That, to me, is a bit of an expectations mismatch. ” I.e. they’re complaining that a type checker like mypy isn’t run by default.

Yup, this is the summary of the article. I can't say that I disagree, but in practice typechecking for Python was never going to happen if it had to go out as part of the CPython interpreter. Mypy was able to develop on its own terms, outside of the burden it would have if it had to support the entire Python ecosystem as part of a Python release.

Also, the comparison to typescript is not quite fair because you can't run Typescript in your browser; you have to set up a proper build system. You can do the same thing for Python and make typechecking (and linting and code formatting) part of your build and you get the exact same benefits.

Re: Python types have an expectations problem

#96

Post by pjmlp »

ReflectedImage wrote: post #59

Using static typing in Python is a serious mistake. The point of static typing is to allow an compiler to compile your code for performance reasons and nothing else. People do not normally compile Python code with a compiler. Static typing significantly increases code length compared to duck typing, significantly increases development times and significantly increases bug count per delivered software feature. It addi…

> The point of static typing is to allow an compiler to compile your code for performance reasons and nothing else

Sure, if one doesn't care about their code quality, after all everyone loves to write unit tests for every possible use case.

Re: Python types have an expectations problem

#97

Post by frou_dh »

ReflectedImage wrote: post #59

Using static typing in Python is a serious mistake. The point of static typing is to allow an compiler to compile your code for performance reasons and nothing else. People do not normally compile Python code with a compiler. Static typing significantly increases code length compared to duck typing, significantly increases development times and significantly increases bug count per delivered software feature. It addi…

> The point of static typing is to allow an compiler to compile your code for performance reasons and nothing else.

The relevant term is Type Checker. Static Type Checker: Something that checks types statically (i.e. by inspecting the source code without running it). Doesn't necessarily say anything about compilation, execution strategy, or indeed if the user program will ever be run at all.

Re: Python types have an expectations problem

#98

Post by misnome »

tyingq wrote: post #38
misnome wrote: post #24

Earlier quoted context omitted.

Unless you both a) Don't evaluate them at runtime, and b) import annotations from __future__, in which case it is generally safe to write them like this (and AFAIK all of the usual type-checking tools read them fine).

Nope. See https://bugs.python.org/issue45117

Yep. This is explicitly what I listed as "as long as you don't (a), evaluating at runtime". This extremely specific and rare case is outside of the scope of "Generally, this works". It means that some, very few definitions still need to be in old style, but the majority of your code is fine.

Re: Python types have an expectations problem

#99

Post by noone_youknow »

Sounds to me like the author has the “expectations problem”. I’m not a huge fan of type hints (though they are useful especially with modern IDEs) but it seems a stretch to say a thing is inherently flawed simply because it doesn’t work the way I expect it to…

Re: Python types have an expectations problem

#100

Post by robertlagrant »

drekipus wrote: post #86
robertlagrant wrote: post #71

Earlier quoted context omitted.

I knew someone would say this :) But my point is that how can I assign a negative number to an unsigned int in the first place?

I would argue that you're not. But I use python in my day job

Hah yes, me too. Python has the opposite problem. C changes the type of a supplied value to fit the declared variable type. Python changes the type of the variable to fit its value's (or reference's) type.

So in C if I assign a char literal to an int, I get an int. If I do the same in Python, I get a string.

In a strongly typed language, which I'm defining as "needs the left and right hand side of an assignment expression to match somehow", I'd get a type error.

Post reply on HN