Note that there have been a few past ideas that use a trailing block to allow some variation of a multi-line lambda syntax (either directly, or by allowing full nested function definitions):
- New syntax `Trailing Block` for constructing objects with complex structure (start of the thread @dg-pb referenced above)
- a special
@in“decorator” to replace the name-binding step in class and function definitions: PEP 403 – General purpose decorator clause (aka “@in” clause) | peps.python.org - adding
givenclauses on various simple statements: PEP 3150 – Statement local namespaces (aka “given” clause) | peps.python.org makestatements: PEP 359 – The “make” Statement | peps.python.org (this one was pretty much entirely replaced by class decorators: PEP 3129 – Class Decorators | peps.python.org)
@in would be the closest in spirit to the proposal in the current thread:
names = ['James', 'Josh', 'Michael']
@in filtered_names = [n for n in names if relevant_name(n)]
def relevant_name(name: str):
return name.startswith('J')
print(list(filtered_names))
So far, even without considering the question of whether or not they address a problem worth solving, they’ve all failed the “effort vs expressiveness” test (that is, the potential increase in language expressiveness they might offer isn’t considering to be high enough to justify the effort required to fully design, implement, document, and maintain them, including the additional cognitive burden they would place on all users of the language). And I say that as the author of two of the draft ideas on my list (they’re Deferred indefinitely because I know the answer I would get if I actually submitted them would be “No”, and I’d agree with that answer given the weak justifications those proposals currently contain)