[Python-ideas] Backtick expression: similar to a shorter lambda syntax
cspealma at redhat.com
Mon Jan 21 11:22:35 EST 2019
On Sun, Jan 20, 2019 at 9: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, this “percent” property is bound to the instance, not
> to the class.
> class Example:
> percent = property(`self.v*self.v2/100`)
> And a few more examples for clarity.
> def example():
> locals()['a'] = 1
> expr = `a+1`
> return expr() # error: one variable is required
> Any variable names that exist when the backtick expression is created are
> bound to the expression, and the reference to the expression is stored
> within the expression. Names that do not exist when the expresssion is
> created must be passed in as parameters. Such names can also be passed in
> as keyword arguments. Backtick expressions are created when their scope is
> Variable names that are declared but have not been assigned to will be
> considered to exist for the purposes of the backtick expression.
> Directly calling a backtick expression as soon as it’s created is
> But this is technically allowed but discouraged, like how := works:
> Use Cases
> This can be used anywhere a lambda would feel “heavy” or long. Here are a
> few use cases where using a backtick expression would allow code to be
> significantly mote readable:
> If/else chains that would be switch statements.
> Creating decorators.
> Passing in logging hooks.
> Writing design-by-contract contracts. (See icontract on GitHub for an
> example of what DBC looks like in Python.)
> Tests and assertions.
> Additionally, the instance binding enables:
> A shorthand way to create a class that wraps an API to a better or more
> uniform code interface. Previously you’d need to make defs and @property,
> now each wrapped property and method is a single, readable line of code.
> I propose syntax highlighters show a backtick expression on a different
> background color, a lighter shade of black for a dark theme; dirty white
> for a light thing.
> I also propose the following attributes on the backtick expression.
> __str__(): the string [parameter names separated by commas] => [the string
> of the backtick expression]
> __repr__(): the original string of the backtick expression, surrounded by
> I secondarily propose that backtick expressions are only bound to their
> instances when defined within a class when the following syntax is used:
> def a = <expression>
> Now, let’s bikeshed.
I don't overall hate the idea, but I do have a few negatives to list I see.
1) While backticks are a free syntax now, they used to be a repr()
expression in older versions of Python! I'm not keen on re-using them,
it'll look real weird to us old people who remember that being common.
2) As a syntax it is pretty lightweight and could be easy to overlook. I
like that you thought of highlighters, but you can't depend on them to make
this syntax easier to notice.
Instead, it is likely that the expressions in the backticks will just blend
in with the rest of the code around them.
The one positive I see is that because there is no open and closing pair of
backticks, like parens or brackets, you can't easily nest this syntax and I
actually like how it inherently discourages or makes that impossible!
I can't say if I'm -0 or +0 but it is one of those.
> Python-ideas mailing list
> Python-ideas at python.org
> Code of Conduct: http://python.org/psf/codeofconduct/
SENIOR QUALITY ENGINEER
cspealma at redhat.com M: +1.336.210.5107
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas