This is the reasoning that speaks to me.
I also think that it might be a good idea to start compiling these very commonly suggested ideas into an index along with their motivations and reasons for rejection. I’m not sure who wants to invest time in that, but it seems like it may be a lot less work than going through the motions of re-explaining things.
Maybe we could have some PEPs that written for the purpose of being rejected and serving the above purpose?
We have a system for that: rejected PEPs. But someone has to write up the document and go through all of the effort required to get a full summary of the arguments for and against, all without the potential payoff of seeing a new feature in the language. So… who wants to champion the cause of anonymous multi-statement functions (or whatever name you want to give them), or if you prefer, champion the cause of having a document to point people to whenever they ask?
My 2 cents. Maybe “tail defs” can be a good enough solution to cover common use cases?
So that this:
def deco(f):
@wraps(f)
def wrapper(*args, **kwargs):
print('calling f')
return f(*args, **kwargs)
return wrapper
def callback(framework_arg):
pass
api_call(1, 2, callback, kw="example")
can become this:
def deco(f):
return @wraps(f) def (*args, **kwargs):
print('calling f')
return f(*args, **kwargs)
api_call(1, 2, lambda, kw="example") def ():
pass
So, basically, a single trailing anonymous def after a statement defines a function that can be referenced elsewhere in the statement.
Frankly, I don’t like how it looks, it’s quite limited and it barely saves space and keystrokes, but it helps to put things in more natural order, and conceptualy not far off from how decorators work today.
Sorry, but maybe I wasn’t clear. I’m not suggesting that anyone expect “the payoff of seeing a new feature”. The only payoff is mitigating threads like this one. So you don’t need a “champion”.
Instead of a PEP, it could simply be a wiki of commonly proposed ideas. That keeps the editing barrier small. Each idea would have its own page, which could look something like:
Main idea: Multi-line anonymous functions
Proposal details: … [variations of syntaxes, e.g.]
Links to discussion threads: …
Main arguments against: …
Main arguments for: …
Related PEPs: …
This doesn’t need much effort. You could probably lift most of these sections from this thread verbatim.
I kind of like the ability to return def(*args, **kwargs):, but I don’t think I like the rest. What if something accepts more than one function?
When is something like this ever going to pass a code review? It’s unnecessarily complex. At the very least, you need a comment summarizing what the function is doing. On the other hand, if you give the function a name, the name can stand in for the comment that you would otherwise be writing.
Also, I think it would help your case if you came up with real life examples of where you would use your proposed syntax. Even the controversial := had some nice use cases (with re.match, e.g.).
Like I said, the payoff of having a document to be able to point people to. Which means it still needs a champion - someone to take the role of writing everything up.
Go ahead! FrontPage - Python Wiki
Or are you asking someone else to do the work?
This could very nicely be handled by a slight extension of PEP 614:
@return
def _(*args, **kwargs): ...I don’t understand this antagonism. Are we okay with adding a section for commonly rejected ideas? I’ll add it when I have some time, if so.
Different people can write up different bits at different times. So no real champion.
It’s not antagonism. It’s just pointing out that anyone can talk about having something added, but unless someone wants to actually go and write up the document, it’s not going to exist. And someone has to be willing to make a document that can actually be useful, otherwise it’s not going to make any difference the next time. So… is that person you? The wiki is there, has been for years, but so far nobody’s gone and written up a page of this nature.
There doesn’t need to be consensus for someone to add a section to the wiki. All it needs is someone to (1) write the section, and (2) make people aware of it when these sorts of discussions come up. And that person needs to have the confidence to just get on and do it, not wait for consensus (they won’t get consensus, to be blunt).
Call that a “champion” or not, it still needs to be an individual, at least to get the ball rolling.
Personally, I don’t think the sort of person who starts discussions like this will be dissuaded any more effectively by a wiki page than by the information in the archives. At best, giving them one link to look at makes it slightly more likely they will actually read some of the background. But that’s just why I won’t be writing the wiki section. You seem to think differently, so go for it. You could well prove me wrong.
On the other hand, all it does is move one line, while saving one space (_ is replaced by @).
def _(*args, **kwargs):
...
return _
Sure, I don’t see the point of this at all. My reply was only meant to say there’s a much less invasive way to make something akin to return def ... happen.
I don’t think PEP 614 is about allowing keywords to be used as decorator: it’s only to allow any expression (that needs to be callable) as decorator.
You cannot call return keyword.
I suspect there’s a general phenomenon here, where the wiki gets little use first off because it’s not highly discoverable, and second because people feel they need some social “permission” to add something (despite it being a wiki), which creates a sort of inertia - people see a little-used, highly outdated wiki, and feel discouraged from getting the ball rolling.
As the person who started this discussion, I’m not sure what this is supposed to mean. What is the purpose of this forum if not to raise questions like this? If there had been a PEP for this or an easily discoverable discussion about anonymous function expressions, I would have not asked this question in the first place. But now there is a record of this discussion on this forum.
I would like this feature. I would use it. I’ve made that clear. Apparently many other people do not see sufficient motivation for it, given the constraints, and that’s fine. A lot of this boils down to a matter of taste, although I now understand that there are technical arguments against it as well. In that sense, my question has been answered. Was I wrong to ask the question in the first place?
May I humbly suggest that this thread itself serves that purpose?
The thread title is not great for this purpose, and how many are going to read through (currently) 77 posts?
You mean another record of this discussion:
You are not the first person to ask this question, nor are you the first on this forum, nor the first within the last year.
Who would sponsor me to write a PEP? I enter this with the expectation that it will be rejected but it seems like it’s the right way to be on the record once and for all. And perhaps it will only be deferred rather than rejected outright. I’m sure there’s some precedent of writing PEPs for this purpose?
You could also just update this page: AlternateLambdaSyntax - Python Wiki or create a similar one