Is it just me or are Python type hints like..goofy?
They're quite limited in some ways, obscenely powerful in others, and have a fairly strange syntax, yeah.
Python Type Hints – *args and **kwargs (2021)
81–90 of 158 posts
Re: Python Type Hints – *args and **kwargs (2021)
#82Earlier 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.
FWIW Rust does not have variadic functions. The closest thing would be either macros, which are variadic, or trait methods, which are not variadic but can look like they are.
Oh yeah, that’s right! Thanks for the correction
Re: Python Type Hints – *args and **kwargs (2021)
#83Is it just me or are Python type hints like..goofy?
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.
Re: Python Type Hints – *args and **kwargs (2021)
#84That article promulgates a misunderstanding about immutability. For my way of thinking, python is already an interpreted language and I can enforce tropes in code more cleanly and effectively than people taking something five levels up at face value and trying to figure out what sticks when they throw it against the wall: no wonder they end up frustrated, and it's a frustrating situation. Given: def foo(*args): print…
Within the function, args is a tuple, as your output demonstrates.
Re: Python Type Hints – *args and **kwargs (2021)
#85> 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`.
Yeah, that is odd. Python still has no immutable dict type, except it kinda does: https://adamj.eu/tech/2022/01/05/how-to-make-immutable-dict-...
Re: Python Type Hints – *args and **kwargs (2021)
#86Earlier quoted context omitted.
You should use `Iterable`
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.
How is it more "readable"? The two are just as readable.
What do you do with your first example if you have a list (generated at runtime, not a static one) to pass to the function? This wouldn't work (imagine the first line is more complicated):
l = (1,2,3)
print(l)Re: Python Type Hints – *args and **kwargs (2021)
#87Earlier 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…
Having used Python a lot, I was never glad for multiple inheritance. I’d prefer traits.
Re: Python Type Hints – *args and **kwargs (2021)
#88The 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.
Yea, really only useful imho for proxy functions that then just pass the arguments along to something that DOES properly type every arg.
But doesn't this break type checking for the users of the proxy functions?
Re: Python Type Hints – *args and **kwargs (2021)
#89Earlier 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…
This is why I hate Python, absolutely none of this is obvious from the design of the language
Re: Python Type Hints – *args and **kwargs (2021)
#90Earlier quoted context omitted.
Yea, really only useful imho for proxy functions that then just pass the arguments along to something that DOES properly type every arg.
But doesn't this break type checking for the users of the proxy functions?
You can write the proxy/decorator to preserve typing info using a typevar.
F = TypeVar(“F”, bound=Callable)
def wrapper(f: F) -> F: …