4 ms·

Python types just work. Just use these 30 libraries, spice up your IDE with settings and voila /s. This is garbage and moving backwards as a programmer. I love

Python types just work. Just use these 30 libraries, spice up your IDE with settings and voila /s. This is garbage and moving backwards as a programmer. I loved python when it was easy to use with any editor and with few plugins. Now I'm just going to switch to a statically typed language where I don't have to install a zillion plugins to get first class typing.

wheelerof4te 5y ago
This is the crust of the problem. Python type-hints bind you to a lot of other sister projects of Python, which makes you question if they are even official addition to the language. I think that's also what the OP's article tries to convey.
Spivak 5y ago
Python type annotations in the language are nothing more then allowing you put any Python expression in the "type slot" and have it be syntatically valid. They don't do anything. All the functionality is 3rd party packages taking advantage of their existence.
- nine_zeros 5y ago
  My codebase is more complex than str, text, dict, int, bool. So developers are creating complex custom types with union[custom_type_1, custom_type_2] where each custom type could have more unions of other custom types. These custom types then get imported everywhere. It is utter garbage.
  - Spivak 5y ago
    I don't follow. So some 3rd party library will define a type like Routes = Union[RouteSet, List[Union[str, Route]]] and this is bad? The complexity is already there, you just don't want to see it?
    - nine_zeros 5y ago
      No, my own devs will write insane nested types at the detriment of all developers who end up looking at that code later. Routes = Union[GooglyRoutes, MetaRoutes] Where, GooglyRoutes=Union[List[CloudyRoutes], Sequence[AdseyRoutes]] Where CloudyRoutes = Union[RouteContainers] And then they'd import these types all over the python repo creating all kinds of import issues. Fml.
      - Spivak 5y ago
        What’s the alternative? You have some method like def register_route(route): … That gets called with all the types in that nested union but now the type checker can’t help you if GoogleRoute and Metaroute have different attribute names or that .append isn’t a method on sequences but is on lists. Like that unwieldy nested union already exists in your code, adding the type just documents it and the type checker makes you handle all the cases. Is there something specific about imports that don’t work with type alises?
        nine_zeros 5y ago
        In a language with a sensible typing system, I would create class Route: _route = [] # can be GoogleyRoute or MetaRoute And import Route everywhere. That import would help in creating instance objects AND be used as a type. But we can't do this with the spaghetti that python type annotations are.
  - cjalmeida 5y ago
    You know you can use type aliases, right?
    - nine_zeros 5y ago
      So now you are going to create complex types and then create aliases for them? What are we even developing at this point?
      - icedchai 5y ago
        Some people love this. They spend more time screwing around with types and related tooling than writing actual working code.
cjalmeida 5y ago
As many already said, 99% is just a modern IDE with a one-click-install plugin. Also, I don't know the grip with productivity tools.
- nine_zeros 5y ago
  But a language relying so heavily on IDE means that the language is severely lacking. People not using said "modern" IDEs are just stuck out of using the language. Is this progress? Even with modern IDEs, there is a difference between what different IDEs do. So now the language is stuck with different IDEs doing different things. Is the progress? It also means that anyone developing a future IDE can no longer support these languages without support. Is this progress? God forbid someone tries python on a new architecture where new the entire complex toolchain is not going to be available. They just can't use this language. Is this progress?
  - kortex 5y ago
    I'm pretty sure the IDE uses either mypy or pyrite under the hood. I don't know how this is a sign of python lacking. Works just fine in jupyter notebooks, too, and that is hardly an "IDE" (though it does have Jedi autocomplete).
    - nine_zeros 5y ago
      > I don't know how this is a sign of python lacking If a language cannot be written or used effectively by devs without IDE, it is an incomplete language. This has happened in the past is Java. Within a few years, Python will bloat up like Java and everyone will move on to greener pastures.
