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

291–300 of 581 posts

Re: Python developers are embracing type hints

#291

Post by alfons_foobar »

_flux wrote: post #251
Too wrote: post #218

Earlier quoted context omitted.

> If the type is a class with methods, then this method doesn't work Use typing.Self

I meant if you have two classes that need to refer to each other. But good pointer anyway, I hadn't noticed it, thanks!

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.

So my suggestion: Try not to have interdependent classes :D

Re: Python developers are embracing type hints

#292

Post by whilenot-dev »

zelphirkalt wrote: post #276

Python's dynamic nature can make it quite difficult to express some things correctly. That, or the type checkers have issues when it comes to understanding what would be considered safe in other languages. Years ago when I knew far less about types and programming, I never had such problems in for example Java. It was sometimes stupid, but I always found a way to express things. Although it could also be, that I mere…

That doesn't sound like it'd have something to do with the dynamic nature of python. Type checking is a static analysis of the source code, so if you'd want something to be inferred dynamically, then you'll have to make use of generics:

  from typing import Callable
  
  
  class Pipeline[T]:
    def __init__(self, value: T) -> None:
      self._value = value
  
    def step[U](self, cb: Callable[[T], U]) -> 'Pipeline[U]':
      return Pipeline(cb(self._value))
  
    def terminate(self) -> T:
      return self._value
  
  
  def _float_to_int(value: float) -> int:
    return int(value)
  
  
  def _int_to_str(value: int) -> str:
    return str(value)
  
  
  def main() -> None:
    result = Pipeline(3.14)\
      .step(_float_to_int)\
      .step(_int_to_str)\
      .terminate()
    
    print(result)

  
  if __name__ == '__main__':
    main()
You could further constrain the generic type through type variables: https://docs.python.org/3/library/typing.html#typing.TypeVar

Re: Python developers are embracing type hints

#293

Post by davidatbu »

geenat wrote: post #284

Company selling a product based on what's being glazed in the article. It's always a small vocal fraction or they'd be using a different language.

I doubt that Meta (the company that sponsors the work on pyrefly) is looking forward to selling a product based on Python typing (assuming that's what's "what's being glazed in the article").

Re: Python developers are embracing type hints

#295

Post by tinnet »

pansa2 wrote: post #127
seanparsons wrote: post #110

As a static typing advocate I do find it funny how all the popular dynamic languages have slowly become statically typed. After decades of people saying it's not at all necessary and being so critical of statically typed languages. When I was working on a fairly large TypeScript project it became the norm for dependencies to have type definitions in a relatively short space of time.

> all the popular dynamic languages have slowly become statically typed I’ve heard this before, but it’s not really true. Yes, maybe the majority of JavaScript code is now statically-typed, via Typescript. Some percentage of Python code is (I don’t know the numbers). But that’s about it. Very few people are using static typing in Ruby, Lua, Clojure, Julia, etc.

At least in ruby theres mayor code bases using stripes sorbet and the official RBS standard for type hints. Notably its big code bases with large amounts of developers, fitting in with the trend most people in this discussion point to.

Re: Python developers are embracing type hints

#296

Post by circadian »

stellalo wrote: post #135
circadian wrote: post #19

I really love Python for it's expedience, but type hints still feel like they don't belong in the language. They don't seem to come with the benefits of optimisation that you get with static typed languages. As someone who uses C and Julia (and wishes they had time for Rust), introducing solid typing yields better end results at a minimum, or is a requirement at the other end of the scale. The extra typing clarificat…

> The extra typing clarification in python makes the code harder to read It’s funny, because for me is quite the opposite: I find myself reading Python more easily when there are type annotations. One caveat might be: for that to happen, I need to know that type checking is also in place, or else my brain dismissed annotations in that they could just be noise. I guess this is why in Julia or Rust or C you have this s…

I think the face they fundamentally don't look after you is where my resistance comes from. Will try and evaluate some newer code that uses them and see how I get on a bit more :)

Re: Python developers are embracing type hints

#297

Post by LudwigNagasena »

seanparsons wrote: post #110

As a static typing advocate I do find it funny how all the popular dynamic languages have slowly become statically typed. After decades of people saying it's not at all necessary and being so critical of statically typed languages. When I was working on a fairly large TypeScript project it became the norm for dependencies to have type definitions in a relatively short space of time.

Static typing used to be too rigid and annoying to the point of being counterproductive. After decades of improvement of parsers and IDEs they finally became usable for rapid development.

Re: Python developers are embracing type hints

#298

Post by LudwigNagasena »

ItsHarper wrote: post #76
seniorsassycat wrote: post #73

Earlier quoted context omitted.

Do you have an example of the first?

Languages with strong static type systems

Is there a mainstream language where you can’t arbitrarily cast a variable to any other type?

Re: Python developers are embracing type hints

#299

Post by fn-mote »

zelphirkalt wrote: post #281
9dev wrote: post #225

Earlier quoted context omitted.

That's the same complaints people had about TypeScript in the beginning, when libraries such as Express used to accept a wide range of input options that would be a pain to express in types properly. If you look at where the ecosystem is now, though, you'll see proper type stubs, and most libraries get written in TS in the first place anyway. When editing TS code, you get auto-completion out of the box, even for deep…

Because the flexibility has been a boon and not a problem. The problem only comes when you try to express everything in the type system, that is third party (the type checkers for it) and added on top.

> Because the flexibility has been a boon and not a problem

Well, you could say that the problem in this case was the lack of documentation, if you wanted. The type signature could be part of the documentation, from this point of view.

Let me give a kind-of-concrete example: one year I was working through a fast.ai course. They have a Python layer above the raw ML stuff. At the time, the library documentation was mediocre: the code worked, there were examples, and the course explained what was covered in the course. There were no type hints. It's free (gratis), I'm not complaining. However, once I tried making my own things, I constantly ran into questions about "can this function do X" and it was really hard to figure out whether my earlier code was wrong or whether the function was never intended to work with the X situation. In my case, type hints would have cleared up most of the problems.

Re: Python developers are embracing type hints

#300

Post by yladiz »

kketch wrote: post #237
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…

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

Actually in Python it can. Since the type hints are accessible at runtime, library authors can for example change which values in kwargs are allowed based on the type of the argument.

So on the language level it doesn’t directly change the behavior, but it is possible to use the types to affect the way code works, which is unintuitive. I think it was a bad decision to allow this, and Python should have opted for a TypeScript style approach.

Post reply on HN