slicing arrays

Everytime I have to make a small python tool available to my teammembers it really drives home how crazy it is because everything is realistically one of one or two types, and have to document it as such and build in a thousand little statements to make sure other people don't feed in the wrong type. What's madening is that how python does type checking changes every so often, and libraries are sometimes incosistent with how they name their types when borrowing classes from other libraries.

You just have to do it manually in Python or rely on systems like mypy to get 'static' checking.

It can be useful to rely on duck typing though if you don't want to have to re-implement or inherit from an existing base class to use a higer order function.

If the function is written in a way where all it needs is specific methods or parameters from its input objects, you can really save on interface bloat.

But if someone is used to writing statically typed code and has to deal with that it can create a lot of confusion and I always end up writing a ton of override signatures either in my code or in a .pyi sidecar so whoever is using it can still get some form of feedback that what they're doing is okay. Or at the very least putting that information in the docstring so people can read the docs as they're using the function.

Of course not, the syntax is making the type system obvious tho

static typing:

• afraid to make mistakes
• restricts your freedom
• thinks i'm too stupid to know the types of my variables
• years of programming yet no real world use found for Option<Option<Result<Int>>>

dynamic typing

• bold, fearless
• null pointer exceptions? catch them and return 0
• can use eval, easily extendable

I don't think that's equivalent. I think the former would return e0 and the latter would return [e0]