6 ms·

> The knock-on effects of type annotations seem to be doubling the complexity of the code. This is why I'm far from convinced that static type checking in Pytho

> The knock-on effects of type annotations seem to be doubling the complexity of the code. This is why I'm far from convinced that static type checking in Python is worth the cost. If adding types to your existing code cannot be done without creating new types, that’s a sign that your type-system lacks expressiveness. For instance C# 1 lacked a good and general way to describe types for functions (that is, decoupled from a class). In later C# revisions this have been greatly improved, making this pain go away, and accepting type-safe function-value parameters as easy as any other parameter. I’m guessing Python is lagging quite a bit in that regard. That doesn’t mean that type-safety (when done right) isn’t massively useful and worth the effort 200 times over.

masklinn 6y ago
I think you’re missing their point. They’re not necessarily saying types are not useful, they’re saying types encourages a form of thinking which tends towards class-based overcomplications. Now this is also a very yagni view, and maybe TFAA uses the structure they build for inspection before the final consumption, but their point that the posted script could be half the size and work the same without loss of readability… is compelling.
- foxes 6y ago
  Then types in python are not expressive enough. Other languages most of the time you don't even necessarily need to specify the types - the compiler/interpreter can figure it out and still type check the program.
  - nerdponx 6y ago
    Maybe, maybe not. Data classes are meant to feel like Scala's case classes, or Haskell's record syntax. The point is to stop passing around dicts/hashmaps/tables and tuples, and to start passing around containers with a known and fixed set of keys/names, and known types for the values/elements. I don't know of any language where the compiler automatically infers field names and types, and I don't know if I would ever want such a thing.
    - josteink 6y ago
      > I don't know of any language where the compiler automatically infers field names and types, and I don't know if I would ever want such a thing. Typescript can do this to unannotated code, and it’s surprisingly useful.
      - nerdponx 6y ago
        I've already started checking out Typescript as a general-purpose scripting language to replace Python, Ruby, Perl, and to some extent Bash/Zsh. Knowing this makes it even more attractive. The only annoyances I've had so far are: difficult-to-search docs, and the `tsc` command-line compiler is slow.
  - dragonwriter 6y ago
    Even in languages where this is possible, it's usually idiomatic to explicitly type the public interface including exposed fields, and often it's common to explicitly type them narrower than the inferred type to avoid implementation details leaking into an unintentionally broad backward compatibility contract restricting future evolution.
- nerdponx 6y ago
  The sentiment in Python has been trending toward using "classes" (either with dataclass or attrs [1]) as essentially namespaced logicless containers, and away from dicts (or TypedDicts [2]) and namedtuples/NamedTuples [3]) for that purpose. This is very different from the useless "you don't need classes" classes. Think of classes nowadays serving as being both traditional OO classes and Scala case classes: they can be types of stateful objects, or just dumb record types, which you now can easily extend with logic if you do happen to need it (and you often do, in nontrivial applications). Now this is also a very yagni view, and maybe TFAA uses the structure they build for inspection before the final consumption, but their point that the posted script could be half the size and work the same without loss of readability… is compelling. I find this "it would be half as long and work the same" argument totally bizarre. Do you look at a basic Rust program and say "it would be half as messy and look the same if we did away with all the move/borrow stuff"? Of course not. Yes, YAGNI is fine and all, but at least recognize that there is an upside to this tradeoff. I am not going to need internal state on the object, but I sure as hell am going to want the type checking. And yes, you could (perhaps should) use Typescript or Kotlin for new web server projects instead. But some people want Python with types, including me. I wouldn't accuse Python of being "concise" in the first place, so I am happy to add some up-front verbosity in exchange for a much smoother developer experience later in my project, with significantly less mental overhead as my IDE can do a lot of work for me. 1: https://www.attrs.org/en/stable/ https://www.attrs.org/en/stable/ 2: https://docs.python.org/3/library/typing.html#typing.TypedDict https://docs.python.org/3/library/typing.html#typing.TypedDi... 3: https://docs.python.org/3/library/collections.html#collections.namedtuple https://docs.python.org/3/library/collections.html#collectio... and https://docs.python.org/3/library/typing.html#typing.NamedTuple https://docs.python.org/3/library/typing.html#typing.NamedTu...
  - masklinn 6y ago
    > The sentiment in Python has been trending toward using "classes" (either with dataclass or attrs [1]) That is not even remotely what is being done here. And just because you can do it doesn't mean you should or must do it. Not every argument needs to be bundled in its own object. > I find this "it would be half as long and work the same" argument totally bizarre. Do you look at a basic Rust program and say "it would be half as messy and look the same if we did away with all the move/borrow stuff"? Again, missing the point. The point was not about the typechecking but the design perspective it engenders and encourages. > Of course not. Yes, YAGNI is fine and all, but at least recognize that there is an upside to this tradeoff. Why would I? There is none in the article's snippet. > I am not going to need internal state on the object, but I sure as hell am going to want the type checking. Type checking doesn't require classes. You can typecheck a funtion. > I wouldn't accuse Python of being "concise" in the first place, so I am happy to add some up-front verbosity in exchange for a much smoother developer experience later in my project, with significantly less mental overhead as my IDE can do a lot of work for me. You're still missing the point entirely, but I hope you're happy about all those strawmen you beat down.
