[Python-ideas] Backtick expression: similar to a shorter lambda syntax

[James Lu]

Backtick expressions (now) use the same scoping and same binding rules as
other functions. The only difference is that
class Class:
  stacticmethod = `...`
  staticmethod = lambda: ...
  def instancemethod = `...` # an instancemethod that's called with self
passed in
  def property = property(`...`) # an instancemethod that's called with
self passed in

> The only thing that I can think of is that you want `foo + ^bar` to be
another way of writing lambda bar: foo + bar with some under-specified behavior
for evaluating foo and different under-specified behavior for evaluating bar
.

That is what `lambda bar: foo + ^bar` means.

A caret in a backtick expression indicates that the name after the caret is
a parameter. All names with the same name must have a caret before them.
Mandatory parameters can be passed in as keyword arguments or as positional
ones.

As for the under-specification, I've been working on an example
implementation I'll send soon for backtick expressions.

I've also been doing the "look for use cases in stdlib" thing that
Johnathan and Steve mentioned.


On Wed, Jan 23, 2019 at 3:02 AM Bruce Leban <bruce at leban.us> wrote:

> On Sun, Jan 20, 2019 at 6:43 PM James Lu <jamtlu at gmail.com> wrote:
>
>> Backtick expressions work exactly like lambdas, except that they are
>> bound to the instance they are created in every time that class is used to
>> create one. To illustrate, ...
>
>
> First, if there is a useful procedure I am strongly against using
> backticks because (1) it's been used in the past with an entirely different
> meaning and (2) it looks ugly and is not visually suggestive at all of what
> it does, especially not the subtle difference between other function
> definitions.
>
> Second, I don't understand exactly what this difference or why it would be
> useful. It would help for you to give examples comparing lambda and this
> variation.
>
> Third, you mention using ^ in "explicit" expressions to refer to
> parameters of the "created function" and I do not know what function you
> are referring to or what the exact semantics of this are. Again, a
> comparison of two expressions with and without that ^ would help. An
> expression is not a function and not all expressions are written inside
> functions. (And as to the specific proposed syntax, there already is the ^
> xor operator and the most expected meaning of ^value is ~value. just as
> the unary + and - operators corresponds to the binary operators.
>
> The only thing that I can think of is that you want `foo + ^bar` to be
> another way of writing lambda bar: foo + bar with some under-specified behavior
> for evaluating foo and different under-specified behavior for evaluating
> bar.
>
> Finally, if there is some other useful semantics for references inside a
> function definition, then I would think the best way to do that is to
> implement that, not add a new function difference. For example,
>
> lambda foo: foo + $bar
>
> def sample(foo):
>
>     return foo + $foo
>
>
> where I'm arbitrarily using $ to represent the new semantics whatever they
> are (no point in bikeshedding syntax when semantics are yet to be defined).
>
> --- Bruce
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190123/cf8f307f/attachment.html>