[Python-ideas] Keyword only argument on function call
boxed at killingar.net
Sat Sep 8 06:33:26 EDT 2018
> *At* two arguments? As in this example?
> map(len, sequence)
> I'll admit that I struggle to remember the calling order of list.insert,
> I never know which of these I ought to write:
> mylist.insert(0, 1)
> mylist.insert(1, 0)
> but *in general* I don't think two positional arguments is confusing.
It’s often enough. But yes, map seems logical positional to me too but I can’t tell if it’s because I’ve programmed in positional languages for many years, or that I’m a Swedish and English native speaker. I don’t see why map would be clear and insert not so I’m guessing it has to do with language somehow.
I think it’s a good thing to be more explicit in border cases. I don’t know what the intuitions of future readers are.
> It is difficult to judge the merit of that made-up example. Real
> examples are much more convincing and informative.
Agreed. I just could only vaguely remember doing this sometimes but I had no idea what to grep for so couldn’t find a real example :P
>> Functions in real code have > 2 arguments.
> Functions in real code also have <= 2 arguments.
Yea and they are ok as is.
>> Often when reading the code the
>> only way to know what those arguments are is by reading the names of the
>> parameters on the way in, because it's positional arguments.
> I don't understand that sentence. If taken literally, the way to tell
> what the arguments are is to look at the arguments.
> I think you might mean the only way to tell the mapping from arguments
> supplied by the caller to the parameters expected by the called function
> is to look at the called function's signature.
> If so, then yes, I agree. But why is this relevent? You don't have to
> convince us that for large, complex signatures (a hint that you may
> have excessively complex, highly coupled code!) keyword arguments are
> preferable to opaque positional arguments. That debate was won long ago.
> If a complex calling signature is unavoidable, keyword args are nicer.
Good to see we have common ground here.
I won’t try to claim the code base at work doesn’t have way too many functions with way too many parameters :P It’s a problem that we are working to ameliorate but it’s also a problem my suggested feature would help with. I think we should accept that such code bases exists even when managed by competent teams. Adding one parameter is often ok but only over time you can create a problem. Refactoring to remove a substantial amount of parameters is also not always feasible or with the effort.
I think we should expect such code bases to be fairly common and be more common in closed source big business line apps. I think it’s important to help for these uses, but I’m biased since it’s my job :P
“We” did add @ for numerical work after all and that’s way more niche than the types of code bases I’m discussing here. I think you’d also agree on that point?
>> But those aren't checked.
> I don't understand this either. Excess positional arguments aren't
> silently dropped, and missing ones are an error.
Yea the arity is checked but if a refactor removes one parameter and adds another all the existing call sites are super obviously wrong if you look at the definition and the call at the same time, but Python doesn’t know.
>> To me it's similar to bracing for indent: you're telling
>> the human one thing and the machine something else and no one is checking
>> that those two are in sync.
> No, you're telling the reader and the machine the same thing.
Just like with bracing and misleading indents yes. It blames the user for a design flaw of the language.
> What's not checked is the *intention* of the writer, because it can't
That’s my point yes. And of course it can be. With keyword arguments it is. Today. If people used them drastically more the computer would check intention more.
> But again, this proposal isn't for keyword
> arguments. You don't need to convince us that keyword arguments are
I’m not convinced I’m not in fact arguing this point :P There is a big and unfair advantage positional has over kw today due to the conciseness of one over the other. My suggestion cuts down this advantage somewhat, or drastically in some cases.
>> and then be confused because a and b are flipped.
> How would they know?
How would they know what? They know it’s broken because their program doesn’t work.
How would they know the computer didn’t understand a is a and b is b when it’s blatantly obvious to a human? That’s my argument isn’t it? :P
More information about the Python-ideas