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

Python developers are embracing type hints

pyrefly.org

Post reply on HN
Print view View original

531–540 of 581 posts

Re: Python developers are embracing type hints

#531

Post by dematz »

simonw wrote: post #449
lelanthran wrote: post #388

Earlier quoted context omitted.

> I didn't. I've been mainly a Python, PHP and JavaScript programmer for ~25 years Maybe its time you expanded your horizons, then. Try a few statically typed languages. Even plain C gives you a level of confidence in deployed code that you will not get in Python, PHP or Javascript.

I find automated tests give me plenty of confidence in the Python code I deploy. I'd rather deploy a codebase with comprehensive tests and no types over one with types and no tests. I've been dabbling with Go for a few projects and found the type system for that to be pleasant and non-frustrating.

I feel like Go is a very natural step from Python because it's still pretty easy and fast to start with.

(and if you want to embrace static types, the language starting with them might get advantages over an optional backwards compatible type system)

You may have read this already but the biggest surprise one of the Go creators had was Go was motivated by unhappiness with C++, and they expected to get C++ users, but instead people came from Python and Ruby: https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

Re: Python developers are embracing type hints

#532

Post by alfons_foobar »

_flux wrote: post #363
alfons_foobar wrote: post #291

Earlier quoted context omitted.

I ran into some code recently where this pattern caused me so much headache - class A has an attribute which is an instance of class B, and class B has a "parent" attribute (which points to the instance of class A that class B is an attribute of): class Foo: def __init__(self, bar): self.bar = bar class Bar: def __init__(self, foo): self.foo = foo Obviously both called into each other to do $THINGS... Pure madness. S…

Well, at times having a parent pointer is rather useful! E.g. a callback registration will be able to unregister itself from everywhere where it has been registered to, upon request. (One would want to use weak references in this case.)

Fair point!

Maybe I am just a bit burned by this particular example I ran into (where this pattern should IMO not have been used).

Re: Python developers are embracing type hints

#533

Post by dragonwriter »

pansa2 wrote: post #241
kketch wrote: post #237

Earlier quoted context omitted.

They don’t violate the spirit of the language. They are optional. They don’t change the behaviour at runtime. Type annotations can seem pointless indeed if you are unwilling to learn how to use them properly. Using a giant union to type your (generic) function is indeed silly, you just have to make that function generic as explained in another comment or I guess remove the type hints

> They don’t violate the spirit of the language. They are optional. That in itself violates the spirit of the language, IMO. “There should be one obvious way to do it”.

This is a popular misquote from the Zen of Python. The actual quote is “There should be one—and preferably only one—obvious way to do it.”

The misquote shifts the emphasis to uniqueness rather than having an obvious way to accomplish goals, and is probably a result of people disliking the “There is more than one way to do it” adage of Perl (and embraced by the Ruby community) looking to the Zen to find a banner for their opposing camp.

Re: Python developers are embracing type hints

#534

Post by chpatrick »

mcronce wrote: post #485
chpatrick wrote: post #263

Earlier quoted context omitted.

I went from mypy to pyright to basedpyright and just started checking out pyrefly (the OP), and it's very promising. It's written in Rust so it's very efficient.

You know you can just use a compiled language with statically checked types, right?

For the kind of work I'm using Python for (computer vision, ML), not really. The ecosystem isn't there and even when it's possible it would be much less productive for very little gain. Typed Python actually works quite well in my experience. We do use C++ for some hand-written things that need to be fast or use libraries like CGAL, but it has a lot of disadvantages like the lack of a REPL, slow compile times and bad error messages.

Re: Python developers are embracing type hints

#535

Post by dragonwriter »

bityard wrote: post #418
pansa2 wrote: post #241

Earlier quoted context omitted.

> They don’t violate the spirit of the language. They are optional. That in itself violates the spirit of the language, IMO. “There should be one obvious way to do it”.

"There should only be one way to do it" has not really been a thing in Python for at least the last decade or longer. It was originally meant as a counterpoint to Perl's "there's more than one way to do it," to show that the Python developers put a priority on quality and depth of features rather than quantity. But times change and these days, Python is a much larger language with a bigger community, and there is a l…

> "There should only be one way to do it" has not really been a thing in Python for at least the last decade or longer.

It never was a thing in Python, it is a misquote of the Zen of Python that apparently became popular as a reaction against the TMTOWTDI motto of the Perl community.

Re: Python developers are embracing type hints

#536

Post by Hackbraten »

hauntsaninja wrote: post #475
Marazan wrote: post #288

Earlier quoted context omitted.

