On Fri, 24 Jun 2022 at 16:34, Joao S. O. Bueno <jsbueno@python.org.br> wrote:
On Fri, Jun 24, 2022 at 1:06 AM Chris Angelico <rosuav@gmail.com> wrote:
How much benefit would this be? You're proposing a syntactic construct for something that isn't used all that often, so it needs to be a fairly dramatic improvement in the cases where it _is_ used.
Excuse-me Who is the "you" you are referring to in the last paragraphs? (honest question)
I am not proposing this - the proto-pep is David Mertz' .
You, because you're the one who devised the version that I was responding to. His version is a much more in-depth change, although it has other issues.
I just pointed out that the language, as it is today,can handle the inner part of the deferred object, as it is.
Yes, but with the limitations that I described.
(if one just adds all possible dunder methods to your proxy example above, for example)
I still don't understand why you treat dunder methods as special here. Are you, or are you not, relying on __getattribute__? Have you taken tp_* slots into account?
Moreover, there could be an attribute namespace to deal/modify the object so - retrieving the "real" object could be trivial. (the original would actually be retrieved in _any_ operation with with the object that would make use of its dunder attributes - think "str", or "myobj + 3", since the proxy dunder would forward the operation to the wrapped object corresponding method.
Okay, here's an exercise for you. Given any function f(), ascertain whether these two calls returned the same object: x = f() y = later f() You do not know what kind of object it is. You just have to write the code that will answer the question of whether the second call to f() returned the exact same object as the first call. Calling str() on the two objects is insufficient, for instance. Calling id(y) is not going to touch any of y's dunder methods - it's just going to return the ID of the proxy, so it'll always show as different.
I am talking about this because I had played around with that "transparent future object" in the Lelo project I linked in the other e-mail, and it just works, and actually looks like magic, due to it auto-resolving whenever it is "consumed".
Right. That auto-resolving requires language support, but it means that it's not a "transparent future object". It's a real object, just one that you don't have yet. There *is no object* representing the pending state.
But like you, I don't know how useful it would actually be - so I am not the "you" from your last paragraphs - I'd not used the "lelo" proxy in production code: calling a ".result()" method, or, in these days, having an "await" expression offers something with a lot more control
Then you are not talking about the same thing at all. You're talking about a completely different concept, and you *are* the "you" from my last paragraphs.
I just wrote because it is something I made work before - and if there are indeed uses for it, the language might not even need changes to support it beyond an operator keyword.
Yes, you've done something that is broadly similar to this proposal, but like every idea, has its own set of limitations. It's easy to say "I did something different from what you did, and it doesn't require language support", but your version of the proposal introduces new problems, which is why I responded to them. ChrisA