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

141–150 of 158 posts

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

#141

Post by zoomablemind »

hk__2 wrote: post #131
zoomablemind wrote: post #68

Earlier quoted context omitted.

Both cases are an index error. It's just for some other reasons in case of the section, the error is represented by an empty object and it's left to user to handle the result. This could easily conceal the indexing error unless the caller code explicitly checks the length of the returned section.

> This could easily conceal the indexing error unless the caller code explicitly checks the length of the returned section. An empty returned section doesn’t mean the index was out of bounds (`a[0:0]`); if you want to make sure you have to check the length before slicing, like in Go.

Here it is. It only underscores the ambiguity of such handling of the section indexes. Flagging the index error would make this less ambiguous/silent.

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

#142

Post by banannaise »

veber-alex wrote: post #113
krick wrote: post #110

Earlier quoted context omitted.

Any examples? I don't write Python that much nowadays, and while I'm sure its type checker doesn't do everything , I kinda never felt disappointed by what it does. Maybe, a considerable part of that is that I still don't really think of Python as a type-checked language, so everything an IDE does for me still feels like quite a bit of an improvement over how I used to write code in Python for a long, long time. But r…

Well on Pycharm 2022.3 which is what I still have installed even this simple function doesn't show any error. def foo() -> int: pass I sure hope they improved the type checker in later versions...

On the other hand, Pycharm will show an error if you replace the pass keyword with any statement. Seems like a deliberate behavior - it declines to typecheck a stub.

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

#143

Post by uxp8u61q »

zem wrote: post #114
uxp8u61q wrote: post #86

Earlier quoted context omitted.

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)

that's what the splat operator is for - it unpacks a list into separate arguments. in this case e.g. xs = (1, 2, 3) f(*xs) is equivalent to f(1, 2, 3), not f((1, 2, 3))

And that's readable?

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

#144

Post by uxp8u61q »

BurningFrog wrote: post #103
uxp8u61q wrote: post #86

Earlier quoted context omitted.

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)

It's more readable, for my brain at least, because there is less distracting syntax cruft lying around.

You're distracted by the parentheses? Really?

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

#145

Post by BurningFrog »

uxp8u61q wrote: post #144
BurningFrog wrote: post #103

Earlier quoted context omitted.

It's more readable, for my brain at least, because there is less distracting syntax cruft lying around.

You're distracted by the parentheses? Really?

Absolutely!

Something I keep relearning is that people are different, sometimes in ways hard for me to comprehend :)

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

#146

Post by wendyshu »

throwaway2037 wrote: post #123
dragonwriter wrote: post #92

Earlier quoted context omitted.

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

In Python, except for mutability, is there any difference between tuple and list? In my experience: Pure Python people get so excited about tuples ("oh, it's so Pythonic"); others: much less.

Generally tuples are an antipattern.

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

#147

Post by throwaway2037 »

wendyshu wrote: post #146
throwaway2037 wrote: post #123

Earlier quoted context omitted.

In Python, except for mutability, is there any difference between tuple and list? In my experience: Pure Python people get so excited about tuples ("oh, it's so Pythonic"); others: much less.

Generally tuples are an antipattern.

Hot take! Can you explain more? It might foster some good discussion. Also, how do you feel about the comments from the other "sister" post? They seem to be very keen about list vs tuple.

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

#148

Post by ddejohn »

jcalvinowens wrote: post #91
curiousgal wrote: post #56

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.

> none of the benefits

Autocomplete and type-checking are massive boons to writing "type-correct" code, fast. It doesn't guarantee that your code won't explode at runtime or is logically correct (that's what tests are for), but it does help eliminate an entire class of bugs, and, again, speeds up development a massive amount when dealing with very large codebases.

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

#149

Post by ddejohn »

tomn wrote: post #42
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.

Even better when the docstring doesn't even match the signature.

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

#150

Post by veber-alex »

mathisfun123 wrote: post #136
veber-alex wrote: post #127

Earlier quoted context omitted.

> Um lol what do you think the error is here? This is widely accepted syntax for a stub. No it isn't. The accepted stub syntax is an ellipses (...). A competent type checker like pyright will error on this code. Function with declared return type "int" must return value on all code paths Type "None" cannot be assigned to type "int" And if you need more proof that pycharm is useless as a type checker: def foo(b) -> in…

I linked directly to the section of mypy docs that shows you are wrong - all you have to do is click the link to understand that you are wrong: >(Using stub file syntax at runtime). You may also occasionally need to elide actual logic in regular Python code... You can also elide default arguments as long as the function body also contains no runtime logic: the function body only contains a single ellipsis, the pass s…

And why would I care about mypy docs? pyright does the correct thing by showing an error.

In any case, the second example is definitely not a stub.

Post reply on HN