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

101–110 of 158 posts

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

#101

Post by twelve40 »

PheonixPharts wrote: post #99
mirsadm wrote: post #83

Earlier quoted context omitted.

Have to disagree with this. Choosing a language is not just about its features but also its ecosystem. I chose Python for my current project because it has great libraries that don't exist in other languages.

"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 manually, with my own eyes, as to not screw up. What are those supposed super-benefits of ditching type safety?

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

#102

Post by no_wizard »

veber-alex wrote: post #70
zbentley wrote: post #24

Earlier quoted context omitted.

While functools.wraps does propagate __annotations__ by default, be aware that not all IDE-integrated type checkers handle that properly. It's easy in PyCharm, for example, to use functools.wraps such that the wrapper function is treated by the IDE as untyped. Underneath, this is because many (most?) type checkers for Python aren't actually running the code in order to access annotation information, and are instead p…

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…

There definitely seems to be a few areas since the Fleet announcement that have given me pause on JetBrains.

Their Python support has t kept up with other tools as noted. I’ve see a similar decline in the ability for for them to keep up to date with things like Svelte, Vue, Astro etc too.

They need to embrace the LSP

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

#103

Post by BurningFrog »

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)

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

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

#104

Post by EdwardDiego »

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

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

#105

Post by thaumasiotes »

sdenton4 wrote: post #94
esafak wrote: post #74

Earlier quoted context omitted.

Your example has a fixed number of names. What if you wanted to accept any number of names, like Pablo Diego José Francisco de Paula Juan Nepomuceno María de los Remedios Cipriano de la Santísima Trinidad Ruiz y Picasso ? Really, though, Iterables make more sense for monadic types.

We would force broad changes in human society to conform to the assumptions of our database scheme, same as we always have.

I knew a Chinese girl whose parents, surnamed 吕 and 郎, wanted to give her the combined surname 吕郎. This was not allowed, so formally she was surnamed 吕 and given a three-syllable personal name starting with 郎.

There are a couple funny things about this:

1. A personal name of three syllables is stranger than a surname of two.

2. Double-syllable surnames are unusual, but definitely not unheard of. This girl told me that she hadn't been allowed to receive the double surname 吕郎, because it was too long. I asked what would have happened if her double surname had been 司马 instead. "That's different!"

(If the government of China tried to pick a legitimacy fight with the name 司马, it would lose, and everyone knows this.)

So this almost looks like an example of the kind of thing you're referring to, except that the database scheme has nothing to do with it. A surname that was nontraditional but within the technical norms was rejected in favor of a personal name that was both nontraditional and well outside the technical norms.

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

#106

Post by EdwardDiego »

PheonixPharts wrote: post #78
curiousgal wrote: post #56

Is it just me or are Python type hints like..goofy?

As someone who has written Python for nearly 20 years now, and also has plenty of experience with strongly and statically typed languages (including a fair bit of Haskell), I think type hints in Python should at most remain just that, hints . A language being statically typed or dynamically typed is a design decision with implications for what the language can do. There are benefits to each method of programming. Try…

Last thing I want is Go types tbh. Trying to figure out what implements a given interface is difficult without a sufficiently clever tool.

Funnily enough, Python has Go-esque types also, Protocols, and they have the exact same issue. I only use them when I really really need structural typing to reuse code in a typesafe way.

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

#107

Post by dcgudeman »

veber-alex wrote: post #70
zbentley wrote: post #24

Earlier quoted context omitted.

While functools.wraps does propagate __annotations__ by default, be aware that not all IDE-integrated type checkers handle that properly. It's easy in PyCharm, for example, to use functools.wraps such that the wrapper function is treated by the IDE as untyped. Underneath, this is because many (most?) type checkers for Python aren't actually running the code in order to access annotation information, and are instead p…

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.

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

#108

Post by jtdev »

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

[dead]

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

#109

Post by dcgudeman »

voz_ wrote: post #79
refactor_master wrote: post #31

Earlier quoted context omitted.

Usually the solutions range from a culture of “just don’t” to tests/mypy that have become increasingly stricter over the years, every time we’ve come a step further up the ladder. But I admit, it has taken quite some bridging to get there. Moving to static Python in most places has dramatically improved the code and language.

As someone that works on a Python compiler, this is a very limited view of reality…

Can you explain a bit more?

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

#110

Post by krick »

veber-alex wrote: post #70
zbentley wrote: post #24

Earlier quoted context omitted.

While functools.wraps does propagate __annotations__ by default, be aware that not all IDE-integrated type checkers handle that properly. It's easy in PyCharm, for example, to use functools.wraps such that the wrapper function is treated by the IDE as untyped. Underneath, this is because many (most?) type checkers for Python aren't actually running the code in order to access annotation information, and are instead p…

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 really, "night and day on the amount of type errors"?..
Post reply on HN