This is exactly why I think this should be arguments-bound-on-definition proxy object, which is serialisable, thus doesn’t have inconvenient quirks of lambda, but is rather well-behaved fairly standard object.
This way, it actually introduces something new while maintaining manageable scope.
And if someone wants to use it with lambda - it supports it.
Introducing syntactic convenience to use it with lambda would be “Part 2”.
And part 1. most likely wouldn’t need a PEP.
Thus, it might actually be possible to push this through.
For late-bound argument defaults, it’s indeed a bit more complicated.
But the major challenge is on how to make the behavior of proposed syntax align with user’s intuitions, there is no technical issue that prevents the feature from being implemented.
def fn(x => []):
x.append(1) # [1] created and immediately dereferenced
x.append(2) # [2] created and immediately dereferenced
print(x) # []
I am writing a more consolidated version of the specification which will address that. It’s never dismissed.
I’d say the problem of forward typing is tackled by PEPs 649 and 749 already - just skip this case.
(and, as stated elsewhere in this thread, PEP 649 is a good example of why this is hard)
No, but I also can’t think of a reason why I’d give a 3rd party function a parameter I don’t intend for it to use. I also don’t want to be a 3rd party maintainer who now has to consider that any parameters I’m given may have side effects or mutate if I don’t forcibly evaluate them immediately.
Sidenote: if you haven’t figured out why gc is segfaulting, it’s probably at least partially because of your definition of traverse, I am pretty sure it should never allocate memory and should not observe the defer expression.
This comes down to your own opinion - which I am not going to judge.
My take is to let the idea fly. Someone out there might find a great use of it that surprise all of us.
One possibility is the observer model commonly used in web world (e.g. React and Vue).
In the original post, I stated that there needs to be a typing infrastructure to annotate arguments which must not be a DeferExpr. It’s up to the user to decide whether to adhere to typing rules - they will be warned and hence takes full responsibility of the outcome.
I think it’s confusing to call it a “zero-argument lambda”, because it’s actually a “automatically evaluated zero-argument lambda”, which is something quite different.
You’ve stripped out the aspects of the OP that exited me at this point, but since you and @dg-pb have use cases yourselves, don’t let that bother you.
I am drafting a more consolidated version of it. May I ask what concept that was stripped that could fit into your use case? I will definitely try to bring it back if possible.
I have use-cases for lazy(func, *args, **kwds), which is well behaved serialisable object. I am currently using Python implementation and was slowly working on possibility to propose it after I have arrived at final POC as implementing it in C would allow more accurate proxy and be more efficient.
If this proposal is automatically-evaluated-zero-argument-lambda-coupled-with-syntactic-conveniences, then, personally, I don’t have use cases for this.
And I would even go out of my way to object this as this would take space (mental model, namespace, syntax, etc) that I think can be used in better thought out ways.
Adding args and kwargs is trivial. It can be done in a few lines of code. I am open for both. AFAIK both will work identical for you - especially if performance is not your first priority.
I see very little divergence between what we proposed, I think it will be much better if we can collaborate on this.
