> On 15 Jul 2019, at 10:23, Andrew Barnert <abarn...@yahoo.com> wrote: > >> On Jul 15, 2019, at 00:27, Anders Hovmöller <bo...@killingar.net> wrote: >> >> >>> On 14 Jul 2019, at 22:46, Andrew Barnert <abarn...@yahoo.com> wrote: >>> >>> But this doesn’t in any way help with late eval. >> >> Ah. Now I'm with you. Yes this is different but it also seems strange that >> we wouldn't just use a lambda or a function for that. That's exactly why >> they exist. > > Yes, but they’re verbose, so they hardly solve the problem here. Think about > it this way: The OP is unhappy that he had to write df[(df.price > 500) | > (df.tip >5)] instead of just df[(price > 500) | (tip >5)]. Would you really > suggest that the answer is to write df[lambda d: d.price > 500 or d.tip > 5]?
It seems a bit excessive to be upset over that added verbosity I think. But I think I'd suggest df[lambda price, tip, **_: price > 500 or tip > 5] but that's basically the same. It does scale nicer with larger expressions though. > There have been lots of proposals for general late binding, like Nick > Coghlan’s concise lambda idea, that might solve this, but none of them have > ever gotten near ready for prime time status. The OP’s proposal only covers a > much more limited set of uses, but it does seem to cover them well. Your > proposal doesn’t even attempt to solve it, so it’s not really a substitute > for the OP’s idea. Largely because I misunderstood what he wrote :) > >>> But in the case of plot(=lambda x:x*2, =lambda x:x**2), you’re saying that >>> the callee has a variable named lambda x:x*2, which is not true. What the >>> callee actually has is two unnamed positional arguments, each of which >>> comes with an extra string argument buried as its name. >> >> I disagree. The callee has a thing called that, it just isn't a variable but >> a local expression. > > An expression isn’t a name that you call something, it’s instructions to > compute something. Those are very different things. .What happens If you try > to assign a value to that expression, nonlocal it from a nested function, > etc.? The question doesn’t even make sense, because those things only make > sense for names, and expressions aren’t names. Yea ok. I don't see the relevance to any of that. We're talking about a thing that produces a dict. The keys are strings. Pretty standard stuff. >> And in any kwargs have never meant that the caller has a variable by the >> name of the callee argument so why would it here? > > Sure, today, kwargs means that the callee has a variable with that name, not > the caller. > But isn’t the whole point of your proposal that often the callee _does_ have > a name that exactly matches the caller name, so you shouldn’t have to repeat > it? That's one point. But the other is that we can get the stringly representation of the expression. It just happens that those two have an intersection when the callee expression is a simple variable name. >>> (The fact that they’re positional, but passed as if they were keyword, >>> accepted as if they were keyword, and then pulled out by iterating **kw in >>> order is also confusing.) >> >> What is positional? > > The name-value pairs are positional. If the keyword names aren’t being used > to match the values to parameter names, or to distinguish the values in any > other way, but instead to smuggle in arbitrary extra string values, how else > can you handle them but by position? Consider a concrete example, your > plot(=lambda x:x*2, =lambda x:x**2). How could plot process that? It's a syntax error. Just like normal keyword arguments: >>> def f(**kwargs): print(kwargs) ... >>> f(a=1, a=2) File "<string>", line 1 SyntaxError: keyword argument repeated >>> This might actually be a good change even on its own. The fact that the >>> docs aren’t clear on what can go in a **kw is probably not a strength of >>> the language definition but a flaw. If every implementation does the exact >>> same thing (especially if it’s been that way unchanged in every >>> implementation from 2.3 to 3.8), why not document that as the rule? >> >> Agreed! If you don't follow this you are de facto a broken python >> implementation even if the spec allows it. > > You ought to propose this idea separately. Buried in the middle of this > thread I don’t think it’s going to get noticed, but on b.p.o., or maybe its > own thread, you’ve got a good shot of convincing people. Good idea! >>>> Sure. The lack of round tripping in the standard library AST is a problem >>>> but in this case a simple AST dump is most likely fine even if it loses >>>> the users specific formatting. >>> >>> It’s not just about a lack of round tripping in the standard library AST, >>> it’s about a lack of round tripping in the implementation of the CPython, >>> PyPy, etc. compilers. If the compilers don’t have access to that >>> information internally, they can’t put it in the output. >>> >>> And I think it would be pretty confusing if spam(=eggs+cheese) gave you an >>> argument named “eggs + cheese” instead of “eggs+cheese”. And it would be >>> annoying if you were using it to define labels on a displayed graph—you >>> keep trying to tweak the code to change how the label is written and it >>> doesn’t do what you tell it to do. >> >> Agreed. But there must be a way to explicitly specify the label anyway so I >> don't think this is a deal breaker. > > Sure, you can write something like, say, spam(eggs+cheese, > label='eggs+cheese'), just as you’d do today. But then your proposal isn’t > useful for these cases. If stringifying arbitrary expressions doesn’t get you > the actual string that you’d want for things like labels, and can’t give you > late eval or any other kind of modified eval, what does it get you? Much simpler code in the 80% of common cases? The proposal didn't aim much higher I think. > I think in your main use case, where the callee and caller often have > variables with the same names and you want to be able to write plot(=x, > =xscale, =fmt) or get(=url, =data, =auth) without repeating everything twice, > it’s a nice idea. But I don’t think it really helps most of the OP’s uses. Maybe not. / Anders _______________________________________________ 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/3AEZWDIGXAJQH7WYR6C3QZFPI6CMME6F/ Code of Conduct: http://python.org/psf/codeofconduct/
