5 ms·

I love typing in Python. I learnt programming with C++ and OOPs. It was freeing when I took up Python to note care about types, but I have come to enjoy types a

I love typing in Python. I learnt programming with C++ and OOPs. It was freeing when I took up Python to note care about types, but I have come to enjoy types as I got older. But, boy have we gone overboard with this now? The modern libraries seem to be creating types for the sake of them. I am drowning in nested types that seem to never reach native types. The pain is code examples of the libraries don’t even show them. Like copy paste an OpenAI example and see if LSP is happy for example. Now I have gotten in this situation where I am mentally avoiding type errors of some libraries and edging into wishing Pydantic et al never happened.

AlienRobot 1y ago
My love for python was critically hurt when I learned about typing.TYPE_CHECKING. For those unaware, due to the dynamic nature of Python, you declare a variable type like this foo: Type This might look like Typescript, but it isn't because "Type" is actually an object. In python classes and functions are first-class objects that you can pass around and assign to variables. The obvious problem of this is that you can only use as a type an object that in "normal python" would be available in the scope of that line, which means that you can't do this: def foo() -> Bar: return Bar() class Bar: pass Because "Bar" is defined AFTER foo() it isn't in the scope when foo() is declared. To get around this you use this weird string-like syntax: def foo() -> "Bar": return Bar() This already looks ugly enough that should make Pythonists ask "Python... what are you doing?" but it gets worse. If you have a cyclic reference between two files, something that works out of the box in statically typed languages like Java, and that works in Python when you aren't using type hints because every object is the same "type" until it quacks like a duck, that isn't going to work if you try to use type hints in python because you're going to end up with a cyclic import. More specifically, you don't need cyclic imports in Python normally because you don't need the types, but you HAVE to import the types to add type hints, which introduces cyclic imports JUST to add type hints. To get around this, the solution is to use this monstrosity: if typing.TYPE_CHECKING: import Foo from foo And that's code that only "runs" when the static type check is statically checking the types. Nobody wants Python 4 but this was such an incredibly convoluted way to add this feature, specially when you consider that it means every module now "over-imports" just to add type hints that they previously didn't have to. Every time I see it makes me think that if type checks are so important maybe we shouldn't be programming Python to begin with.
- dandiep 1y ago
  Isn’t this solved in 3.14/PEP-649?
  - analog31 1y ago
    At last, Pi-thon.
  - aw1621107 1y ago
    I want to say it (or something similar at least) was originally addressed by from __future__ import annotations back in Python 3.7/3.8 or thereabouts? I definitely remember having to use stringified types a while back but I haven't needed to for quite a while now.
    - sgarland 1y ago
      Yes, annotations allows you to use the declared types as they are, no strings.
      - FreakLegion 1y ago
        It turns them into thunks (formerly strings) automatically, an important detail if you're inspecting annotations at run time because the performance hit of resolving the actual type can be significant.
        sgarland 1y ago
        TIL, thanks! It looks like 3.14 is also changing it so that all evaluations are lazy.
- zahlman 1y ago
  > that isn't going to work if you try to use type hints in python because you're going to end up with a cyclic import. More specifically, you don't need cyclic imports in Python normally because you don't need the types, but you HAVE to import the types to add type hints, which introduces cyclic imports JUST to add type hints. Yes, `typing.TYPE_CHECKING` is there so that you can conditionally avoid imports that are only needed for type annotations. And yes, importing modules can have side effects and performance implications. And yes, I agree it's ugly as sin. But Python does in fact allow for cyclic imports — as long as you're importing the modules themselves, rather than importing names `from` those modules. (By the way, the syntax is the other way around: `from ... import ...`.) https://stackoverflow.com/questions/744373/ https://stackoverflow.com/questions/744373/
pton_xd 1y ago
> But, boy have we gone overboard with this now? The modern libraries seem to be creating types for the sake of them. I am drowning in nested types that seem to never reach native types. Thought you were talking about TypeScript for a moment there.
- afiori 1y ago
  Except that typescript structural typing and features make it much easier to swim. Also python is far less aggressive with lint warnings so it is much easier to make mistakes
ninetyninenine 1y ago
I learned C++ before learning python as well and python felt like a breath of fresh air. At first I thought it was because of the lack of types. But in actuality the lack of types was a detriment for python. It was an illusion. The reason why python felt so much better was because it had clear error messages and a clear path to find errors and bugs. In C++ memory leaks and seg faults are always hidden from view so EVEN though C++ is statically typed, it's actually practically less safe then python and much more harder to debug. The whole python and ruby thing exploding in popularity back in the day was a trick. It was an illusion. We didn't like it more because of the lack of typing. These languages were embraced because they weren't C or C++. It took a decade for people to realize this with type hints and typescript. This was a huge technical debate and now all those people were against types are proven utterly wrong.
- raincole 1y ago
  > It was an illusion. We didn't like it more because of the lack of typing. These languages were embraced because they weren't C or C++. It's an illusion only you once had. Java (a language that is not C or C++) got mainstream way before Python.
  - Too 1y ago
    Java on the other hand had the most verbose syntax known to man, especially those early versions of it. Nowadays it’s getting more tolerable.
  - afiori 1y ago
    I don't understand, the parent says that not being C/C++ was a strong point and you give an counter example of a successful language that is not C/C++
