16 ms·
Ooh, seems there is a new syntax for declaring the types of kwargs [1]: from typing import TypedDict, Unpack class Movie(TypedDict): name: str y
by dandiep 3y ago
Ooh, seems there is a new syntax for declaring the types of kwargs [1]:
from typing import TypedDict, Unpack
class Movie(TypedDict):
name: str
year: int
def foo(*kwargs: Unpack[Movie]): ...
Maybe now I'll be able to actually figure out what data to send libraries without actually reading their source code.
1. https://docs.python.org/3.12/whatsnew/3.12.html#pep-692-using-typeddict-for-more-precise-kwargs-typing https://docs.python.org/3.12/whatsnew/3.12.html#pep-692-usin...
- ledauphin 3y agowhat's especially interesting about this is that it could create a new "meta" for static typing in Python. One significant issue with static typing in Python is how much boilerplate is required to use types when also doing the sorts of things that dynamic Python is really good at - for instance proxying functions. If you want to do that now and preserve the types, you need to re-declare the types of everything in the wrapper. Now, if the underlying function already made use of Unpack, you could "reuse" that type in your own wrapper with low boilerplate and less chance of things diverging in hard-to-refactor ways.
- zackees 3y ago[dead]
- dagmx 3y agoI wonder if Unpack works on a function? I assume it’s any callable.
- squeaky-clean 3y agoThe type that gets Unpack[]'d needs to inherit from TypeDict, unless I'm misunderstanding what you mean.
- dagmx 3y agoBasically I was hoping to use it for functions that wrap others. E.g setup something and then pass the kwargs through to the other function.
- benkuykendall 3y agoIf I understand you correctly, I think ParamSpec (since 3.10) is what you are looking for, especially if you want to be generic over the type of the inner function. The example from the docs (https://docs.python.org/3/library/typing.html#typing.ParamSpec https://docs.python.org/3/library/typing.html#typing.ParamSp...): from collections.abc import Callable from typing import TypeVar, ParamSpec import logging T = TypeVar('T') P = ParamSpec('P') def add_logging(f: Callable[P, T]) -> Callable[P, T]: '''A type-safe decorator to add logging to a function.''' def inner(*args: P.args, **kwargs: P.kwargs) -> T: logging.info(f'{f.__name__} was called') return f(*args, **kwargs) return inner @add_logging def add_two(x: float, y: float) -> float: '''Add two numbers together.''' return x + y
- dagmx 3y agoHmm thanks. I think that might be slightly different but I’ll try it out and see.
- hyperbovine 3y agoSurely you mean `**kwargs`
- winter_blue 3y ago> be able to actually figure out what data to send libraries without actually reading their source code Just reading this sent a chill down my spine. I have horrible memories of having to read the code to figure out what something was doing (in JavaScript, Python, Ruby, etc), due to the disaster of an anti-feature called dynamic typing having been used.
- seunosewa 3y agoBut third party code in Python was easy to read.
- goatlover 3y agoIt's not an anti-feature. Those languages gained popularity in part because they were dynamically typed. But this debate is decades old and people always dogmatically choose one side, so not really any point in trying to convince you. Alan Kay made the argument back in the 1970s that type systems were always too limiting, therefore classes and late binding were the answer for him.
- winter_blue 3y agoI’m speaking from my real-life lived experience with dynamic typing. I feel that dynamic typing is truly harmful for any project that involves involving complex logic, needs collaboration / where there’s more than 1 person working on it, or even for any large project (even if only 1 person is working on it). It was a massive waste of time to have to read piles of code code, use a debugger and inspect object structure, to understand how some parts of certain large codebases worked. In my experience, dynamic typing has simply been horrible for team collaboration, code readability (and ease of understanding), and it results in a large number of bugs that could easily have been eliminated with static type checking. > But this debate is decades old and people always dogmatically choose one side, so not really any point in trying to convince you. You’re right about that. I am indeed very dogmatic and take a hard-line on this. I take a stronger position on this than most things (for example: something very subjective like curly braces versus white space indentation), to the point that I’ll say this: dynamic typing is simply a wrong and bad engineering decision. Another example of a bad language design decision is allowing null to be a part of every type instead of requiring an explicit ? in the type, or the use of an Optional wrapper. This has been recognized as an ill, andis something many modern languages (to name a few: Rust, Kotlin, etc) fixes. But that isn’t meant to level a personal attack against the languages designers of the past (or to say that they were stupid). Allowing every type to be Union[T, null] was a simply a language design mistake (that potentially cost wasted billions of dollars), but it's been recognized as a mistake today that we need to rectify and move forward from (as is reflected by decision made by more recent languages). However, imo, in comparison, dynamic typing is a 100 times worse than not having null safety (or not having memory safety like C or C++). I can work with a C or C++ without much trouble, but not with dynamic typing. Dynamic typing makes it difficult and unpleasant to work with a large codebase, to an inexcusable degree.
- IshKebab 3y agoFinally! I've been waiting for this for years. Now I just have to wait 5 more years until 3.12 is sufficiently old that work lets me use it. Bets on user-upgradable Python on Linux by 2030?
- ptx 3y agoSoftware is always user-upgradable on Linux. Just install it somewhere in your home directory. GNU Stow [0] can be helpful as a very lightweight way to manage the packages. (Of course, then you take on the responsibility of keeping up with patch releases yourself, which is why we use distros. But if it's just a small number of packages on top of a distro-managed base system, it's perhaps not so bad.) [0] https://www.gnu.org/software/stow/ https://www.gnu.org/software/stow/
- IshKebab 3y agoSure and how do you install Python 3.12 on RHEL 8 without compiling it from source?
- JodieBenitez 3y agoI don't know, but what is the problem with compiling from source ? Some softwares are hard to compile but I found Python really easy to compile.
- IshKebab 3y agoI agree that compiling Python from source is surprisingly straight forward, but is that a serious question? Have you ever worked in a place that uses Python? When someone says to you "hey it's not working" are you really going to say with a straight face "oh yes, you just need to compile Python from source". Come on, this is one of those obviously stupid situations that for some reason people feel the need to defend. It's not defensible. You don't need to compile Node or Rust or Go or Deno from source to install the latest version.
- Cynox 3y ago
- pmeira 3y agoSome packages already use those. For previous Python versions, those are available in typing_extensions: https://typing-extensions.readthedocs.io/en/latest/ https://typing-extensions.readthedocs.io/en/latest/
- markrages 3y agoModern Python is sure ugly.
- unstruktured 3y agoUnfortunately the typed kwargs are NOT composable :(.
- vorticalbox 3y agosome add what it takes in the DOC string, but even then most don't actually state all the options.
- diarrhea 3y agoYep, it’s incomplete, and much more importantly not machine readable. These days I want all my code to pass strict mypy. It’s mostly possible and a bliss when it works, but libraries (ab)using kwargs throw a spanner in that. Libraries where everything is kwarg and the docs have to be consulted are a killjoy. And they cause tons of bug from misuse!
- appplication 3y ago> Maybe now I'll be able to actually figure out what data to send libraries without actually reading their source code. One could hope, but any library abusing kwargs in all their methods is showing they’re willing to go through the absolute minimum to make their code usable, let alone readable and self-documenting.
- Earwig 3y agoThis is excellent for adding typing to libraries originally designed without it in mind while keeping backwards compatibility.
- rollcat 3y agoIt feels like we're going in cycles. C was somewhat lax with type checking, thus C++ and Java were both made more strict. Looking to escape the tyranny of static typing, the rise of Python, Ruby, or JavaScript instead left us with a desire that Rust, Go, and TypeScript now fulfill. I wonder what's the next step? LLMs are extremely broad in what they accept, but don't exactly fill the same niches.
- tomrod 3y agoI'm holding out hope for a Fortran resurgence. It's a tiny hope. But a hope nonetheless. Fortran is fun.
- haneefmubarak 3y agoI'm curious - what do you particularly like about Fortran that isn't otherwise broadly available? Is it a matter of cultural idioms, a unique composition of features, or something else entirely?
- f1shy 3y agoNot OP, but I know a good use case: where I work we do lots of math and signal processing. It is done in matlab, which is great, but then we need to run it in some embedded processor. Using the C++ generated by matlab is beyond any hope. Had the code be written in Fortran (which is very possible, and would make the code clearer) it would run very fast. Now we had a team of people translating matlab to C++