Allow use of named-argument syntax for positional arguments?

[DNF]

One thing I frequently do is use one variable name in the documentation, and another one in the actual code. The docstring might say

crazyawsomevacationpic = enhance(awsomevacationpic)

but the code itself has

function enhance(img::Image)

because that’s much more convenient and readable inside the code. If positional variable names are part of the API, how will this work?

Another question regarding the update process:

@StefanKarpinski

It’s an extremely awkward and annoying process where the method definition in question retains the old keyword name with a nothing (or other sentinel) default value, and if a different value is passed, it manually calls depwarn to tell the user to change their code to use the new keyword argument, then it assigns the new keyword argument the appropriate value and continues on its way. I don’t think we want to encourage more of this.

Let’s say I decide to, not just change variable names, but to interchange them? I decide that, really, it makes more sense that variable x should be called y and y should be called x (I have made changes like that countless times.) That would make for a very awkward deprecation process.

@nickeubank

is that such a bad thing that the var names be part of API?

It seems really bad to me. It’s ugly, verbose, intrusive, will cause bugs, and puts an extra unnecessary burden on the developer. When I use positional arguments I deliberately want to hide the names from the caller. When I want named arguments I use kwargs.

Perhaps it could be possible to allow kwargs to also accept positional input, or something like that? Then this would be opt-in behaviour. Otherwise, if a change like this were to come, I hope it will be possible for any developer to turn it off and disallow its use.