Hacker News Reader

Comment by Too | Hacker News Reader

This is trivial to solve by simply not having circular imports. Place the types in one file and the usage of it in others.

This has many benefits, like forcing you to think about the dependencies and layers of your architecture. Here is a good read about why, from F# that has the same limitation https://fsharpforfunandprofit.com/posts/cyclic-dependencies/

As others already mentioned, importing __annotations__ also works.

View on HN

If the type is a class with methods, then this method doesn't work, though adding intermediate interface classes (possibly with Generic types) might help in most cases. Python static type system isn't quite the same level as F#.

> Well, these complaints are unfounded.

"You're holding it wrong." I've also coded quite a bit of OCaml and it had the same limitation (which is where F# picked it up in the first place), and while the issue can be worked around, it still seemed to creep up at times. Rust, also with some virtual OCaml ancestry, went completely the opposite way.

My view is that while in principle it's a nice property that you can read and and understand a piece of code by starting from the top and going to the bottom (and a REPL is going to do exactly that), in practice it's not the ultimate nice property to uphold.

> 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

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).

Reply on news.ycombinator.com