6 ms·

This has to be a troll comment. The overhead of typing is literally _nothing_ compared to the amount of time it takes to sift through code to figure out a) wha

This has to be a troll comment. The overhead of typing is literally _nothing_ compared to the amount of time it takes to sift through code to figure out a) what types a function/class accepts as arguments and b) what types are returned. If you don't check it then I agree it's useless. However, working with libraries that are typed is an _insane_ productivity boost over working with untyped libraries.

ReflectedImage 5y ago
Typing in Python is generally a code smell. Typing encourages a large number of bad coding practices. If you can apply typing to a Python program then you are not taking advantage of the dynamic nature of the language to write simpler and shorter code. In Python world, unit tests cover what is normally handled by typing.
- kortex 5y ago
  What. > Typing encourages a large number of bad coding practices. I'm sorry, what? What exactly is the bad practice here? Not passing random dicts to my coworkers only to surprise them because the key was userid and not user_id? Or wasting time bugging an overworked dev to ask what their crazy 8 levels of dynamic indirection magic are doing, vs just being able to Cmd-B and step through the code path? > If you can apply typing to a Python program then you are not taking advantage of the dynamic nature of the language to write simpler and shorter code. Yeah, no, flat out wrong. You can use typing with dynamicism to do magical things. FastApi works a near miracle, generating serializers, deserializers, openapi docs, automatic api deprecation warnings, not to mention type safety. Properly typed python is faster to write and safely magical.
  - ReflectedImage 5y ago
    The bad practice is treating a dynamically typed language as if it was a statically typed language. There are shorter more concise ways to write your programs if you are not using static typing. If you are not writing your Python programs in the Pythonic way then you are not really using Python correctly and you do not get most of the benefits of the language. Unit tests exist for catching bugs in Python. Type hints are for documentation not for ensuring code correctness. Yes, there are libraries that take advantage of type hints, through they could of used other annonations and it's valid to use type hints along with those libraries. But as soon as you are attempting to prove your program doesn't have bugs via typing rather than unit testing. You have gone wrong. Typed Python is far more bug prone, why? Because structuring your Python code to support typing means writing considerably more lines of code. It not the type hints themselves but it's the way you will structure your program at a high level to support them. The more lines of code the more bugs it has. Bugs are well known to be proportion to the number of lines of source code regardless of language used or whether the language is typed or not.
    - kortex 5y ago
      > Typed Python is far more bug prone, why? Because structuring your Python code to support typing means writing considerably more lines of code. That does not bear out in practice. In my experience, bugs have almost nothing to do with LoC. A short bit of complex, I/O heavy code with lots of state is going to be way more bug prone, and far harder to unit test correctly, than 10x the LoC of purely functional, well-typed, stateless code. Mutation, parallelism, IO, and complex state space are the four horsemen of the bugpocalypse. But in fact, I find functional, well-typed, properly abstracted code ends up with less LoC in the codebase, because it's more reusable and composes well.
nine_zeros 5y ago
This is a snippet from the python codebase, written by a type nazi SessionInfoType = Union[AuthzQuerySessionInfo, AuthnReqSessionInfo] Notice how it is doing a union of two objects. Do you know what those 2 objects are? Those are types as well. They have no business use case. AuthzQuerySessionInfo = TypedDict( "AuthzQuerySessionInfo", {"name_id": Any, "came_from": Any, "issuer": Any, "not_on_or_after": Any, "authz_decision_info": Any,}, total=False, ) AuthnReqSessionInfo = TypedDict( "AuthnReqSessionInfo", { "ava": Union[dict, None], "name_id": Any, "came_from": Any, "issuer": Text, "not_on_or_after": Union[int, bool], "authn_info": list, "session_index": Any, }, total=False, ) RequestCookieType = TypedDict( "RequestCookieType", { "request_id": Text, "came_from": Optional[Text], "public_id": Text, "is_mobile": Union[Literal[True], Text], "c_challenge": Text, "c_challenge_method": Text, }, total=False, ) So now. not only do we have dicts that represent above data, we also have TypedDicts created specially for types. To rub salt on the wound, the callsite with these types now looks like session_info = authresp.session_info() session_info = cast(SessionInfoType, session_info) WTF!! If we have to see a codebase littered with TypedDicts just to satisfy type annotations and then have to cast everything to that type - why not just wrap it in a class and call it a day? When I see garbage like this, I seriously question the productivity improvement brought about by python type annotations. I certainly end up spending an inordinate amount of time unraveling nested unions of types all over now. Considering switching to a team that uses Golang.
- noitpmeder 5y ago
  No amount of typing will save you from bad code.