- bspammer 5y ago
  I think the difference is largely a culture problem. Most python devs think of typing as a “nice to have” extra, whereas someone using a typed-at-compile-time language see it as an essential feature of good code. You can see the results of this in the fact that a lot of popular 3rd party python libraries still don’t have type hints. Even with typing, how often do you see Any in python vs Object in Java?

wheelerof4te 5y ago

This is the crust of the problem. Python type-hints bind you to a lot of other sister projects of Python, which makes you question if they are even official addition to the language. I think that's also what the OP's article tries to convey.

Spivak 5y ago

Python type annotations in the language are nothing more then allowing you put any Python expression in the "type slot" and have it be syntatically valid. They don't do anything. All the functionality is 3rd party packages taking advantage of their existence.

nine_zeros 5y ago
My codebase is more complex than str, text, dict, int, bool. So developers are creating complex custom types with union[custom_type_1, custom_type_2] where each custom type could have more unions of other custom types. These custom types then get imported everywhere. It is utter garbage.
- Spivak 5y ago
  I don't follow. So some 3rd party library will define a type like Routes = Union[RouteSet, List[Union[str, Route]]] and this is bad? The complexity is already there, you just don't want to see it?
  - nine_zeros 5y ago
    No, my own devs will write insane nested types at the detriment of all developers who end up looking at that code later. Routes = Union[GooglyRoutes, MetaRoutes] Where, GooglyRoutes=Union[List[CloudyRoutes], Sequence[AdseyRoutes]] Where CloudyRoutes = Union[RouteContainers] And then they'd import these types all over the python repo creating all kinds of import issues. Fml.
    - Spivak 5y ago
      What’s the alternative? You have some method like def register_route(route): … That gets called with all the types in that nested union but now the type checker can’t help you if GoogleRoute and Metaroute have different attribute names or that .append isn’t a method on sequences but is on lists. Like that unwieldy nested union already exists in your code, adding the type just documents it and the type checker makes you handle all the cases. Is there something specific about imports that don’t work with type alises?
      - nine_zeros 5y ago
        In a language with a sensible typing system, I would create class Route: _route = [] # can be GoogleyRoute or MetaRoute And import Route everywhere. That import would help in creating instance objects AND be used as a type. But we can't do this with the spaghetti that python type annotations are.
- cjalmeida 5y ago
  You know you can use type aliases, right?
  - nine_zeros 5y ago
    So now you are going to create complex types and then create aliases for them? What are we even developing at this point?
    - icedchai 5y ago
      Some people love this. They spend more time screwing around with types and related tooling than writing actual working code.

cjalmeida 5y ago

As many already said, 99% is just a modern IDE with a one-click-install plugin. Also, I don't know the grip with productivity tools.

nine_zeros 5y ago
But a language relying so heavily on IDE means that the language is severely lacking. People not using said "modern" IDEs are just stuck out of using the language. Is this progress? Even with modern IDEs, there is a difference between what different IDEs do. So now the language is stuck with different IDEs doing different things. Is the progress? It also means that anyone developing a future IDE can no longer support these languages without support. Is this progress? God forbid someone tries python on a new architecture where new the entire complex toolchain is not going to be available. They just can't use this language. Is this progress?
- kortex 5y ago
  I'm pretty sure the IDE uses either mypy or pyrite under the hood. I don't know how this is a sign of python lacking. Works just fine in jupyter notebooks, too, and that is hardly an "IDE" (though it does have Jedi autocomplete).
  - nine_zeros 5y ago
    > I don't know how this is a sign of python lacking If a language cannot be written or used effectively by devs without IDE, it is an incomplete language. This has happened in the past is Java. Within a few years, Python will bloat up like Java and everyone will move on to greener pastures.
bspammer 5y ago
I think the difference is largely a culture problem. Most python devs think of typing as a “nice to have” extra, whereas someone using a typed-at-compile-time language see it as an essential feature of good code. You can see the results of this in the fact that a lot of popular 3rd party python libraries still don’t have type hints. Even with typing, how often do you see Any in python vs Object in Java?