Skip to content

PEP 572: Add another UAEAP bullet point #729

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 10, 2018
Merged

PEP 572: Add another UAEAP bullet point #729

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
80e6e31
PEP 572: Add another UAEAP bullet point
Rosuav Jul 10, 2018
bae57b9
PEP 572: Improve the examples for the lambda prohibition
Rosuav Jul 10, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions pep-0572.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -201,6 +201,20 @@ in order to avoid ambiguities or user confusion:
ungrouped assortment of symbols and operators composed of ``:`` and
``=`` is hard to read correctly.

- Unparenthesized assignment expressions are prohibited in lambda functions.
Example::

(lambda: x := 1) # INVALID
lambda: (x := 1) # Valid, but unlikely to be useful
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. I'd much rather show an example here that is actually useful (and not obviously terrible style). E.g.

lambda line: (m := re.match(pattern, line)) and m.group(1)

Such a lambda might be useful (or be the starting point for something useful) with sorted(lines, key=...).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That one wouldn't work in Python 3 because None and str are not comparable (None < str throws an error). Something like lambda line: m.group(1) if m := re.match(pattern, line) else '' would work I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll keep the super-simple one, but also add the more useful one.

It won't really work as a sort key function, since None isn't comparable. Unfortunately, the if/else variant reads somewhat badly:

lambda line: m.group(1) if m := re.match(pattern, line) else ''

(it's confusingly similar to a comparison), and I'm not even sure how I'd write a bool-tuple version as a clean one-liner.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would work:

lambda line: (m := re.match(pattern, line)) and m.group(1) or ''

but disqualifies itself by relying on the questionable A and B or C idiom. So let's stick to what Chris just added.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't ignore this. In the back of my head, I've been trying all day to dream up a realistic example of using an assignment expression in a lambda that didn't plain suck. The problem: if a lambda is fancy enough to benefit from one, it's already so fancy that I'd almost certainly write it as a def instead. This is the closest I got to a legitimate use, and it's still on the "use a def" side to me:

lowest_terms = lambda n, d: (n // (g := gcd(n, d)), d // g)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I think here we're just looking to define the edge cases of the grammar precisely, and future generations may find a use for what the grammar allows. (As with so many other grammar edge cases.)

(x := lambda: 1) # Valid
lambda line: (m := re.match(pattern, line)) and m.group(1) # Valid

This allows ``lambda`` to always bind less tightly than ``:=``; having a
name binding at the top level inside a lambda function is unlikely to be of
value, as there is no way to make use of it. In cases where the name will be
used more than once, the expression is likely to need parenthesizing anyway,
so this prohibition will rarely affect code.

Scope of the target
-------------------

Expand Down