Implicit Keyword Arguments for Python | Hacker News Reader

Implicit Keyword Arguments for Python

lwn.net

31 pointsjwilk16 comments

I feel like Python is getting ever farther away from "Explicit is better than implicit."

From the moment python decided `if L:` was the way to check whether a list was empty, it was explicitness was never its goal.

If it's gonna happen, and I'm not convinced it needs to, it needs to be a prefix. Otherwise, it's harder to distinguish positional and keyword arguments.

But like the walrus operator (I was on the side of reuse of the keyword as), I worry I'll be on the losing side of this one too.

I think borrowing object creation via spreading from JS would be a great option for this. The prefix would be the double , which would also differentiate it from a set. Something like
def foo(long_argument1: str, long_argument2: str): pass long_argument1 = “some value” long_argument2 = “another value” foo(**{long_argument1, long_argument2})*

Rust doesn't have keyword arguments, but does this for struct initializer expressions. Works pretty well; the `rust-analyzer` language server handles variable renames, so that's not an issue.

https://rust-lang.github.io/rfcs/1682-field-init-shorthand.h...

I wonder if they could brand this differently.

Cause you know, "explicit is better than implicit"

Other Zen of Python principles are allowed to override it. Let's say, "Readability counts".

I have some of the same concerns that Miraculixx iterated.

A small addition: I think it will lend itself to callers preferring to the use the same names in the calling function as in the parameters to take advantage of this feature, instead of using a name that is more appropriate for the context.

I wonder how scoping would work. That could result in the interesting bugs.

How do people who code in languages that have this feature like it?

> I think it will lend itself to callers preferring to the use the same names in the calling function as in the parameters to take advantage of this feature, instead of using a name that is more appropriate for the context.

The more concrete a function is, it's more useful than not to have the names match (or be very similar); and that mismatched names smell of bad naming.

Comparing "customerName = customer.bankId" with "customerName = customer.name".. there's less cognitive overhead if the latter is the one which works.

For very 'concrete' functions, e.g. `updateInfo(bankId, customerName, payload)` or `updateInfo(customerName, bankId, payload)` both look correct, and it's possible to imagine one being a typo of another. Named arguments avoids this.

:o) And for those who use LLM tools which can quickly output lots of code which looks-correct-but-may-be-buggy, it's nice to have these 'conservative' features which reduce risk of 'looks correct, but is not what was intended'.

Whereas, say, the arguments to string.format or list.map, these functions are so abstract that positional arguments don't suffer the same risks (to the same extent).

This is similar to JS (which has to use objects instead of keyword args).

  a = 1
  b = "foo"
  c = null
  f({a, b, c})

This is a popular feature.

name= for name=name?

Another major miss-step in recent python syntax evolution, even worse than the worst perl5 obscurities.

For sure everybody will read that the name will be empty, and not not the value of the variable with the same name.

func2(=visibility, =frobnification_level) looks much better

Perhaps, but it’s also very odd, and potentially confusing.

># instead of this: func2(visibility=visibility, frobnification_level=frobnification_level)

># this could be used: func2(=visibility, =frobnification_level

Please, no. It takes two seconds to write it out, this will lead to hard to read code.

> This will lead to hard to read code

I’m curious to hear why you think this. What is it about duplicating the variable name that you feel makes the code clearer?

It's clearer because with the duplicated variable name, the syntax is just a special case of the general default argument syntax. The default value for the "visibility" parameter is the value of the "visibility" variable in the scope the function belongs to. Anyone who knows the default argument syntax can work that out. And even if you don't know the default argument syntax, you might be able to guess how it works by analogizing it to the similar-looking variable assignment syntax. With the new syntax, on the other hand, you have to know about it in order to understand what it does. It just adds one more thing people will have to learn about Python syntax, for, as far as I can see, a very minor benefit. The trade-off doesn't seem worth it to me, given that one of Python's USPs is its relative accessibility to newcomers.

Pretty good, but putting the "=" after the argument name seems weird to me. Looks like a mistake, and personally I'd like it if it was consistent with labeled arguments in OCaml.

Reply on news.ycombinator.com