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

551–560 of 581 posts

Re: Python developers are embracing type hints

#551

Post by sota_pop »

grumbel wrote: post #357
sota_pop wrote: post #317

Python types - all the onus of static types, with none of the performance! I enjoy packages like pydantic and SOME simple static typing, but if I’m implementing anything truly OOP, I wouldn’t first reach for Python anyway; the language doesn’t even do multiple constructors or public/private props. Edit: as a side note, I was interested to learn that for more verbose type specification, it’s possible to define a type…

The most annoying part is that the type checking exists outside the regular runtime. I constantly run into situation where the type checker is happy, but the thing explodes at runtime or the type checker keeps complaining about working code. And different type checkers will even complain about different things regularly too. It's a whole lot of work making every part of the system happy and the result still feels ext…

They ARE only “hints” afterall.

Re: Python developers are embracing type hints

#552

Post by Narushia »

letmeinhere wrote: post #544
lexicality wrote: post #452

Earlier quoted context omitted.

No, because the type checker should prevent you interacting with `Unknown` until you tie it down, but `object` is technically a valid type

Exactly, I want it to complain if I try to manipulate the fields/methods of an unknown object.

By default, Mypy warns you if try to reassign a method of any object[1]. It will also warn you when you access non-existent attributes[2]. So if you have a variable typed as `object`, the only attributes you can manipulate without the type checker nagging are `__doc__`, `__dict__`, `__module__`, and `__annotations__`. Since there are very few reasons to ever reassign or manipulate these attributes on an instance, I think the `object` type gets us pretty darn close to an "unknown" type in practice.

There was a proposal[3] for an unknown type in the Python typing repository, but it was rejected on the grounds that `object` is close enough.

[1]: https://mypy.readthedocs.io/en/stable/error_code_list.html#c...

[2]: https://mypy.readthedocs.io/en/stable/error_code_list.html#c...

[3]: https://github.com/python/typing/issues/1835

Re: Python developers are embracing type hints

#553

Post by scuff3d »

chpatrick wrote: post #537
scuff3d wrote: post #507

Earlier quoted context omitted.

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?

I'd say Typescript/JavaScript on the backend are a bad idea across the board. That's not really because of this conversation, just in general.

The comment about Typescript was really about JavaScript. It's a patch on top of JavaScript, which is a shit show and should have been replaced before it ended up forming the backbone of the internet.

Python, typed or otherwise, isn't good for anything past prototyping, piping a bunch of machine learning libraries together, or maybe a small project. The minute the project gets large or starts to move towards actual production software Python should be dropped.

Re: Python developers are embracing type hints

#554

Post by chpatrick »

scuff3d wrote: post #553
chpatrick wrote: post #537

Earlier quoted context omitted.

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

I'd say Typescript/JavaScript on the backend are a bad idea across the board. That's not really because of this conversation, just in general. The comment about Typescript was really about JavaScript. It's a patch on top of JavaScript, which is a shit show and should have been replaced before it ended up forming the backbone of the internet. Python, typed or otherwise, isn't good for anything past prototyping, piping…

Happily using both in production here, guess I'm just hallucinating.

Re: Python developers are embracing type hints

#555

Post by mixmastamyk »

hnlmorg wrote: post #549
mixmastamyk wrote: post #542

Earlier quoted context omitted.

Python doesn’t have “no types,” in fact it is strict about types. You just don’t have to waste time reading and writing them early on. While a boon during prototyping, a project may need more structural support as the design solidifies, it grows, or a varied, growing team takes responsibility. At some point those factors dominate, to the extent “may need” support approaches “must have.”

My point is if you don’t know what types you need, then you can’t be trusted to write the function to begin with. So you don’t actually save that much time in the end. typing out type names simply isn’t the time consuming part of prototyping. But when it comes to refactoring, having type safety makes it very easy to use static analysis (typically the compiler) check for type-related bugs during that refactor. I’ve sp…

Right after hello world you need a list of arguments or a dictionary of numbers to names. Types.

Writing map = {}, is a few times faster than map: Dictionary[int, str] = {}. Now multiply by ten instances. Oh wait, I’m going to change that to a tuple of pairs instead.

It takes me about three times longer to write equivalent Rust than Python, and sometimes it’s worth it.

Re: Python developers are embracing type hints

#556

Post by mjr00 »

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…

> No, it definitionally isn't. The entire point is that `+` is being used to represent operations where `+` makes intuitive sense.

Huh? There's no restriction in Python's type system that says `+` has to "make sense".

  import requests

  class Smoothie:
      def __init__(self, fruits):
          self.fruits = fruits

      def __repr__(self):
          return " and ".join(self.fruits) + " smoothie"

  class Fruit:
      def __init__(self, name):
          self._name = name

      def __add__(self, other):
          if isinstance(other, Fruit):
              return Smoothie([self._name, other._name])
          return requests.get("https://google.com")

  if __name__ == "__main__":
      print(Fruit("banana") + Fruit("mango"))
      print(Fruit("banana") + 123)
> banana and mango smoothie

>

So we have Fruit + Fruit = Smoothie. Overly cute, but sensible from a CS101 OOP definition and potentially code someone might encounter in the real world, and demonstrates how not all T + T -> T. And we have Fruit + number = requests.Response. Complete nonsense, but totally valid in Python. If you're writing a generic method `slow_add` that needs to support `a + b` for any two types -- yes, you have to support this nonsense.

Re: Python developers are embracing type hints

#557

Post by scuff3d »

chpatrick wrote: post #554
scuff3d wrote: post #553

Earlier quoted context omitted.

I'd say Typescript/JavaScript on the backend are a bad idea across the board. That's not really because of this conversation, just in general. The comment about Typescript was really about JavaScript. It's a patch on top of JavaScript, which is a shit show and should have been replaced before it ended up forming the backbone of the internet. Python, typed or otherwise, isn't good for anything past prototyping, piping…

Happily using both in production here, guess I'm just hallucinating.

I'm not saying you _can't_ do it. You could write production software in Bash if you really wanted to. I'm saying there are much better options.

Re: Python developers are embracing type hints

#558

Post by fragmede »

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…

> something that is indexable by ints. > ...Dict[int, Any]...

If that is exactly what you want, then define a Protocol: from __future__ import annotations from typing import Protocol, TypeVar

    T = TypeVar("T")
    K = TypeVar("K")
    
    class GetItem(Protocol[K, T]):
        def __getitem__(self, key: K, /) -> T: ...
    
    
    def first(xs: GetItem[int, T]) -> T:
        return xs[0]
Then you can call "first" with a list or a tuple or a numpy array, but it will fail if you give it a dict. There is also collections.abc.Sequence, which is a type that has .__getitem__(int), .__getitem__(slice), .__len__ and is iterable. There are a couple of other useful ones in collections.abc as well, including Mapping (which you can use to do Mapping[int, t], which may be of interest to you), Reversible, Callable, Sized, and Iterable.

Re: Python developers are embracing type hints

#559

Post by procaryote »

dirkc wrote: post #520
procaryote wrote: post #274

Earlier quoted context omitted.

Writing tests is harder work than writing the equvalent number of type hints though

Type hints and/or stronger typing in other languages are not good substitutes for testing. I sometimes worry that teams with strong preferences for strong typing have a false sense of security.

People write tests in statically typed languages too, it's just that there's a whole class of bugs that you don't have to test for.

Re: Python developers are embracing type hints

#560

Post by IshKebab »

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?

Python is the second most popular programming language in the world. It's not that easy to avoid.
Post reply on HN