Is it just me or are Python type hints like..goofy?
I agree. It adds all the inconvenience of static typing with none of the benefits.
Python Type Hints – *args and **kwargs (2021)
91–100 of 158 posts
Re: Python Type Hints – *args and **kwargs (2021)
#92> In the function body, args will be a tuple, and kwargs a dict with string keys. This always bugs me: why is `args` immutable (tuple) but `kwargs` mutable (dict)? In my experience it’s much more common to have to extend or modify `kwargs` rather than `args`, but I would find more natural having an immutable dict for `kwargs`.
> This always bugs me: why is `args` immutable (tuple) but `kwargs` mutable (dict)?
Because python didn’t (still doesn’t, but at this point even if it did backward compatibility would mean it wouldn’t be used for this purpose) have a basic immutable mapping type to use.
(Note, yes, MappingProxyType exists, but that’s a proxy without mutation operations, not a basic type, so it costs a level of indirection.)
Re: Python Type Hints – *args and **kwargs (2021)
#93For typing **kwargs there are TypedDicts https://peps.python.org/pep-0692/ If your function just wraps another you can use the same type hints as the other function with functools.wraps https://docs.python.org/3/library/functools.html#functools.w...
I think pep 612 is trying to make the ergonomics better for the 'forwarding' / pass-through case (when .wraps isn't appropriate)
Re: Python Type Hints – *args and **kwargs (2021)
#94Earlier quoted context omitted.
I'm not sure print(firstname, lastname) for example is more readable than print((firstname, lastname)) especially since I would then have to write print((surname,)) to just print a single string. Variadic functions are rather classic, I think Go, Rust, C and JavaScript also have them.
Your example has a fixed number of names. What if you wanted to accept any number of names, like Pablo Diego José Francisco de Paula Juan Nepomuceno María de los Remedios Cipriano de la Santísima Trinidad Ruiz y Picasso ? Really, though, Iterables make more sense for monadic types.
We would force broad changes in human society to conform to the assumptions of our database scheme, same as we always have.
Re: Python Type Hints – *args and **kwargs (2021)
#95now try typing a decorator https://stackoverflow.com/questions/47060133/python-3-type-h... what a disaster
PEP 612 made this much better FWIW.
Re: Python Type Hints – *args and **kwargs (2021)
#96What if the second argument is a float?
Re: Python Type Hints – *args and **kwargs (2021)
#97The ability of **kwargs to leave behind no proper documentation and silently swallow any invalid arguments has made us remove them entirely from our codebase. They're almost entirely redundant when you have dataclasses.
They are a necessity for subclasses though, especially when subclassing from an external library that will likely change underneath you.
Re: Python Type Hints – *args and **kwargs (2021)
#98Earlier quoted context omitted.
What do you do when inheriting from a base class with a defined __init__ ?
For everybody reading this and scratching their head why this is relevant: Python subclassing is strange. Essentially super().__init__() will resolve to a statically unknowable class at run-time because super() refers to the next class in the MRO. Knowing what class you will call is essentially unknowable as soon as you accept that either your provider class hierarchy may change or you have consumers you do not contr…
> So the easiest way to solve this is: Declare everything you need as keyword argument, but then only give *kwargs in your function signature to allow your __init__() to handle any set of arguments your children or siblings may throw at you. Then remove all of "your" arguments via kwargs.pop('argname') before calling super().__init__() in case your parent or uncle does not use this kwargs trick and would complain about unknown arguments. Only then pass on the cleaned kwargs to your MRO foster parent.
The easiest way is to not put your arguments into kwargs in the first place. If you put them as regular function arguments (probably give them a default value so they look like they're related to kwargs), then the python runtime separates them from the rest when it generates kwargs and you don't have to do the ".pop()" part at all.
Re: Python Type Hints – *args and **kwargs (2021)
#99Earlier quoted context omitted.
As someone who has written Python for nearly 20 years now, and also has plenty of experience with strongly and statically typed languages (including a fair bit of Haskell), I think type hints in Python should at most remain just that, hints . A language being statically typed or dynamically typed is a design decision with implications for what the language can do. There are benefits to each method of programming. Try…
Have to disagree with this. Choosing a language is not just about its features but also its ecosystem. I chose Python for my current project because it has great libraries that don't exist in other languages.
"my current project" type problems are where Python is great. Types remain "nice to have" (if you like them) and aren't really essential compared to the ease of prototyping new ideas and building a PoC. You're choosing Python because the benefit of libraries outweighs your personal preference for types.
Most of my work is in machine learning/numeric computing, so I'm very familiar with the benefits of Python's ecosystem. Basically all of AI/ML work is about prototyping ideas rapidly, where access to libraries and iterating fast greatly trumps the need for type safety.
At nearly every place I've worked, Python is the tool for building models quickly but shipping them to production and integrating them with the core product almost always involves another language, typically with types, better suited for large engineering teams working on a large code base where you really want some sort of type checking in place. Most of the companies I know that do serious ML in production typically take models from python and then implement them in either C++ or Scala for the actual production serving.
It's worth pointing out that the vast majority of those libraries you use were initially developed without any consideration, or need, for types. Great, reliable, software can be written without types. Dynamic typing is a great language choice, and there's no need to fight the language itself by trying to bolt types on.
Where types are important is where you have a complex, rapidly changing code base with a large number of developers of differing skill levels releasing frequently. If that's the environment you're in, I would strongly recommend against using Python in prod, even if it means you have to implement the features of some libraries internally.
Re: Python Type Hints – *args and **kwargs (2021)
#100For typing **kwargs there are TypedDicts https://peps.python.org/pep-0692/ If your function just wraps another you can use the same type hints as the other function with functools.wraps https://docs.python.org/3/library/functools.html#functools.w...
There is also typing.ParamSpec when the purpose is to write a generic wrapper:
https://docs.python.org/3/library/typing.html#typing.ParamSp...