Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python Type Hints – *args and **kwargs (2021)

adamj.eu

Post reply on HN
Print view View original

51–60 of 158 posts

Re: Python Type Hints – *args and **kwargs (2021)

#51

Post by IshKebab »

masklinn wrote: post #5
assbuttbuttass wrote: post #2

This does restrict all of your keyword arguments to the same type. If you have keyword arguments of different types, you're right back to no type safety.

That seems obvious? If you want a variable number of arguments of arbitrary type you have to specify the common supertype, commonly top itself. To do otherwise would require some form of vararg generics which is uncommon.

It's extremely common for Python programmers to write code with kwargs of different types. Look at subprocess.run() for example.

Re: Python Type Hints – *args and **kwargs (2021)

#52

Post by crazydoggers »

akasakahakada wrote: post #39
icedchai wrote: post #35

Earlier quoted context omitted.

I once worked on a code base where we had *kwargs passed down 4 or 5 layers deep (not my idea.) It was a true joy.

This is literally me. It is a math program that can evaluate equations and generate code. 6 layers of heterogeneous data structure which the math operation being act on 1st layer has its effect down to 6th layer. Temporarily using *kwargs to make it works but still thinking what is the proper way to do it right.

Can you organize the data structures into classes or dataclasses?

Re: Python Type Hints – *args and **kwargs (2021)

#53

Post by c32c33429009ed6 »

akasakahakada wrote: post #39
icedchai wrote: post #35

Earlier quoted context omitted.

I once worked on a code base where we had *kwargs passed down 4 or 5 layers deep (not my idea.) It was a true joy.

This is literally me. It is a math program that can evaluate equations and generate code. 6 layers of heterogeneous data structure which the math operation being act on 1st layer has its effect down to 6th layer. Temporarily using *kwargs to make it works but still thinking what is the proper way to do it right.

Out of interest, what sort of company/industry do you work in where you're able to work on this kind of thing?

Re: Python Type Hints – *args and **kwargs (2021)

#54

Post by m3047 »

That 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(args)
        return

    class Thing(object):
        def __init__(self,a,b):
            self.a = a
            self.b = b
            return
        
        def foo_style(self):
            return (self.a, self.b)
args is not required to refer to a tuple:

    >>> foo(*[31,42])
    (31, 42)
I can have objects construct parameters conforming to the specifications for a signature:

    >>> foo(*Thing(3,91).foo_style())
    (3, 91)
Consider that a counterexample.

Re: Python Type Hints – *args and **kwargs (2021)

#55

Post by akasakahakada »

crazydoggers wrote: post #52
akasakahakada wrote: post #39

Earlier quoted context omitted.

This is literally me. It is a math program that can evaluate equations and generate code. 6 layers of heterogeneous data structure which the math operation being act on 1st layer has its effect down to 6th layer. Temporarily using *kwargs to make it works but still thinking what is the proper way to do it right.

Can you organize the data structures into classes or dataclasses?

Already doing this. The problem is there are 5 layers in between. Copy and paste the same docstring into all layers is doable but do not seem smart.

Re: Python Type Hints – *args and **kwargs (2021)

#59

Post by [deleted] »

m3047 wrote: post #54

That 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…

[deleted]

Re: Python Type Hints – *args and **kwargs (2021)

#60

Post by plonk »

zbentley wrote: post #22
refactor_master wrote: post #11

The 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.

What about decorators, or wrappers around third-party code whose contracts change frequently (or even second party code when interacting with functions provided by teams that don't follow explicit argument typing guidelines, if you have that sort of culture)?

Those are better handled by typing.ParamSpec, it should keep track of the unwrapped function's arguments.
Post reply on HN