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

121–130 of 597 posts

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

#121

Post by ledauphin »

the_af wrote: post #98
seti0Cha wrote: post #91

Earlier quoted context omitted.

Have you looked at the tools recently? LSP + Pyright is very fast and plugins exist for many editors. Or maybe it's slow on larger codebases or very large files? I don't have that broad an experience yet, but so far it's been very good.

Sorry, I wasn't clear: I want command-line tooling for the build pipeline, not for the IDE or any individual developer.

mypy is quite fast at the command line. certainly fast enough for CI usage, where speed is generally less critical than in an IDE.

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

#122

Post by the_af »

hoosieree wrote: post #107
the_af wrote: post #65

Earlier quoted context omitted.

Honest question: what's the point of type hinting without type checking ? I must be mistaken, but I always thought "type hinting" was a synonym of "optional type annotations". But if you're not using those annotations for actual type checking at some point , what are they good for?

Just a couple hours ago, a student asked me what was the type of a parameter in a function I wrote. A type hint would have answered their question immediately (as they were reading the code).

Yes, but checked type annotations will do the same, plus they are actually enforced.

An unenforced type hint is just like any comment: likely to get out of sync with the code, and a human must do all the work of keeping it up to date.

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

#123

Post by ledauphin »

theodorejb wrote: post #97
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…

> 1. If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime. Counterexample: PHP is a dynamic language which enforces static type declarations at runtime.

Meh. you can do the same thing in Python if you really want - there are dynamic interpreter shims that can do this.

The point is that it is not expected by definition, since by definition, static != runtime.

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

#124

Post by Banana699 »

the__alchemist wrote: post #81
the_af wrote: post #65

Earlier quoted context omitted.

Honest question: what's the point of type hinting without type checking ? I must be mistaken, but I always thought "type hinting" was a synonym of "optional type annotations". But if you're not using those annotations for actual type checking at some point , what are they good for?

The IDE catches type errors, and it lets you do things like simulate structs using @dataclass.

@dataclass has nothing to do with the IDE in python, it's a decorator, sugaring a higher order function.

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

#125

Post by the_af »

wronglyprepaid wrote: post #112
the_af wrote: post #89

Earlier quoted context omitted.

> The same as in literally every other language with static typing No, obviously not the same, otherwise I wouldn't be complaining. They are not even on par with Typescript, which I'm not a fan of either. > [type hints] tell you when you make type errors Not according to other comments I seem to be getting here. Other people are arguing type hints are not primarily for checking , but a form of notation for documentat…

> No, obviously not the same, otherwise I wouldn't be complaining. What is the difference? > They are not even on par with Typescript, which I'm not a fan of either. Go is not on par with Typescript or Python, I still don't think it is okay for people to just say fuckit and `interface{}` it all and it is still shit to work with code that does use `interface{}`. At least Python with mypy has null safety, something tha…

> What is the difference?

I'm not going to repeat myself, I already told you.

I find mypy slow, unsatisfying, inconsistent, and it fails to catch many type errors. No, I'm not going to go look in my work laptop to give you an example.

> There are some places it is worse than other statically typed languages, others where it is better.

In most places it is way worse, and I'll find it very hard to find common ground with anyone who disagrees on this.

Feel free to disagree, but I don't find this conversation useful.

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

#126

Post by tialaramex »

ledauphin wrote: post #87
smu3l wrote: post #83

What is the precise definition of static typing? Both the article and many comments in this thread refer to static typing or static type hints in Python. But as I've always understood it, static typing means that types are checked and enforced at compile time. And if python is not compiled, the notion of static typing in python does not make sense. So do I have it wrong? Or is the term ambiguous?

static in this case can be understood to mean simply "prior to (or separate from) runtime". In other words, it's based on what you can check _without_ running the code. It's worth noting that nearly every statically-typed language currently in existence has two separate "type systems" - the static type system which is the formal type system offered to the programmer, plus a runtime type system enforced, at minimum, b…

> It's worth noting that nearly every statically-typed language currently in existence has either two separate "type systems"

Either that or... ? You should probably complete this thought.

I don't think the distinction you've claimed make much sense, but perhaps you had an alternative which you just never explained.

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

#127

Post by the_af »

ledauphin wrote: post #121
the_af wrote: post #98

Earlier quoted context omitted.

Sorry, I wasn't clear: I want command-line tooling for the build pipeline, not for the IDE or any individual developer.

mypy is quite fast at the command line. certainly fast enough for CI usage, where speed is generally less critical than in an IDE.

Not my experience!

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

#128

Post by xarope »

the_af wrote: post #73
xarope wrote: post #70

Earlier quoted context omitted.

as a reminder for yourself/others who need to read/maintain your code? (I am often reminded of my perl days, where something I thought idiomatic 3 days ago, is now completely incomprehensible when I just want to make a minor change)

So is it simply a standardized comment then? I will have a really bad time convincing my team mates, if that's the case. It's especially bad because, like any comment, it can say one thing but the code may do something different (actually happened to me).

it's a comment which can trigger an action (if you run mypy).

So, unlike a comment, which does nothing, if you run mypy and get some warnings, you can then do something about it (whether it's just # type: ignore or you realise you made a mistake with allocating to variable new_value versus newvalue/new_valu/etc)

(btw, in case someone objects, some comments DO do something, e.g. golang's godoc examples)

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

#129

Post by ledauphin »

the_af wrote: post #101
ledauphin wrote: post #76

Earlier quoted context omitted.

Python does and always has enforced types at runtime. This is called duck-typing. If you're not familiar with the concept of strong+dynamic, it is easy to see how this could be confusing. This may help. https://stackoverflow.com/questions/2351190/static-dynamic-v... Static type annotations by definition are not enforced at runtime. This has been true of every language that has ever used static typing, including C, C+…

> Yes, it is possible to annotate types in Python incorrectly. It's possible to do this in all other languages that allow type-unsafe behavior (whether natively or via reflection, etc). This may be less common in some languages than in others, but it is fundamentally possible in the vast majority of languages that perform static typing, because those types are fundamentally enforced at analysis time, not runtime. It…

I think your (and the article's) argument could be summarized as "static type annotations without automated enforcement by actually running a type checker considered harmful".

Since this argument is not meaningfully different from "comments that are lies considered harmful", it seems fair to expect reasonable people to dismiss it as uninteresting.

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

#130

Post by giyanani »

fluster wrote: post #108
the_af wrote: post #65

Earlier quoted context omitted.

Honest question: what's the point of type hinting without type checking ? I must be mistaken, but I always thought "type hinting" was a synonym of "optional type annotations". But if you're not using those annotations for actual type checking at some point , what are they good for?

I view them as similar to python's "private" functions, which are really just functions starting with an underscore. The interpreter will let anyone call them like any other function, but the general rule is don't do it, unless you know what you're doing and are willing to deal with the internals changing. Python typing is like that. If I say a function takes a List[int], but you know I'm just calling a for loop, you…

The typing (>= python 3.6?) and collections (>= python 3.8?) packages have definitions for a bunch of protocols (basically interfaces for structural typing).

So for that List[int] example, you probably want to take a(n) Iterable[int], Iterator[int], or Collection[int] instead, depending on exactly how you use it.

Post reply on HN