3 ms·

> The new type system goes pretty much against the idea of duck typing How so? Python’s Protocol and TypedDict have their limitations but are structurally type

> The new type system goes pretty much against the idea of duck typing How so? Python’s Protocol and TypedDict have their limitations but are structurally typed. > `a: int = "foo"` goes through the python interpreter without even a warning As long as you’re validating inputs then you don’t need type validation at runtime. Input validation ensures that static types are representative of runtime types

grumbel 4y ago
Once you start adding Protocol and TypedDict you are (almost) back where C++ and Java are with virtual classes and interfaces. The point of duck typing was that you don't have to write all that boilerplate and stuff just works as long as the right functions are there. That's lost once you have to declare what you want to use. > As long as you’re validating inputs then you don’t need type validation at runtime. The issue is that type validation is done by a different tool, that follow similar, but not identical rules to the runtime. So it's very easy to create code that passes the type checker, but fails at runtime or vice versa. Type validation is something Python should be able to do itself, it's part of the language after all.
- kortex 4y ago
  > The point of duck typing was that you don't have to write all that boilerplate and stuff just works as long as the right functions are there. As long as your definition of "just works" is "run, crash, fix something, run, repeat". I remember the pre-type-annotation days, and still live it with some libraries. I find it quite unpleasant, but hey I guess some folks like the "freedom". > So it's very easy to create code that passes the type checker, but fails at runtime or vice versa. In theory, yes, in practice, not as much as you might think. If you actually use mypy with strict, which is actually really hard to do, you will find very, very few surprises.
- goodoldneon 4y ago
  I'd heavily argue against "stuff just works". Without type annotations it's this wild west where stuff fails in prod because you don't have tests that cover every possible code path. With static type analysis, you're able get automatic test coverage for a huge swath of your codebase. I can't count the number of times I've seen None-related errors in prod because some function deep in the business logic can't handle a None parameter. Another huge benefit of type annotations is that it adds friction for clever code. As I've retroactively added type annotations to old code, I've discovered wild polymorphism. Some functions required upwards of 10 type signature overloads to account for all the polymorphism -- engineers have to remember all that polymorphism! Engineers won't write extremely polymorphic functions if they also have to write the convoluted overloads.

grumbel 4y ago

Once you start adding Protocol and TypedDict you are (almost) back where C++ and Java are with virtual classes and interfaces. The point of duck typing was that you don't have to write all that boilerplate and stuff just works as long as the right functions are there. That's lost once you have to declare what you want to use. > As long as you’re validating inputs then you don’t need type validation at runtime. The issue is that type validation is done by a different tool, that follow similar, but not identical rules to the runtime. So it's very easy to create code that passes the type checker, but fails at runtime or vice versa. Type validation is something Python should be able to do itself, it's part of the language after all.

kortex 4y ago
> The point of duck typing was that you don't have to write all that boilerplate and stuff just works as long as the right functions are there. As long as your definition of "just works" is "run, crash, fix something, run, repeat". I remember the pre-type-annotation days, and still live it with some libraries. I find it quite unpleasant, but hey I guess some folks like the "freedom". > So it's very easy to create code that passes the type checker, but fails at runtime or vice versa. In theory, yes, in practice, not as much as you might think. If you actually use mypy with strict, which is actually really hard to do, you will find very, very few surprises.
goodoldneon 4y ago
I'd heavily argue against "stuff just works". Without type annotations it's this wild west where stuff fails in prod because you don't have tests that cover every possible code path. With static type analysis, you're able get automatic test coverage for a huge swath of your codebase. I can't count the number of times I've seen None-related errors in prod because some function deep in the business logic can't handle a None parameter. Another huge benefit of type annotations is that it adds friction for clever code. As I've retroactively added type annotations to old code, I've discovered wild polymorphism. Some functions required upwards of 10 type signature overloads to account for all the polymorphism -- engineers have to remember all that polymorphism! Engineers won't write extremely polymorphic functions if they also have to write the convoluted overloads.