ReflectedImage 5y ago

Typing in Python is generally a code smell. Typing encourages a large number of bad coding practices. If you can apply typing to a Python program then you are not taking advantage of the dynamic nature of the language to write simpler and shorter code. In Python world, unit tests cover what is normally handled by typing.

kortex 5y ago
What. > Typing encourages a large number of bad coding practices. I'm sorry, what? What exactly is the bad practice here? Not passing random dicts to my coworkers only to surprise them because the key was userid and not user_id? Or wasting time bugging an overworked dev to ask what their crazy 8 levels of dynamic indirection magic are doing, vs just being able to Cmd-B and step through the code path? > If you can apply typing to a Python program then you are not taking advantage of the dynamic nature of the language to write simpler and shorter code. Yeah, no, flat out wrong. You can use typing with dynamicism to do magical things. FastApi works a near miracle, generating serializers, deserializers, openapi docs, automatic api deprecation warnings, not to mention type safety. Properly typed python is faster to write and safely magical.
- ReflectedImage 5y ago
  The bad practice is treating a dynamically typed language as if it was a statically typed language. There are shorter more concise ways to write your programs if you are not using static typing. If you are not writing your Python programs in the Pythonic way then you are not really using Python correctly and you do not get most of the benefits of the language. Unit tests exist for catching bugs in Python. Type hints are for documentation not for ensuring code correctness. Yes, there are libraries that take advantage of type hints, through they could of used other annonations and it's valid to use type hints along with those libraries. But as soon as you are attempting to prove your program doesn't have bugs via typing rather than unit testing. You have gone wrong. Typed Python is far more bug prone, why? Because structuring your Python code to support typing means writing considerably more lines of code. It not the type hints themselves but it's the way you will structure your program at a high level to support them. The more lines of code the more bugs it has. Bugs are well known to be proportion to the number of lines of source code regardless of language used or whether the language is typed or not.
  - kortex 5y ago
    > Typed Python is far more bug prone, why? Because structuring your Python code to support typing means writing considerably more lines of code. That does not bear out in practice. In my experience, bugs have almost nothing to do with LoC. A short bit of complex, I/O heavy code with lots of state is going to be way more bug prone, and far harder to unit test correctly, than 10x the LoC of purely functional, well-typed, stateless code. Mutation, parallelism, IO, and complex state space are the four horsemen of the bugpocalypse. But in fact, I find functional, well-typed, properly abstracted code ends up with less LoC in the codebase, because it's more reusable and composes well.

nine_zeros 5y ago

This is a snippet from the python codebase, written by a type nazi SessionInfoType = Union[AuthzQuerySessionInfo, AuthnReqSessionInfo] Notice how it is doing a union of two objects. Do you know what those 2 objects are? Those are types as well. They have no business use case. AuthzQuerySessionInfo = TypedDict( "AuthzQuerySessionInfo", {"name_id": Any, "came_from": Any, "issuer": Any, "not_on_or_after": Any, "authz_decision_info": Any,}, total=False, ) AuthnReqSessionInfo = TypedDict( "AuthnReqSessionInfo", { "ava": Union[dict, None], "name_id": Any, "came_from": Any, "issuer": Text, "not_on_or_after": Union[int, bool], "authn_info": list, "session_index": Any, }, total=False, ) RequestCookieType = TypedDict( "RequestCookieType", { "request_id": Text, "came_from": Optional[Text], "public_id": Text, "is_mobile": Union[Literal[True], Text], "c_challenge": Text, "c_challenge_method": Text, }, total=False, ) So now. not only do we have dicts that represent above data, we also have TypedDicts created specially for types. To rub salt on the wound, the callsite with these types now looks like session_info = authresp.session_info() session_info = cast(SessionInfoType, session_info) WTF!! If we have to see a codebase littered with TypedDicts just to satisfy type annotations and then have to cast everything to that type - why not just wrap it in a class and call it a day? When I see garbage like this, I seriously question the productivity improvement brought about by python type annotations. I certainly end up spending an inordinate amount of time unraveling nested unions of types all over now. Considering switching to a team that uses Golang.

noitpmeder 5y ago
No amount of typing will save you from bad code.