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

41–50 of 158 posts

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

#41

Post by macintux »

hk__2 wrote: post #33
zoomablemind wrote: post #30

Earlier quoted context omitted.

It seems altogether surprising that with an empty list or tuple a, a[1] results in index error, yet a[1:] quietly returns an empty list or tuple.

> It seems altogether surprising that with an empty list or tuple a, a[1] results in index error, yet a[1:] quietly returns an empty list or tuple. `a[1:]` returns the sequence of elements that start at index 1. If there is no such element, the list is empty. I don’t see any good reason why this should throw an error.

Then why doesn’t a[1] return None?

I understand the logic behind both decisions, but it’s not surprising that people find it inconsistent and unintuitive.

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

#42

Post by tomn »

akasakahakada wrote: post #8

Although these two comes in handly, people have been using them wrong. Often in scientific open source package, they slap *kwargs in function definition without documentation. How am I suppose to know what to pass in? https://qiskit.org/ecosystem/aer/stubs/qiskit_aer.primitives...

OT, but this is my number one peeve with code documentation: going to the effort to write a doc comment, taking up at least 6 lines, probably using some special syntax, cluttering up the code, but then adding no information that can't be derived from the signature.

If you're not going to document something (which I totally respect), at least don't make the code worse while doing it.

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

#44

Post by hk__2 »

macintux wrote: post #41
hk__2 wrote: post #33

Earlier quoted context omitted.

> It seems altogether surprising that with an empty list or tuple a, a[1] results in index error, yet a[1:] quietly returns an empty list or tuple. `a[1:]` returns the sequence of elements that start at index 1. If there is no such element, the list is empty. I don’t see any good reason why this should throw an error.

Then why doesn’t a[1] return None? I understand the logic behind both decisions, but it’s not surprising that people find it inconsistent and unintuitive.

> Then why doesn’t a[1] return None?

Because there would be no way to distinguish between "a[1] contains None" and "a[1]" doesn’t exist.

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

#45

Post by js2 »

zoomablemind wrote: post #30
Znafon wrote: post #7

Earlier quoted context omitted.

It is used when the number of argument can vary, like: def sum(*args: int) -> int: if len(args) == 0: return 0 return args[0] + sum(*args[1:])

It seems altogether surprising that with an empty list or tuple a, a[1] results in index error, yet a[1:] quietly returns an empty list or tuple.

a[1] has to raise an IndexError because there's no return value it could use to otherwise communicate the item doesn't exist. Any such value could itself be a member of the sequence. To behave otherwise, Python would have to define a sentinel value that isn't allowed to be a member of a sequence.

When using slice notation, the return value is a sequence, so returning a zero-length sequence is sufficient to communicate you asked for more items than exist.

It may be surprising, but it almost always leads to more ergonomic code.

https://discuss.python.org/t/why-isnt-slicing-out-of-range/

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

#46

Post by jpc0 »

vorticalbox wrote: post #4

Why do people not just type everything they want passed? def variable(n:str, nn:str, nnn:str, *, a:int, b:int, c:int) Anything after,*, is a kwarg.

If you have enough arguments that the signature becomes obscure to read you need a dataclass to pass into the function instead.

I would rather:

    @dataclass(frozen=True, slots=True)   
    class VarThings:   
        n: int   
        ...

    def variable(a: VarThings):   
        ...
Than a million args

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

#48

Post by Znafon »

macintux wrote: post #41
hk__2 wrote: post #33

Earlier quoted context omitted.

> It seems altogether surprising that with an empty list or tuple a, a[1] results in index error, yet a[1:] quietly returns an empty list or tuple. `a[1:]` returns the sequence of elements that start at index 1. If there is no such element, the list is empty. I don’t see any good reason why this should throw an error.

Then why doesn’t a[1] return None? I understand the logic behind both decisions, but it’s not surprising that people find it inconsistent and unintuitive.

I think it is consistent, it works a bit like filtering an element from a mathematical set.

Given a set of sheeps, let x be the five-legged sheep is inconsistent because we know neither the existence or uniqueness of shuch sheep, so it raises an exception.

Given a set of sheeps, let x be the subset of five legged sheeps is the empty set because there is no such sheep.

but this may also just be because I internalised Python's behavior.

Some language have a specific value to denote the first thing, for example:

   ["a", "b", "c"][4]
gives `undefined` in JavaScript but it differs from `null` which would be the equivalent to `None` in Python (and I don't think Python has such concept).

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

#49

Post by macintux »

hk__2 wrote: post #44
macintux wrote: post #41

Earlier quoted context omitted.

Then why doesn’t a[1] return None? I understand the logic behind both decisions, but it’s not surprising that people find it inconsistent and unintuitive.

> Then why doesn’t a[1] return None? Because there would be no way to distinguish between "a[1] contains None" and "a[1]" doesn’t exist.

And with a[1:] returning the empty list there’s no way to distinguish between a is empty and a only has one element.

These are, in the end, relatively arbitrary language design decisions.

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

#50

Post by IshKebab »

vorticalbox wrote: post #4

Why do people not just type everything they want passed? def variable(n:str, nn:str, nnn:str, *, a:int, b:int, c:int) Anything after,*, is a kwarg.

In my experience it's generally because Python developers make functions with an insane number of keyword arguments, and then wrap those functions. They don't want to type them all out again so they use kwargs.

subprocess.run() is an example of that. Also check out the functions in manim.

The inability to properly static type kwargs using TypedDict is probably the biggest flaw in Python's type hint system (after the fact that hardly anyone uses it of course).

Post reply on HN