561–570 of 597 posts
Earlier quoted context omitted.
As of Python 3.10, you can use `T | U` instead of Union. Starting from 3.8 (I think), you can also directly use dict[T, U] and list[T] rather than having to import Dict and List.
I would rather see work done on something more useful than new syntax for typing.
Earlier quoted context omitted.
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.
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?
I love statically typed languages. I also love python. But pythons "type annotation" system is garbage. It is neither here, nor there and developers spend an inordinate amount of time figuring out types.
While other languages typing is a productivity booster, pythons type annotation absolutely isn't, especially with complex types.
Earlier quoted context omitted.
The problem with these sorts of "rules" is they create needless changes outside of the PR's primary focus. The PR's purpose is to do X: add a feature, fix a bug, whatever. Now because I've done X, you want me to do Y, a set of totally unrelated changes that ultimately are a distraction.
Why wouldn’t you submit two different branches to review? One where you fix errors for types and another for the feature with the fixes: (git main) > git checkout -b abc-1234/type-fixes (git abc-1234/type-fixes) > git checkout -b abc-1234/feature-branch Then you can submit the feature branch as a PR on top of the type fixing branch and a PR for that branch to main. You only see the type fixing changes on that PR and…
Earlier quoted context omitted.
> "Quite frankly, no. My motivation for the conversation now is mostly to see how long is going to take you to realize [...]" Oh, I see. Well, I have no interest in that kind of conversation. Goodbye.
Please don't read it as snark. It was not my intention. What I am trying to say is that perhaps the lesson you could take from this it's to not think that something is "inferior" or "needs fixing" just because it doesn't immediately meet your expectations. It isn't Python's fault that you have to use at the job even though you don't like it. It isn't Python's fault that you have to use even though you are absolutely…
I think there's a lesson here, but it's for you rather than me.
This is tiring. You keep making stuff up for the sake of argument. I never claimed I didn't like Python; in fact I like it. I never claimed it was Python's fault.
I thought you were going to "wait until I realize". Go on waiting, then. Off you go!
Earlier quoted context omitted.
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?
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.
def register_route(route): …
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?
Earlier quoted context omitted.
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.
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 y…
class Route:
_route = [] # can be GoogleyRoute or MetaRoute
But we can't do this with the spaghetti that python type annotations are.
Earlier quoted context omitted.
Please don't read it as snark. It was not my intention. What I am trying to say is that perhaps the lesson you could take from this it's to not think that something is "inferior" or "needs fixing" just because it doesn't immediately meet your expectations. It isn't Python's fault that you have to use at the job even though you don't like it. It isn't Python's fault that you have to use even though you are absolutely…
> "What I am trying to say is that perhaps the lesson you could take" I think there's a lesson here, but it's for you rather than me. This is tiring. You keep making stuff up for the sake of argument. I never claimed I didn't like Python; in fact I like it. I never claimed it was Python's fault. I thought you were going to "wait until I realize". Go on waiting, then. Off you go!
Anyway, you also had the chance to respond to other questions I made, but instead you preferred to stick to defensive retorts.
This article is so hopelessly mis-informed, that it's practically hard to read without screaming "that's not how any of this works!" Most of their main arguments - type hints can be wrong, they can be ignored, and they don't inform you in a useful way about program state because of this - all evaporate as soon as you start using the correct tooling. My stack is pycharm, mypy, pydantic, sqlalchemy stub, several mypy p…
disallow_any_unimported = true
disallow_any_expr = true
disallow_any_decorated = false # true if you never plan to use Any
disallow_any_explicit = false # true if you never plan to use Any
disallow_any_generics = false # true if you never plan to use Any
disallow_subclassing_any = true
disallow_untyped_calls = true
disallow_untyped_defs = true
disallow_incomplete_defs = true
disallow_untyped_decorators = true
no_implicit_optional = true
warn_redundant_casts = true
warn_unused_ignores = true
no_warn_no_return = true
warn_return_any = true
warn_unreachable = true
strict_equality = true
strict = trueEarlier quoted context omitted.
Yeah, especially types like: List[Tuple[Tuple[str, int, str], Tuple[int, float, float]]] Oh, so I am supposed to make my own data structures now, just for typing? How about no?
Seems to me you have a Data Structure problem. What type of data is this suppose to represent and why can a Class not fix it.
It's literally a tuple containing two three-tuples inside a list.
Do a for loop over it, unpack it and you are done..