4 ms·

Implicit Keyword Arguments for Python

31 points by jwilk 3y ago

Georgelemental 3y ago
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.html https://rust-lang.github.io/rfcs/1682-field-init-shorthand.h...
Zanni 3y ago
I feel like Python is getting ever farther away from "Explicit is better than implicit."
- bobbylarrybobby 3y ago
  From the moment python decided `if L:` was the way to check whether a list was empty, it was explicitness was never its goal.
LeafItAlone 3y ago
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?
- paulddraper 3y ago
  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.
- rgoulter 3y ago
  > 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).
paulddraper 3y ago
I wonder if they could brand this differently. Cause you know, "explicit is better than implicit"
- lionelw 3y ago
  Other Zen of Python principles are allowed to override it. Let's say, "Readability counts".
bjornasm 3y ago
># 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.
- Svetlitski 3y ago
  > 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?
  - housecarpenter 3y ago
    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.
jmholla 3y ago
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.
- JoBrad 3y ago
  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})*
rurban 3y ago
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
- JoBrad 3y ago
  Perhaps, but it’s also very odd, and potentially confusing.
catlover76 3y ago
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.

31 points by jwilk 3y ago

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.html https://rust-lang.github.io/rfcs/1682-field-init-shorthand.h...

Zanni 3y ago

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

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

LeafItAlone 3y ago

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?

paulddraper 3y ago
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.
rgoulter 3y ago
> 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).

paulddraper 3y ago

I wonder if they could brand this differently. Cause you know, "explicit is better than implicit"

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

bjornasm 3y ago

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

Svetlitski 3y ago
> 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?
- housecarpenter 3y ago
  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.

jmholla 3y ago

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.

JoBrad 3y ago
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})*

rurban 3y ago

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

JoBrad 3y ago
Perhaps, but it’s also very odd, and potentially confusing.

catlover76 3y ago

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.