4 ms·

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 eac

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.

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.