On Thursday, September 6, 2018 at 3:11:46 PM UTC+2, Steven D'Aprano wrote: > > On Thu, Sep 06, 2018 at 12:15:46PM +0200, Anders Hovmöller wrote: > > > I have a working implementation for a new syntax which would make > > using keyword arguments a lot nicer. Wouldn't it be awesome if instead > > of: > > > > foo(a=a, b=b, c=c, d=3, e=e) > > > > we could just write: > > > > foo(*, a, b, c, d=3, e) > > > > and it would mean the exact same thing? > > No.
Heh. I did expect the first mail to be uncivil :P > > > > This would not just be shorter but would create an incentive for > > consistent naming across the code base. > > You say that as if consistent naming is *in and of itself* a good thing, > merely because it is consistent. > If it's the same thing yes. Otherwise no. > I'm in favour of consistent naming when it helps the code, when the > names are clear and relevant. Which is what I'm saying. > But why should I feel bad about failing to > use the same names as the functions I call? Yea, why would you feel bad? If you should have different names, then do. Of course. > If some library author names > the parameter to a function "a", why should I be encouraged to use > that same name *just for the sake of consistency*? > It would encourage library authors to name their parameters well. It wouldn't do anything else. > > So the idea is to generalize the * keyword only marker from function > > to also have the same meaning at the call site: everything after * is > > a kwarg. With this feature we can now simplify keyword arguments > > making them more readable and concise. (This syntax does not conflict > > with existing Python code.) > > It's certainly more concise, provided those named variables already > exist, but how often does that happen? You say 30% in your code base. > (Caveat: 30% of the cases where my super simple and stupid tool can find.) It's similar for django btw. > I disagree that f(*, page) is more readable than an explicit named > keyword argument f(page=page). > People prefer f(page) today. For some reason. That might refute your statement or not, depending on why they do it. > > My own feeling is that this feature would encourage what I consider a > code-smell: function calls requiring large numbers of arguments. Your > argument about being concise makes a certain amount of sense if you are > frequently making calls like this: > I don't see how that's relevant (or true, but let's stick with relevant). There are actual APIs that have lots of arguments. GUI toolkits are a great example. Another great example is to send a context dict to a template engine. To get benefit from your syntax, I would need to > extract out the arguments into temporary variables: > which completely cancels out the "conciseness" argument. > > First version, with in-place arguments: > 1 statement > 2 lines > 120 characters including whitespace > > Second version, with temporary variables: > 3 statements > 3 lines > 138 characters including whitespace > > > However you look at it, it's longer and less concise if you have to > create temporary variables to make use of this feature. Ok. Sure, but that's a straw man.... / Anders
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
