I remain baffled as to how the javascript-heavy modern web actually functions as well as it does, with all that dynamic insanity. Typescript isn’t a miracle cure.
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.
It’s funny how Python spent the past like 6 years developing the type hinting system (which is a massive improvement from no typing don’t get me wrong) only to start re-introducing duck typing again with the Protocols.
The one thing I’ll always love about it is the ability to override builtins and do dumb things like call ‘sum(cats)’ where cats is a list of cat objects and have it like print out meow to the terminal for each cat in the list.
Shit like that makes it perfect for internal tools.
Even better is to create a decorator and just wrap the offending functions:
defshut_up(func):
defcall(*args, **kwargs):
try:
return func(*args, **kwargs)
except Exception as e:
print(f"shit's fucked, but I'll be quiet about it")
returnreturn call
@shut_updefadd(x: int, y: int):
print(x + y)
add(1, 2)
add(-1, 2)
add(1, "2")
>>> 3>>> 1>>> "shit's fucked, but I'll be quiet about it"
Or if you want to attempt to salvage it:
defshut_up(func):
defcall(*args, **kwargs):
try:
return func(*args, **kwargs)
except Exception as e:
try:
return func(*map(int, args), **kwargs)
except Exception as e:
print(f"shit's really fucked, I even tried to fix it for you")
returnNonereturn call
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.
I like static typing more
I remain baffled as to how the javascript-heavy modern web actually functions as well as it does, with all that dynamic insanity. Typescript isn’t a miracle cure.
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.
It’s funny how Python spent the past like 6 years developing the type hinting system (which is a massive improvement from no typing don’t get me wrong) only to start re-introducing duck typing again with the Protocols.
The one thing I’ll always love about it is the ability to override builtins and do dumb things like call ‘sum(cats)’ where cats is a list of cat objects and have it like print out meow to the terminal for each cat in the list.
Shit like that makes it perfect for internal tools.
At some point I’m just gonna give up and do
Try:
Entire fucking program
Except:
Print(“error: something went wrong”)
Even better is to create a decorator and just wrap the offending functions:
def shut_up(func): def call(*args, **kwargs): try: return func(*args, **kwargs) except Exception as e: print(f"shit's fucked, but I'll be quiet about it") return return call @shut_up def add(x: int, y: int): print(x + y) add(1, 2) add(-1, 2) add(1, "2") >>> 3 >>> 1 >>> "shit's fucked, but I'll be quiet about it"Or if you want to attempt to salvage it:
def shut_up(func): def call(*args, **kwargs): try: return func(*args, **kwargs) except Exception as e: try: return func(*map(int, args), **kwargs) except Exception as e: print(f"shit's really fucked, I even tried to fix it for you") return None return callThose are in no way incompatible.
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 is for wusses who can’t handle dynamic, go-getter variables
static typing:
dynamic typing
I don’t like static typing, it hurts my fingers, and I’m always worried it’ll fry my motherboard.