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

111–120 of 597 posts

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

#111

Post by zmgsabst »

ImprobableTruth wrote: post #49
zmgsabst wrote: post #40

Earlier quoted context omitted.

That’s the point though: Duck typing and heterogeneous dictionaries are (and have been) standard Python. Adding a type system which doesn’t respect duck typing by trying to access the member even when the types don’t match or which can’t express standard idioms used in Python seems a poor architectural choice. It’s not saying that Python’s type system is “too much discipline”, but rather that the type system doesn’t…

No offense, but have you actually given it a shot? Duck typing is supported and you can get virtually all use cases of heterogenous dictionaries by using union types and duck typing. The article even touches on this. edit: To be more precise: The article specifically mentions that accessing invalid members give you a type error, but posits that people will probably not bother and just use 'any' instead. How is that n…

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 type “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.

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

#112

Post by wronglyprepaid »

the_af wrote: post #89
wronglyprepaid wrote: post #85

Earlier quoted context omitted.

> The tooling that pays attention to type hints is slow as molasses or difficult to use or understand. I use mypy daily on big codebases, it is fine, not fast, but fine. > The type hints themselves are of dubious use. They tell you when you make type errors, they help you understand what type things should be. The same as in literally every other language with static typing. There is nothing special here, nothing dif…

> 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 that Java and Go does not have. There are some places it is worse than other statically typed languages, others where it is better.

> Standardized, go-to tools that work in the build pipeline and that catch most errors without taking a long time to do so.

It is mypy. What actual type errors does mypy not catch that you want it to catch? Why can't you use it in the build pipeline? I do it every day, it catches all the errors it should. The one complaint I can maybe see is the duct type compatibility complaint, and it is not really something that comes up that often for me, and definitely not something I would say invalidates the whole concept.

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

#113

Post by mindwok »

POiNTx wrote: post #35

Don't let perfect be the enemy of good. Type hints are usefull especially in large codebases. I find myself using them with minimal effort and they can catch bugs that otherwise wouldn't be catched.

Exactly. The article has some valid criticisms of the weirdness of type hinting, but type hinting is a pretty large paradigm shift added to a 20+ year old language. Yes it will have shortcomings, but in my opinion has made working with large Python codebases actually possible. It’s a good thing.

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

#114

Post by zmgsabst »

ljojiasdf wrote: post #99
zmgsabst wrote: post #57

Earlier quoted context omitted.

I read 0544 and the proposal for protocols fails to support the main benefit of duck typing, as it requires the substituted-for class to be defined as a protocol. Traditionally, duck typing is used to inject types into a library that isn’t expecting extension at that particular point — eg, substituting a test class for a real class in a data object that normally wouldn’t be a protocol. I’m not seeing how that PEP add…

Can you re-read please? https://peps.python.org/pep-0544/#:~:text=Structural%20subty... . > substituted-for class to be defined as a protocol. ... which is false > Similarly, the heading on the dictionary says “for a fixed set of keys” — but what if I want a dynamic heterodox dict? Eg, unpacking JSON. You can quite obviously decode to recursive types (e.g. using pydantic), not sure what the problem is.

Your link appears not to work (for me) — can you cite what you believe I have incorrect?

This section seems to agree with me, where it explains why normal classes can’t be subclassed to protocols:

> Now, C is a subtype of Proto, and Proto is a subtype of Base. But C cannot be a subtype of Base (since the latter is not a protocol). This situation would be really weird. In addition, there is an ambiguity about whether attributes of Base should become protocol members of Proto.

https://peps.python.org/pep-0544/#protocols-subclassing-norm...

- - - -

I’m not sure why you think it’s “obvious” that you can use a third party library to solve the problem — or why that addresses my complaint that the built-in type system doesn’t work for that.

If anything, the existence of a third party library hints the standard library doesn’t cover the use case.

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

#115

Post by the_af »

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…

Thanks for your reply.

> I view them as similar to python's "private" functions, which are really just functions starting with an underscore

