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

131–140 of 158 posts

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

#131

Post by hk__2 »

zoomablemind wrote: post #68
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.

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.

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

#132

Post by toxik »

akasakahakada wrote: post #40
cbarrick wrote: post #32

Earlier quoted context omitted.

> I'm not sure what it means to "merge two functions into one", can you elaborate? I'm not OP, but I see this pattern often enough: def foo(**kwargs): pass der bar(**kwargs): pass def wrapper(**kwargs): foo(**kwargs) bar(**kwargs)

Yup, this exactly.

What would you have wraps() do for two functions? Concatenate the docstrings and union of the annotations? Perhaps you want only the latter, that seems like it could easily be its own decorator: `@functools.annotate_intersection(f1, f2, …)`

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

#133

Post by jraph »

Skeime wrote: post #128
throwaway2037 wrote: post #120

Earlier quoted context omitted.

To add to your list: During string concatenation, there is no automatic conversion to string. It results in an exception. It is infuriating. This code: "abc" + 123 ... will raise this exception: TypeError: can only concatenate str (not "int") to str I have wasted so many hours fixing this same bug, over and over again.

I strongly disagree. Not converting the int to a string automatically is absolutely the right decision. In all code I write, this TypeError would catch an actual error, because concatenation of strings is just not the right tool for creating "abc123" from "abc" and 123, so I would not use it for that. Hence, if this exception occurs, it indicates that I probably mixed up variables somewhere. Use one of the (admittedl…

Interesting. 100% of the times I encountered this TypeError, I actually wanted to create the concatenated string. It never caught an actual error.

Now, I guess I'm not against and explicit cast and I can imagine how the error could catch an actual bug. It's painful when the error stops the execution when the string concatenation was intended, but it is not really an issue anymore with the possibility to type check before the execution.

> concatenation of strings is just not the right tool for creating "abc123" from "abc" and 123

Why? This sounds like an opinion to me. String interpolation of formatting features are nice but I find them quite clunky in such simple cases.

Of course when you have to be careful to call str(val), it's arguably as clunky...

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

#134

Post by dontlaugh »

throwaway2037 wrote: post #122
dontlaugh wrote: post #87

Earlier quoted context omitted.

Having used Python a lot, I was never glad for multiple inheritance. I’d prefer traits.

Are traits and mixins the same? If not, can you please provide a trivial example. It would be useful to better understand what you mean. When I was very young, learning C++, I thought multiple inheritance was so cool. Now, I know it is like sleeping in the open jaws of a saltwater croc.

Traits as in the original Smalltalk research, Rust traits or Haskell type classes are like interfaces, but only when in scope. So until you import a trait, its implementation on various types isn’t visible.

This makes it possible to safely make a new trait and implement it on a built in type (like giving int a method) without the chance of another unrelated use of the type accidentally using what this trait provides.

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

#135

Post by maxbond »

krick wrote: post #112
dcgudeman wrote: post #107

Earlier quoted context omitted.

It’s sad to see this happen to be honest. Seems like Jet Brains is getting distracted from their core value proposition: good IDEs. If electron based IDEs are becoming more responsive and performant than their “native” IDEs they have major priority problems.

What even distracts them? IDEs are supposedly the only thing they do. Well, maybe except for Kotlin. And it's not like their IDEs are very cheap either. I mean, not that cheep that I'd like the idea of being too much mentally invested into something, that barely competes with a free source-code editor, let alone lags behind it.

I don't actually know but my assumption is that that they're working with a very old codebase based on the "bespoke parsing and plugins for every language" paradigm that served them well for decades. Meanwhile eg VSCode is using the "language server with treesitter and queryable compiler genetically integrated over a standard API" model that's only recently become widespread.

When I first learned about LSPs it was immediately clear to me they would run circles around the "traditional" IDEs. I'd given up on using IDEs because I found them too finicky and error prone, but LSPs have been a total game changer.

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

#136

Post by mathisfun123 »

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

Earlier quoted context omitted.

Um lol what do you think the error is here? This is widely accepted syntax for a stub. So yes it does return None if run but it's not expected to ever be run. So pretty ironic that you would blame pycharm (which is indeed excellent) for your own misunderstanding. https://mypy.readthedocs.io/en/stable/stubs.html#using-stub-...

> 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 statement, or a raise NotImplementedError(). It is also acceptable for the function body to contain a docstring. For example:

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

#137

Post by [deleted] »

jraph wrote: post #133
Skeime wrote: post #128

Earlier quoted context omitted.

I strongly disagree. Not converting the int to a string automatically is absolutely the right decision. In all code I write, this TypeError would catch an actual error, because concatenation of strings is just not the right tool for creating "abc123" from "abc" and 123, so I would not use it for that. Hence, if this exception occurs, it indicates that I probably mixed up variables somewhere. Use one of the (admittedl…

Interesting. 100% of the times I encountered this TypeError, I actually wanted to create the concatenated string. It never caught an actual error. Now, I guess I'm not against and explicit cast and I can imagine how the error could catch an actual bug. It's painful when the error stops the execution when the string concatenation was intended, but it is not really an issue anymore with the possibility to type check be…

[deleted]

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

#138

Post by akvadrako »

joshuamorton wrote: post #71
b5n wrote: post #66

Earlier quoted context omitted.

I usually start with a namedtuple unless I need the additional features provided by a dataclass.

Why? Dataclasses are vastly better: more typesafe, less hacky, etc.

The new syntax is basically the same as dataclasses:

  class Employee(NamedTuple):
    name: str
    id: int

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

#139

Post by Skeime »

jraph wrote: post #133
Skeime wrote: post #128

Earlier quoted context omitted.

I strongly disagree. Not converting the int to a string automatically is absolutely the right decision. In all code I write, this TypeError would catch an actual error, because concatenation of strings is just not the right tool for creating "abc123" from "abc" and 123, so I would not use it for that. Hence, if this exception occurs, it indicates that I probably mixed up variables somewhere. Use one of the (admittedl…

Interesting. 100% of the times I encountered this TypeError, I actually wanted to create the concatenated string. It never caught an actual error. Now, I guess I'm not against and explicit cast and I can imagine how the error could catch an actual bug. It's painful when the error stops the execution when the string concatenation was intended, but it is not really an issue anymore with the possibility to type check be…

Of course it’s an opinion. But in my experience, I almost exclusively have some sort of “template” with some parts to fill out, and string interpolation represents this better (in my opinion). This is especially true if the different parts to fill in are of different types.

As I wouldn’t use string concatenation for this purpose, it’s impossible for me to run into a situation where I wanted the concatenated string. (And even if I did, I would be glad for the reminder to change this into an f-string.)

And the bugs that it catches are of the form: I took some user input, expecting it to be a number, but forgot to convert it into one. Then I passed it to a function expecting a number, and it thankfully crashed instead of turning everything else into strings as well.

Maybe this is also a question that informs your view on this: Do you expect "abc" or 123 to be the “variable” part of that expression?

- If "abc" is a literal in the code with 123 coming from a variable, wanting 123 to turn into a string as well is somewhat unterstandable. - However, if 123 is the literal part of the code and "abc" the value of some variable, I would expect to mostly run into this in cases where I am actually doing some math and that the variable is a string just is some accidentally unparsed input.

In what I do, the second case would be more common.

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

#140

Post by polski-g »

SushiHippie wrote: post #10

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

In this section, what is this slash in the function definition for the second foo() ?

https://peps.python.org/pep-0692/#keyword-collisions

Post reply on HN