- deleted 1y ago
  [deleted]
_zoltan_ 1y ago
modern C++ is great, to be honest.

AlienRobot 1y ago

My love for python was critically hurt when I learned about typing.TYPE_CHECKING. For those unaware, due to the dynamic nature of Python, you declare a variable type like this foo: Type This might look like Typescript, but it isn't because "Type" is actually an object. In python classes and functions are first-class objects that you can pass around and assign to variables. The obvious problem of this is that you can only use as a type an object that in "normal python" would be available in the scope of that line, which means that you can't do this: def foo() -> Bar: return Bar() class Bar: pass Because "Bar" is defined AFTER foo() it isn't in the scope when foo() is declared. To get around this you use this weird string-like syntax: def foo() -> "Bar": return Bar() This already looks ugly enough that should make Pythonists ask "Python... what are you doing?" but it gets worse. If you have a cyclic reference between two files, something that works out of the box in statically typed languages like Java, and that works in Python when you aren't using type hints because every object is the same "type" until it quacks like a duck, that isn't going to work if you try to use type hints in python because you're going to end up with a cyclic import. More specifically, you don't need cyclic imports in Python normally because you don't need the types, but you HAVE to import the types to add type hints, which introduces cyclic imports JUST to add type hints. To get around this, the solution is to use this monstrosity: if typing.TYPE_CHECKING: import Foo from foo And that's code that only "runs" when the static type check is statically checking the types. Nobody wants Python 4 but this was such an incredibly convoluted way to add this feature, specially when you consider that it means every module now "over-imports" just to add type hints that they previously didn't have to. Every time I see it makes me think that if type checks are so important maybe we shouldn't be programming Python to begin with.

dandiep 1y ago
Isn’t this solved in 3.14/PEP-649?
- analog31 1y ago
  At last, Pi-thon.
- aw1621107 1y ago
  I want to say it (or something similar at least) was originally addressed by from __future__ import annotations back in Python 3.7/3.8 or thereabouts? I definitely remember having to use stringified types a while back but I haven't needed to for quite a while now.
  - sgarland 1y ago
    Yes, annotations allows you to use the declared types as they are, no strings.
    - FreakLegion 1y ago
      It turns them into thunks (formerly strings) automatically, an important detail if you're inspecting annotations at run time because the performance hit of resolving the actual type can be significant.
      - sgarland 1y ago
        TIL, thanks! It looks like 3.14 is also changing it so that all evaluations are lazy.
zahlman 1y ago
> that isn't going to work if you try to use type hints in python because you're going to end up with a cyclic import. More specifically, you don't need cyclic imports in Python normally because you don't need the types, but you HAVE to import the types to add type hints, which introduces cyclic imports JUST to add type hints. Yes, `typing.TYPE_CHECKING` is there so that you can conditionally avoid imports that are only needed for type annotations. And yes, importing modules can have side effects and performance implications. And yes, I agree it's ugly as sin. But Python does in fact allow for cyclic imports — as long as you're importing the modules themselves, rather than importing names `from` those modules. (By the way, the syntax is the other way around: `from ... import ...`.) https://stackoverflow.com/questions/744373/ https://stackoverflow.com/questions/744373/

pton_xd 1y ago

> But, boy have we gone overboard with this now? The modern libraries seem to be creating types for the sake of them. I am drowning in nested types that seem to never reach native types. Thought you were talking about TypeScript for a moment there.

afiori 1y ago
Except that typescript structural typing and features make it much easier to swim. Also python is far less aggressive with lint warnings so it is much easier to make mistakes

ninetyninenine 1y ago

I learned C++ before learning python as well and python felt like a breath of fresh air. At first I thought it was because of the lack of types. But in actuality the lack of types was a detriment for python. It was an illusion. The reason why python felt so much better was because it had clear error messages and a clear path to find errors and bugs. In C++ memory leaks and seg faults are always hidden from view so EVEN though C++ is statically typed, it's actually practically less safe then python and much more harder to debug. The whole python and ruby thing exploding in popularity back in the day was a trick. It was an illusion. We didn't like it more because of the lack of typing. These languages were embraced because they weren't C or C++. It took a decade for people to realize this with type hints and typescript. This was a huge technical debate and now all those people were against types are proven utterly wrong.

raincole 1y ago
> It was an illusion. We didn't like it more because of the lack of typing. These languages were embraced because they weren't C or C++. It's an illusion only you once had. Java (a language that is not C or C++) got mainstream way before Python.
- Too 1y ago
  Java on the other hand had the most verbose syntax known to man, especially those early versions of it. Nowadays it’s getting more tolerable.
- afiori 1y ago
  I don't understand, the parent says that not being C/C++ was a strong point and you give an counter example of a successful language that is not C/C++
deleted 1y ago
[deleted]

_zoltan_ 1y ago

modern C++ is great, to be honest.