[dandiep]

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

[appplication]

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

[rollcat]

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

[f1shy]

I always saw C++ and Java addressing other issues, like low level memory management, and higher level abstractions like objects. Not so much type policy. Anyways I see a strong tendency in lots of programmers dismissing anything that is not type static-strict-safe, and others advocating for a more relaxed system.

[nurettin]

I see C++ as a scientific DSL definition language. It lets you create an abstraction and define arithmetic operators, iterators and even lets you control dereference and call semantics. The standard helps this scheme by defining return value optimization.

[za3faran]

golang isn't in the same league as the other languages mentioned. And Java and C# have come a long way since to be expressive as well as lesser syntax heavy (type inference, records, pattern matching, string templates, etc.)

[tomrod]

I'm holding out hope for a Fortran resurgence.

It's a tiny hope. But a hope nonetheless. Fortran is fun.

[haneefmubarak]

I'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]

Not 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++

[teleforce]

Check out D language, it should be suitable for math, signal processing, data science, embedded, etc, and it's intended to be better than Fortran, C and C++ [1].

[1] Is Fortran easier to optimize than C for heavy calculations?

https://news.ycombinator.com/item?id=37606477

[haneefmubarak]

I know that Fortran is highly used in the numeric world, especially due to widespread libraries such as LAPACK and BLAS, amongst others; in your opinion, what are the characteristics that make such code much more clear when written in Fortran as opposed to C or C++?

Also, do you prefer a specific version of Fortran, or is the latest one fine?

[4m1rk]

Can you give an example? I'm always curious what could be more readable than calling a few functions and composing them using properly named variables.

[drbaba]

Modern Fortran (2008+) has built-in support for matrices, complex numbers, co-arrays (parallel programming), array slicing, etc. This makes it easy to write performant compiled code if you mostly deal with numerics.

Fortran has also added support for e.g. object-oriented programming, pure functions (no side effects for better optimization), and pointers. So idiomatic modern Fortran code looks very different from the “Fortran 77” code that many people might think of when they hear the name :).

[f1shy]

I would really like to see more fortran.

[jules22]

What does a modern Fortran bring that Julia does not? Small binaries?

[xmcqdpt2]

Language stability, and easy C ABI for embedding into other programs. Julia isn't really a language for embedding afaik.

[jules22]

Sure, not in the traditional sense. Since it does not make small standalone libraries, even though possible, I would not make a native extension with it. But juliacall works fine for Python and R. Quite seamless.

[jules22]

Nim/Julia, IMO.

However....

Nim is unlikely to go mainstream. It's not the next Rust and not for technical reasons.

Julia won't budge Python out of the top slot anytime soon, although it should in many scenarios past simple scripting.

[fiedzia]

Python is very strict about type checking, it just does it at runtime.

The next step is Idris, where you define starting and desired type and start interactive shell to figure out right way to get there.

[diarrhea]

It’s like pointer chasing, except the docs having you chase around kwargs are incomplete and there’s gaps. You have to read source code.

The Azure SDK is full of them, making liberal use of kwargs.pop. What a nightmare.

[gen220]

`kwargs.pop`, what a phrase – it's amazing how the right arrangement of syllables can make your brain shudder. (:

[b33j0r]

Well, who hasn’t used that classic datastructure `dictstack` (and famously the dict.pop operation)?

At first I was kinda giggling. But actually there are such things, if the Mapping is also ordered.

LRU cache, trees, tries… and—oh wait—all CPython dicts are ordered these days!

(Honestly I have only used the modern ordered-nature of `dict` for serialization to versioned or human-editable files. But why not an algorithm with a “`stackdict`” I guess?)

[mrweasel]

The Azure SDK generally have a lot of silliness in the Python implementation. Functions that take string as inputs, except of course they don't, they take two or three very specific string values and use them to control functionality. What those values are... Well, you should take a look at the ENUM in the C# implementation to figure that part out.

[MrBuddyCasino]

Relieved to learn its not just the Java libs that are piles of hastily cobbled-together crap.

[vorticalbox]

