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]?
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.
>> 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.
> 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?
>> (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 has to pull them out of
kwargs in order, acting as if they were positional arguments even though they
aren’t passed that way, maybe something like this:
def plot(**lwargs):
for name, values in kwargs.items():
draw(values, label=name)
>> 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.
>>> 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?
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.
_______________________________________________
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/TV7ZZ2FE3XBELVRB67SHPLSDXNGHTKBZ/
Code of Conduct: http://python.org/psf/codeofconduct/