Ok, so this is just one of many examples but the most immediate one is where I don't care about the immutable sanctity of the variable I have just declared. I often use Python for data munging and I'll frequently write code that goes foo = initial_value ... foo = paritally_cleaned_up_value ... if check: foo = fianllylikethis else: foo = orlikethis Where the type of the value being assigned to foo is different each ti…

pyright will accept this. mypy should accept this when using --allow-redefinition-new as well

> mypy should accept this when using --allow-redefinition-new as well

TIL, thank you!

Re: Python developers are embracing type hints

#537

Post by chpatrick »

scuff3d wrote: post #507
chpatrick wrote: post #476

Earlier quoted context omitted.

I disagree and I've been using Haskell professionally for ten years so I know what I'm talking about when it comes to types. Typed Python isn't perfect but it's totally workable with medium sized projects and gives you access to a great ecosystem.

Everyone knows Haskell is only used for white papers :p Yeah it's workable, and better than nothing. But it's not better than having an actual static type system. 1. It's optional. Even if you get your team on board you are inevitably going to have to work with libraries that don't use type hints 2. It's inconsistent, which makes sense given that it's tacked onto a language never intended for it. 3. I have seen some…

What job are we talking about and why is TypeScript or typed Python actually bad at it?

Re: Python developers are embracing type hints

#538

Post by albrewer »

Dr_Birdbrain wrote: post #215

I actually don’t like python type hints! At my work we have a jit compiler that requires type hints under some conditions. Aside from that, I avoid them as much as possible. The reason is that they are not really a part of the language, they violate the spirit of the language, and in high-usage parts of code they quickly become a complete mess. For example a common failure mode in my work’s codebase is that some func…

Define a protocol[0] that declares it implements `__getitem__` and type annotate with that protocol. Whatever properties are needed inside the function can be described in other protocols.

These are similar to interfaces in C# or traits in Rust - you describe what the parameter _does_ instead of what it _is_.

[0]: https://typing.python.org/en/latest/spec/protocol.html

Re: Python developers are embracing type hints

#539

Post by pdonis »

mjr00 wrote: post #500
pdonis wrote: post #492

Earlier quoted context omitted.

> it is factually and objectively an esoteric and unusual case. Sorry, but your unsupported opinion is not "factual and objective". > If your argument is that all type systems are bad or deficient I said no such thing, any more than the article did. Again you are attacking a straw man. (If you had said "limited in what they can express", I might buy that. But you didn't.) I think I've said all I have to say in this s…

It's factual and objective that billions, if not trillions of lines of Java and Go have been deployed and the language still cannot express "supports the + operator" as a type constraint. In production, non-academic settings, people don't generally write code like that. Again, this is an esoteric limitation from the perspective of writing code that runs working software, not a programming language theory perspective.

How many of those lines of code would have benefited from being able to express that type constraint, if the language made it possible?

You have no idea, and nor does anyone else. But that's what you would need "factual and objective" evidence about to support the claim you made.

By your argument, anything that programming languages don't currently support, must be an "esoteric limitation" because billions if not trillions of lines of code have been written without it. Which would mean programming languages would never add new features at all. But it's certainly "factual and objective" that programming languages add new features all the time. Maybe this is another feature that at some point a language will add, and programmers will find it useful. You don't even seem to be considering such a possibility.

Re: Python developers are embracing type hints

#540

Post by pdonis »

zahlman wrote: post #530
mjr00 wrote: post #445

Earlier quoted context omitted.

> This is a strange and aggressive bit of pedantry. There's nothing pedantic about it. That's how Python works, and getting into the nuts and bolts of how Python works is precisely why the linked article makes type hinting appear so difficult. > The entire point is that we have an intuition about what can be "added", but can't express it in the type system in any meaningful way. As the post explores, your intuition i…

> your intuition is also incorrect. No, it definitionally isn't. The entire point is that `+` is being used to represent operations where `+` makes intuitive sense. When language designers are revisiting the decision to use the `+` symbol to represent string concatenation, how many of them are thinking about algebraic fields, seriously? And all of this is exactly why you can't just say that it's universally bad API d…

> you can't just say that it's universally bad API design to "accept all types"

Note, though, that that's not really the API design choice that's at stake here. Python will still throw an exception at runtime if you use the + operator between objects that don't support being added together. So the API design choice is between that error showing up as a runtime exception, vs. showing up as flagged by the type checker prior to runtime.

Or, to put it another way, the API design choice is whether or not to insist that your language provide explicit type definitions (or at least a way to express them) for every single interface it supports, even implicit ones like the + operator, and even given that user code can redefine such interfaces using magic methods. Python's API design choice is to not care, even with its type hinting system--i.e., to accept that there will be interface definitions that simply can't be captured using the type hinting system. I personally am fine with that choice, but it is a design choice that language users should be aware of.

Post reply on HN