Mypy 1.6 • Hacker News Board

Re: Mypy 1.6

#111

Post by VeejayRampay » Thu, Oct 19, 2023, 9:09 AM UTC

networked wrote: post #65

VeejayRampay wrote: post #45

I really wish we had a ruff equivalent for python type checking, mypy is OK but it's really slow

Pyre, written in OCaml, is the closest thing that's stable. It has been discussed on HN a couple of times. Here is the 2021 discussion: https://news.ycombinator.com/item?id=27107647 . Note that Pyre does not support Windows ( https://github.com/facebook/pyre-check/issues/554 ) and only provides wheels for x86_64 Linux and macOS ( https://pypi.org/project/pyre-check/0.9.18/#files ). While I don't use Windows, it makes…

there's something a bit strange with pyre though, I feel like it makes it too difficult to check types in a subdirectory (like you have to provide a configuration or something)

it works well and fast for a whole codebase though

Re: Mypy 1.6

#112

Post by frou_dh » Thu, Oct 19, 2023, 11:07 AM UTC

nerdponx wrote: post #33

brigadier132 wrote: post #27

Earlier quoted context omitted.

> I find "dynamic during runtime + static during development" to be a highly potent combination Except you miss out on massive performance gains and your software runs 10x slower because of runtime type-checking. It's actually the worst of both worlds.

The point is that you don't need runtime type checking if you can trust your type checker.

I have seen people point out that this confusing discussion can be avoided by accepting that types are purely a static property of terms (not only identifiers and literals) in source code, and that what many insist on calling dynamic types are tags, not types.

Re: Mypy 1.6

#113

Post by randomdata » Thu, Oct 19, 2023, 3:51 PM UTC

gaganyaan wrote: post #62

randomdata wrote: post #50

Earlier quoted context omitted.

> but the larger purpose of the code is obscured in all the "if err != nil" weeds. That's the difference between script and system programming. When writing scripts, one is only concerned about carrying out a certain task and if anything goes wrong the whole thing can bail. Systems are more robust. When things go wrong they cannot just fail. They need to recover gracefully and do something meaningful in the failed st…

Go still picked a terrible option. The `?` operator in Rust is way better, proving that systems languages don't have to suffer Go's choice.

That is quite different. ? in Rust signifies "this code is not important"

Which even in systems is unavoidable, to be fair. Sometimes failure just isn't important. The division between systems and scripts is not perfect. But, that will be the uncommon case in systems. It is not certain that really needs a symbol in which to draw attention. (An implementation may need a symbol, but that's beyond this discussion)

Re: Mypy 1.6

#114

Post by gaganyaan » Fri, Oct 20, 2023, 12:12 PM UTC

randomdata wrote: post #113

gaganyaan wrote: post #62

Earlier quoted context omitted.

Go still picked a terrible option. The `?` operator in Rust is way better, proving that systems languages don't have to suffer Go's choice.

That is quite different. ? in Rust signifies "this code is not important" Which even in systems is unavoidable, to be fair. Sometimes failure just isn't important. The division between systems and scripts is not perfect. But, that will be the uncommon case in systems. It is not certain that really needs a symbol in which to draw attention. (An implementation may need a symbol, but that's beyond this discussion)

I'm not sure why you think it's unimportant. You seem to be confusing its purpose, and making distinction between systems and scripts that doesn't apply here.

Rust's whole error handling, including the ? operator work great for embedded systems where Go isn't enough of a systems language to even run.

EDIT: I think you're confused. The ? operator says "I'm not handling this specially here". That doesn't mean the error is just propagated to the top like an uncaught exception in a Python script. It allows you any level of granular handling you'd like.