- sportsracer 6y ago
  Typing in Python is, at times, at odds with the language. Said another way, patterns which were once Pythonic are now discouraged by the type system (or, mypy I suppose, since the door is still open for other type checkers to emerge). Examples: - Duck typing. I was taught that's Pythonic, yet mypy really only accepts nominal subtyping i.e. it infers type compatibility from the type hierarchy. There is typing.Protocol, but I've never encountered that in code. Ruby's new type annotation language RBS introduces interfaces, so maybe it'll stay true to its duck typing roots. - Lists with mixed types. I might as well bookmark this page, because this behavior of mypy always surprises me: https://mypy.readthedocs.io/en/stable/common_issues.html#invariance-vs-covariance https://mypy.readthedocs.io/en/stable/common_issues.html#inv... In both cases, mypy reminds me way more of Java's type system than of Python's, which is maybe why heavily typed Python code often ends up looking like Java.
  - dragonwriter 6y ago
    > Said another way, patterns which were once Pythonic are now discouraged by the type system (or, mypy I suppose, since the door is still open for other type checkers to emerge). There are several typecheckers, and while they are at slightly different points, they evolving together and together with the core typing library. > Duck typing. I was taught that's Pythonic, yet mypy really only accepts nominal subtyping i.e. it infers type compatibility from the type hierarchy. There is typing.Protocol Which entirely undercuts “mypy only accepts...” > but I've never encountered that in code. That's a library author issue, not a mypy (or typing, the standard library) issue. > In both cases, mypy reminds me way more of Java's type system than of Python's Python’s type system has always supported both nominal and structural subtyping. > heavily typed Python code often ends up looking like Java. That's probably because Java (and languages with closely related type systems) are the typed languages most people writing typed Python have prior experience with, so it's where their typing instincts go.

masklinn 6y ago

I think you’re missing their point. They’re not necessarily saying types are not useful, they’re saying types encourages a form of thinking which tends towards class-based overcomplications. Now this is also a very yagni view, and maybe TFAA uses the structure they build for inspection before the final consumption, but their point that the posted script could be half the size and work the same without loss of readability… is compelling.

foxes 6y ago
Then types in python are not expressive enough. Other languages most of the time you don't even necessarily need to specify the types - the compiler/interpreter can figure it out and still type check the program.
- nerdponx 6y ago
  Maybe, maybe not. Data classes are meant to feel like Scala's case classes, or Haskell's record syntax. The point is to stop passing around dicts/hashmaps/tables and tuples, and to start passing around containers with a known and fixed set of keys/names, and known types for the values/elements. I don't know of any language where the compiler automatically infers field names and types, and I don't know if I would ever want such a thing.
  - josteink 6y ago
    > I don't know of any language where the compiler automatically infers field names and types, and I don't know if I would ever want such a thing. Typescript can do this to unannotated code, and it’s surprisingly useful.
    - nerdponx 6y ago
      I've already started checking out Typescript as a general-purpose scripting language to replace Python, Ruby, Perl, and to some extent Bash/Zsh. Knowing this makes it even more attractive. The only annoyances I've had so far are: difficult-to-search docs, and the `tsc` command-line compiler is slow.
- dragonwriter 6y ago
  Even in languages where this is possible, it's usually idiomatic to explicitly type the public interface including exposed fields, and often it's common to explicitly type them narrower than the inferred type to avoid implementation details leaking into an unintentionally broad backward compatibility contract restricting future evolution.