Good analogy! I wish they were more like "private" class methods, which are prefixed by a double underscore and result in name-mangling: you can still access them from outside if you want, but the code will really look ugly. And you absolutely cannot access them accidentally.

Which is what type checking should be all about, right? Preventing accidental misuse?

> 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 can ignore it and hand me a Set[int]. Maybe it breaks some day, but you're allowed to take that risk, if you have a need.

That's what drives me crazy. I come from the statically typed world. This bit of Python's philosophy really clashes with my world view. "These types are just something someone wrote, they may or may not accurately describe the code" seems so wasteful and unhelpful to me...

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

#116

Post by rurp »

After working in Python without type hinting for quite some time before joining a team that uses it heavily, I was pretty skeptical about how useful it would be give the many rough edges I had read about. After using both approaches for a while I think that type hints are both very flawed and surprisingly useful.

Yes MyPy and type hinting in general has many limitations, rough edges, and occasionally baffling behavior. Despite all that, I think it is helpful for pretty much any Python project. Type hinting does catch a lot of potential issues and the syntax is very simple. I tend to fill in the types even on a first pass at some code since they help so much in tracking various interactions.

I think the bottom line is that something doesn't have to be great in order to be useful.

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

#117

Post by the_af »

rurp wrote: post #110
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?

They are useful for catching issue before code is committed or deployed. At my work we run mypy as part of our test suite, so failing type checks will block a merge or deploy.

How will they catch issues if they are not checked? The comment I'm replying to insinuated type hinting is just for documentation, and not necessarily meant to be actually checked by the tooling.

You seem to be describing actual type checking, which I understand (though in my opinion, mypy is not a satisfying tool for this).

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

#118

Post by Humphrey »

While I love the idea behind Python's type hints, they are merely a shadow of the success of TypeScript.

Like the author, I've mostly given up on adding type hints in my Python code. I now only use them when I want to help my IDE find autocomplete suggestions.

Whereas TypeScript was a game changer for JavaScript. I used to hate JavaScript, but somehow TypeScript has become one of my favourite languages! How has the advent of Typing has changed my opinion on these two very similar languages?

- JavaScript without types is a mess, whereas Python comparatively was much better, esp since it does runtime duck type checks.

- Python type hints are much similar to Flow type hints in JS, which I tried, but ditched for the same reasons as Python type hints.

- I was hesitant to try TS's all in approach, cause it was harder to introduce into a project, but after having converted a number of projects to TS, I can see that going all-in is a much better approach than just adding hints as you go.

- TS does checks at many more levels. Eg, if a property is optional or could have different types, it is a syntax error if I don't check the value is valid before use.

- TS does an amazing job of auto-detecting types, so most of the time you don't need to specify types, and it enforces these just as if you declared them.

- TS has reached the critical mass were most popular packages now include type definitions, I very rarely have to add @types/* anymore. This means you get full intelisense on all 3rd packages! I spend a lot less time referring to documentation now!

In hindsight, compiling out types is a great work flow. TypeScript is so good that it has made me enjoy Python less. If there was ever a Python equivalent to TS which reached a critical mass of support, I'd jump all-in in a heartbeat.

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

#119

Post by ActorNightly »

IshKebab wrote: post #28

Yeah they're pretty bad but they are still better than nothing. If you are in the unfortunately position of having to use Python I would recommend using them. I would also strongly recommend using Pyright (the default checker in VSCode) over MyPy. It's so much better, and the author is really responsive on Github. But yeah, in general trying to use type hints in Python is like trying to discuss philosophy in a mental…

The whole reason Python and JS surpassed most all other languages is specifically because you can write code fast, without worrying about strict definition of data structures.

The issues with python code bases aren't from a lack of strict typing or type support, but from a lack of a good testing framework.

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

#120

Post by cardanome »

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. However, good news! Python has always been strongly typed, and _does_ enforce types at runtime!

So PHP is not a dynamically typed programming language according to you? It enforces type hints at runtime just fine.

There is nothing in the definition of dynamically typed languages that says they can't use type hints to perform runtime checks.

Post reply on HN