> On 17 Jul 2019, at 22:18, Andrew Barnert <abarn...@yahoo.com> wrote: > > On Jul 17, 2019, at 12:29, Anders Hovmöller <bo...@killingar.net> wrote: >> >>>> On 17 Jul 2019, at 21:00, Andrew Barnert <abarn...@yahoo.com> wrote: >>>> >>>> On Jul 17, 2019, at 10:45, Anders Hovmöller <bo...@killingar.net> wrote: >>>> >>>>>> On 17 Jul 2019, at 19:08, Andrew Barnert <abarn...@yahoo.com> wrote: >>>>>> >>>>>> On Jul 15, 2019, at 05:25, Anders Hovmöller <bo...@killingar.net> wrote: >>>>>>>> >>>>>>>> What is positional? >>> >>>>> I didn’t come up with the plot example, so I don’t know the reason it >>>>> took two functions. But let’s say they represent functions for the y and >>>>> z values respectively for each x … >>>>> >>>>> So, how does plot know which argument is y and which is a? It can’t be by >>>>> the names, because the names are stringified lambda expressions. >>>> >>>> The stringification produces two different strings. One has one * while >>>> the other has two. >>> >>> Right, of course it can tell they’re different strings, but how can it tell >>> which string is the name of the y function and which is the name of the z >>> function? There’s nothing about having one * vs. two that tells you which >>> one is y and which is z. And of course there’s nothing about the values, >>> either. If there’s no way to tell based on the names, and no way to tell >>> based on the values, what way can there be to tell, except for the position >>> of the name-value pairs? >> >> Ah. Now I'm with you. Yes, for the purpose of the graph you'd have to >> respect the order of the kwargs, but that has been guaranteed since 3.5 so I >> don't see what the objection is really. > > OK, now we can get back to the original point: code that looks like it’s > using keyword arguments, but acts like it’s using positional arguments, is > confusing to the reader, because it’s defeating the expected purpose of > keyword arguments. Your proposal is good for your original use case, but it’s > not good for the OP’s use case if it can only solve that case by confusing > readers.
I'm not convinced it's more confusing than doing something like plot(x=y, y=x, z=w) where the leftmost of those single characters are the plot-space names, and the rightmost are the problem-space names. Just having them in the order that makes sense and always using the problem-space names seems nice to me. > In case that isn’t clear: > > As the glossary puts it, the normal use of arguments is “Arguments are > assigned to the names local variables in a function body”, and the normal use > of keyword arguments is that you can name which of those variables the > argument is for. > > When you write complex(imag=5, real=3), you know that the imag variable > inside the constructor function gets 5 (and can even guess that the imag > attribute of the constructed object will be 5). With your proposal, if you > happened to have local variables lying around for real and imag, > complex(=imag, =real) would be just as clear: the callee’s imag local gets > the value of the caller’s imag local. Sure. But that's not what happens with dict() to take the most basic example. > But in the plot example, that isn’t what’s happening. The callee y variable > gets the first argument, and z gets the second. That’s not what keywords > mean, or how they work, so it’s confusing. I don't have a problem with this. I disagree that this is "not what keywords mean, or how they work". It's not how they work in the most common case, I agree but there are other cases. / Anders PS. Sorry for the super late reply, this got buried a bit in my inbox _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RUMBTXHUV2OMJHV3336C5NAO456AKVRH/ Code of Conduct: http://python.org/psf/codeofconduct/