nerdponx 6y ago
The sentiment in Python has been trending toward using "classes" (either with dataclass or attrs [1]) as essentially namespaced logicless containers, and away from dicts (or TypedDicts [2]) and namedtuples/NamedTuples [3]) for that purpose. This is very different from the useless "you don't need classes" classes. Think of classes nowadays serving as being both traditional OO classes and Scala case classes: they can be types of stateful objects, or just dumb record types, which you now can easily extend with logic if you do happen to need it (and you often do, in nontrivial applications). Now this is also a very yagni view, and maybe TFAA uses the structure they build for inspection before the final consumption, but their point that the posted script could be half the size and work the same without loss of readability… is compelling. I find this "it would be half as long and work the same" argument totally bizarre. Do you look at a basic Rust program and say "it would be half as messy and look the same if we did away with all the move/borrow stuff"? Of course not. Yes, YAGNI is fine and all, but at least recognize that there is an upside to this tradeoff. I am not going to need internal state on the object, but I sure as hell am going to want the type checking. And yes, you could (perhaps should) use Typescript or Kotlin for new web server projects instead. But some people want Python with types, including me. I wouldn't accuse Python of being "concise" in the first place, so I am happy to add some up-front verbosity in exchange for a much smoother developer experience later in my project, with significantly less mental overhead as my IDE can do a lot of work for me. 1: https://www.attrs.org/en/stable/ https://www.attrs.org/en/stable/ 2: https://docs.python.org/3/library/typing.html#typing.TypedDict https://docs.python.org/3/library/typing.html#typing.TypedDi... 3: https://docs.python.org/3/library/collections.html#collections.namedtuple https://docs.python.org/3/library/collections.html#collectio... and https://docs.python.org/3/library/typing.html#typing.NamedTuple https://docs.python.org/3/library/typing.html#typing.NamedTu...
- masklinn 6y ago
  > The sentiment in Python has been trending toward using "classes" (either with dataclass or attrs [1]) That is not even remotely what is being done here. And just because you can do it doesn't mean you should or must do it. Not every argument needs to be bundled in its own object. > I find this "it would be half as long and work the same" argument totally bizarre. Do you look at a basic Rust program and say "it would be half as messy and look the same if we did away with all the move/borrow stuff"? Again, missing the point. The point was not about the typechecking but the design perspective it engenders and encourages. > Of course not. Yes, YAGNI is fine and all, but at least recognize that there is an upside to this tradeoff. Why would I? There is none in the article's snippet. > I am not going to need internal state on the object, but I sure as hell am going to want the type checking. Type checking doesn't require classes. You can typecheck a funtion. > I wouldn't accuse Python of being "concise" in the first place, so I am happy to add some up-front verbosity in exchange for a much smoother developer experience later in my project, with significantly less mental overhead as my IDE can do a lot of work for me. You're still missing the point entirely, but I hope you're happy about all those strawmen you beat down.
sportsracer 6y ago
Typing in Python is, at times, at odds with the language. Said another way, patterns which were once Pythonic are now discouraged by the type system (or, mypy I suppose, since the door is still open for other type checkers to emerge). Examples: - Duck typing. I was taught that's Pythonic, yet mypy really only accepts nominal subtyping i.e. it infers type compatibility from the type hierarchy. There is typing.Protocol, but I've never encountered that in code. Ruby's new type annotation language RBS introduces interfaces, so maybe it'll stay true to its duck typing roots. - Lists with mixed types. I might as well bookmark this page, because this behavior of mypy always surprises me: https://mypy.readthedocs.io/en/stable/common_issues.html#invariance-vs-covariance https://mypy.readthedocs.io/en/stable/common_issues.html#inv... In both cases, mypy reminds me way more of Java's type system than of Python's, which is maybe why heavily typed Python code often ends up looking like Java.
- dragonwriter 6y ago
  > Said another way, patterns which were once Pythonic are now discouraged by the type system (or, mypy I suppose, since the door is still open for other type checkers to emerge). There are several typecheckers, and while they are at slightly different points, they evolving together and together with the core typing library. > Duck typing. I was taught that's Pythonic, yet mypy really only accepts nominal subtyping i.e. it infers type compatibility from the type hierarchy. There is typing.Protocol Which entirely undercuts “mypy only accepts...” > but I've never encountered that in code. That's a library author issue, not a mypy (or typing, the standard library) issue. > In both cases, mypy reminds me way more of Java's type system than of Python's Python’s type system has always supported both nominal and structural subtyping. > heavily typed Python code often ends up looking like Java. That's probably because Java (and languages with closely related type systems) are the typed languages most people writing typed Python have prior experience with, so it's where their typing instincts go.