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. 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. 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. Of course you’re right that Python 3.5+ makes it possible to write that code. Python lets you define different sets of names in __dir__ and __ getattt__, or name a function sin when it actually calculates the arctangent, and it lets you pretend to take keyword arguments but treat them positionally; that doesn’t mean that doing so isn’t confusing, or that it’s a good idea. _______________________________________________ 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/EYHBE4YCIUOAFVSA67RVQATYVOLU45NX/ Code of Conduct: http://python.org/psf/codeofconduct/
