On Fri, Jun 24, 2022 at 5:38 AM Chris Angelico <ros...@gmail.com> wrote:
>
> On Fri, 24 Jun 2022 at 16:34, Joao S. O. Bueno <jsbu...@python.org.br>
wrote:
> > On Fri, Jun 24, 2022 at 1:06 AM Chris Angelico <ros...@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.
ok.
>
> > 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.
Indeed - I don't want to argue about that, just point out
that the natural way things work in Python as is,
some of those limitations do not apply.
> > (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?
I had not thought about tp_*slots - I am just considering pure Python
code: any slot which does not alias to a visible dunder method would
map to the proxy instead, in a straightforward way for one looking
only at the Python code. Maybe some of the not mapped slots might cause
some undesired effects, and should trigger the resolve as well.
. The reason I am treating dunder attributes as special is simply because
it is what cPython does when resolving any operator with an object - any
other
attribute access, from Python code, goes through __getattribute__, but
the code path triggered by operators (+, -, ..., not, len, str) does not.
>
> > 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.
It won't work, indeed. unless there are reserved attributes that would
cause the
explicit resolve. Even if it is not given, and there is no way for a "is"
comparison,
this derives from the natural usage of the proxy, with no
exceptional behaviors
needed. The proxy is not the underlying object, after all. And not even a
convention such as
a ".__deferred_resolve__" call could solve it: the simpler path I pointed
out does not
involve "in place attribute substitution". But such a method could return
resolve and return the wrapped object, and then:
`(z := resolve(y)) is x`, would work , as well as
id(resolve(y)) == id(x), but "y"would still be the proxy <- no magic
needed,
and that is the point I wanted to bring.
A similar proxy that is used in day to day coding is a super() instance,
and I
never saw one needing `super(cls, instance) is instance` to be true.
[...]
> 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 see.
I've stepped in because that approach worked _really_ well, and I don't
think
it is _all_ that different from the proposal on the thread, and is instead
a
middleground not involving "inplace object mutation", that could make
something very
close to that proposal feasible.
Maybe I'd be more happy to see a generic way to implement "super proxys"
like these in a less hacky way, and then those could be used to build the
deferred objects
as in this proposal, than this specific implementation. In the example
project itself, Lelo, the
proxys are used to calculate the object in a subprocess, rather than just
delaying their
resolve in-thread.
>
> > 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.
Alright - but the only outstanding problem is the "is" and "id"comparison -
I am replying still because I have the impression you had not grokked
the main point: at some point, sooner or later, for any object in Python,
one of the dunder methods _will_ be called (except for identity comparison,
if one has it as an "end in itself"). Be it for printing, serializing, or
being the target of a unary or
binary operator. This path can be hooked to trigger the deferred resolve
in the proposal in this thread.
That said, I am not super in favor of it being in the language, and I will
leave
that for other people to discuss.
So, thank you for your time. Really!
js
-><-
>
> ChrisA
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/C3BED4GCY23E6IO4RDVLSIWXHGZNKF42/
Code of Conduct: http://python.org/psf/codeofconduct/
