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

111–120 of 158 posts

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

#111

Post by PheonixPharts »

twelve40 wrote: post #101
PheonixPharts wrote: post #99

Earlier quoted context omitted.

"my current project" type problems are where Python is great. Types remain "nice to have" (if you like them) and aren't really essential compared to the ease of prototyping new ideas and building a PoC. You're choosing Python because the benefit of libraries outweighs your personal preference for types. Most of my work is in machine learning/numeric computing, so I'm very familiar with the benefits of Python's ecosys…

You keep saying how typing prevents some "elegant" things (are they really prevalent?) or "iterating fast greatly trumps the need for type safety". But in my experience, anything more than half a dozen modules/classes can turn into a bloody minefield very fast. And the supposed speed of iteration is negated and reversed by having to dig through the untyped codebase trying to very inefficiently determine the types man…

> anything more than half a dozen modules/classes can turn into a bloody minefield very fast

I don't disagree with this, but it's worth noting that there are many data scientists I've worked with who have never written a python class or module, and yet produced large amounts of valuable work.

For quick prototyping and exploratory work, both domains where Python sees a lot of success, it's often the case that you don't really know what types you're working with and are iterating very quickly, such that not being able to quickly change all of the types your working with can be a time sink.

So I think you're imagining writing software that is starts more well defined than most optimal use cases for Python.

> And the supposed speed of iteration is negated and reversed by having to dig through the untyped codebase trying to very inefficiently determine the types manually

I do understand this feeling, but this is applying the logic/patterns of statically typed programming dynamic programming. The dynamic answer to "how do I write robust code" is not to keep the types in your head, it's write tests. Well written tests in turn become documentation for your code.

Again, this style of programming works well when you don't really even know how you want your programming to behave. You naturally write tests when writing this kind of code, even if it's just manual tests. Get in the habit of starting your manual tests as unit tests and you're already doing TDD.

Dynamic types works best when you are writing code in a very interactive and exploratory way.

To be clear: I'm not advocating for dynamic languages over statically typed ones. I do believe, whenever possible, production software should be written in strongly typed languages. I think anytime you know the behavior of your program before you start writing you should use statically typed languages.

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

#112

Post by krick »

dcgudeman wrote: post #107
veber-alex wrote: post #70

Earlier quoted context omitted.

Pycharm has the worst type checker that exists today. It may have been the best a few years back but others have suppressed it considerably. I recently switched from Pycharm to vscode which uses pyright and it's night and day on the amount of type errors it catches, it considerably improved the quality of my code and confidence during refactoring. And to add insult to injury Pycharm doesn't even have a pyright plugin…

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.

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

#113

Post by veber-alex »

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

Earlier quoted context omitted.

Pycharm has the worst type checker that exists today. It may have been the best a few years back but others have suppressed it considerably. I recently switched from Pycharm to vscode which uses pyright and it's night and day on the amount of type errors it catches, it considerably improved the quality of my code and confidence during refactoring. And to add insult to injury Pycharm doesn't even have a pyright plugin…

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

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

#114

Post by zem »

uxp8u61q wrote: post #86
Znafon wrote: post #69

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

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

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

#115

Post by LBTables »

bowsamic wrote: post #89
yayachiken wrote: post #38

Earlier quoted context omitted.

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

At an even more basic level, the lack of static typing seems like such a tradeoff getting an incredibly huge nuisance in readability and stupid runtime bugs that shouldn't be a thing in exchange for a feature that's rarely useful.

Granted, I'm primarily an embedded developer. Can any Python experts explain to me a highly impactful benefit of dynamic typing?

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

#116

Post by systemvoltage »

EdwardDiego wrote: post #104
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.

/me cries in Django Kwargs everywhere, often only defined for a type at runtime by spooky voodoo action at a distance metaclass shenanigans...

Hello, I am pytest. I heard ya'll are talking about magic and kwargs fudging?

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

#117

Post by mathisfun123 »

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

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

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

#118

Post by ddejohn »

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

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:])

That is an entirely different use-case than a function signature allowing arbitrary keyword arguments. Arbitrary keyword args are different than arbitrary positional args like you have in your example.

GP is suggesting that one should only ever use explicit keyword-only args (anything listed after `*,` in the signature) versus arbitrary keyword args implicit via `**kwargs`.

e.g. (omitting type hints for clarity):

    def sum(*args, **arbitrary_kwargs):
        ...
vs

    def sum(*args, some_keyword_only_arg):
        ...
In my opinion if one finds themselves writing code that uses arbitrary kwargs, they've got a design problem.**

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

#119

Post by throwaway2037 »

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'm pretty sure they make most of their money from TeamCity build agents.

IntelliJ (the Java+ IDE) always has a community edition that is open source. I can vouch that it is truly free and not crippleware. For most Java programmer, this edition is sufficient.

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

#120

Post by throwaway2037 »

bowsamic wrote: post #89
yayachiken wrote: post #38

Earlier quoted context omitted.

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

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.
Post reply on HN