Python has enums though :(

[mrweasel]

Sure, but Microsoft doesn't always use them.

[masklinn]

A big use case for kwargs is not breaking compatibility and not having to copy/paste a ton of parameters when just forwarding them. But that's exactly the case which is difficult to type correctly.

[appplication]

Either copy/paste or rolling them into config objects and passing those down is generally preferable. Copy paste doesn’t always feel great for pass through arguments but it’s perfectly interpretable.

Naked kwargs is so difficult to work with that I hesitate to think of a use case where it wouldn’t be an anti pattern.

[memco]

> Either copy/paste or rolling them into config objects and passing those down is generally preferable

Preferable for whom? I do not prefer it. I much prefer to avoid the extra work it creates for me vs. the simplicity of kwargs. I use explicit args for the function I made and then add *kwargs on the end and then I don't have to write bespoke config objects or copy and paste a bunch of stuff that might be obsolete by a future update to some library and also pollute my function's signature. I would very much welcome a way to tell callers where kwargs is going without having to do extra work.

[appplication]

Preferable for those who would use your code. If it’s just you then it’s your exclusive preference. If you have users, args/kwargs is going to be more opaque than a more explicit option.

For code with many users, creating a few extra minutes of work for one dev is preferable when the alternative would be every dev who uses that code has to spend that same extra work and then some to grok what exactly is going on with the method signatures. Being explicit also creates traceable code, in that you can search a keyword to find everywhere it’s used or passed rather than tracing methods where it might be used.

I can promise very few users would be thankful for the elegance and minimalism of args/kwargs when they’re source-diving trying to figure out how to get some basic functionality to work.

[paiute]

I think people kind of miss the idea of kwargs in python, the idea is that they are a dict. You can cast a dict to kwargs, in contrast to positional args. I see the typedict being super useful. I really don’t see your argument and would say that this typed dict is more developer friendly than having positional arguments. https://docs.python.org/3/tutorial/controlflow.html#more-on-...

[memco]

I haven't often been the designer of code others have used, but I have used someone else's wrappers for libraries that we use in many parts of our code. My experience of trying to use their wrappers has been a guessing game of how they decided to arbitrarily rename an argument and finding places where they don't support arguments that I need. I get that kwargs is a bag of mystery and that there is benefit to being explicit, but it comes with tradeoffs. I don't like really like kwargs, but sometimes the use of kwargs better serves the purpose than the alternatives. I've looked for solutions, but haven't found anything that avoids the above issues. If anyone has tools or techniques that eliminate these pain points please share. The typedDict is promising, but I'm not sure how composable they are. Time will tell.

[dbrueck]

I think naked kwargs can be abused, but there are many legitimate use cases for them. For example, we interface with a message bus that uses JSON for transport. There are several different ways to enqueue a message onto the bus, and it would add a ton of complexity and no real value to define the parameters for each of those Send APIs.

Looking at it another way, the hunk of code in charge of serializing your message does not care one whit about the innards of each message, and making it become aware would add tremendous complexity with no real value.

[rpcope1]

There's at least a handful of places that you can't escape them, one of the most evident in my mind is when constructing higher order functions or other decorators. Maybe a simple example would be a retry higher order function (or decorator), where you can't know the arguments and their form ahead of time, and want to invoke the wrapped function as is (and only do something like repeating if an exception is triggered). Keyword arguments are helpful for writing certain kinds of generic code, but definitely can be easily abused (much like most of the meta-programming facilities in Python).

[Earwig]

This is excellent for adding typing to libraries originally designed without it in mind while keeping backwards compatibility.

[shrimpx]

If you didn't use **kwargs you'd have to copy and paste every kwarg and its default value from the superclass into the subclass, which is ridiculous IMO.

[bjornasm]

caugh fastai caugh

[winter_blue]

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

[shrimpx]

> disaster of an anti-feature

Untyped languages tend to be at the forefront of paradigms, and typed languages come in toward the end when reliability and need for tooling are more important than innovation/discovery.

In the 90s a bunch of kids were building websites with LAMP stacks while serious engineers were building aging/about-to-be-irrelevant desktop software in serious, typed languages.

[blacklight]

I love Python, but I also love the ability to tell what is what.

I kickstarted a project in Python a decade ago that was wild on dynamic typing. As it passed a critical threshold of ~10k LoC, it became nearly ummaintainable.

What's that `response` passed here? A verbatim response object from `requests`? A proxy mapping? Bytes? A JSON string? If so, a list or a dict? And what fields are inside?

Multiply it by tens or hundreds of methods and classes, and it's easy to see why projects based on purely dynamic patterns fail to scale.

By now I have almost completely rewritten that project to use type hints everywhere I could. And guess what? In 95% of the cases I knew exactly what was being passed - or the choice was about 2-3 types at most, so a Union sufficed.

Yes, there's a 5% of cases where Python's dynamic typing features are a blessing. The power of meta programming in Python is often underestimated. Reflection is amazingly intuitive compared to the patchwork mess of Java, Kotlin and friends. Everything can be mocked without hassle and boilerplate. And duck typing can really be useful sometimes.

But, again, in an average project I wouldn't expect code that benefits from these features to make up more than 5-10% of the codebase.

For everything else, just do yourself, your future self and anyone who will work on your code a favour, and use type hints.

[shrimpx]

I agree. And what makes python a nice choice for this is that you can go wild in the beginning and then gradually add type hints as your project takes shape.

[winter_blue]

Statically typed languages in the 90s had a reputation for being verbose (like Java’s Cat = new Cat()), or difficult to work with (like C’s manual memory management). Haskell and other ML family languages hadn’t quite gotten that popular. Type inference wasn’t a feature in many popular statically typed languages until recently. And type inference makes static typing significantly easier.

The P in the LAMP stack is still a bit of a mystery to me. It could (one could wish) have been Haskell instead, but oh well.

[wiseowise]

Guess on VM written in which language those LAMP stacks run on?

[shrimpx]

Sure. The “serious” stuff is written in more serious languages and the rapidly changing experimental stuff in more lenient and expressive languages.

[goatlover]

It'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]

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

[schrodingerscow]

Ha you sound exactly like my own consciousness. There are few things in life I feel as resolute about than this one. Dynamic types were a mistake. Let’s learn and move on. I often joke that if null pointer references were the billion dollar mistake (or whatever it’s called), dynamic typing was the 100 billion dollar mistake. And we’re still living with it but thank god for typescript etc for saving us finally

[winter_blue]

Thanks. Yeah, I agree.

[seunosewa]

But third party code in Python was easy to read.

[ledauphin]

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

[pmeira]

Some packages already use those. For previous Python versions, those are available in typing_extensions: https://typing-extensions.readthedocs.io/en/latest/

[vorticalbox]

some add what it takes in the DOC string, but even then most don't actually state all the options.

[diarrhea]

Yep, 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!

[gv83]

These days you want java then! Why are you not using java?

[anakaine]

Because compared to the ease of use and readability of python you get 1/10th the work done with 5x the pain in the arse.

[hyperbovine]

Surely you mean `**kwargs`

[unstruktured]

Unfortunately the typed kwargs are NOT composable :(.

[dagmx]

I wonder if Unpack works on a function? I assume it’s any callable.

[squeaky-clean]

The type that gets Unpack[]'d needs to inherit from TypeDict, unless I'm misunderstanding what you mean.

[dagmx]

Basically 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]

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

Hmm thanks. I think that might be slightly different but I’ll try it out and see.

[markrages]

Modern Python is sure ugly.

[IshKebab]

Finally! 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]

Software 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/

[IshKebab]

Sure and how do you install Python 3.12 on RHEL 8 without compiling it from source?

[JodieBenitez]

I 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]

I 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]

Just run the miniforge install script if you want a very friction-free install. I'm not a big conda fan, but the "install in my home directory" use case is very well covered by miniforge. https://github.com/conda-forge/miniforge/

[IshKebab]

That looks like it will install Conda though?

[nurettin]

Are you really going to support rhel8 as a platform for your project which uses specific python 3.12 rc3 features? Well there's always podman, I guess.

[heavyset_go]

Use pyenv and let it manage Python versions for you.

[IshKebab]

pyenv builds Python from source.

[heavyset_go]

Yes, but it's automated behind a single command and fast.

[avtar]

Using containers is a reasonable workaround:

https://realpython.com/python-versions-docker/#running-pytho...

[dist-epoch]

On Ubuntu at least you can install versions of Python separate from the system one.

https://www.cherryservers.com/blog/install-python-on-ubuntu

[hotnfresh]

> Bets on user-upgradable Python on Linux by 2030?

Use asdf. You don’t want to manage your project’s dependencies at the system level any more than you have to.