On Sat, 25 Jun 2022 at 11:56, Joao S. O. Bueno <gwid...@gmail.com> wrote:
>
>
>
> On Fri, Jun 24, 2022 at 10:05 PM Chris Angelico <ros...@gmail.com> wrote:
> >
>
> > Hmmm, I think possibly you're misunderstanding the nature of class
> > slots, then. The most important part is that they are looked up on the
> > *class*, not the instance; but there are some other quirks too:
>
>
> Sorry, no. I know how those work.
>
> > >>> class Meta(type):
> > ... def __getattribute__(self, attr):
> > ... print("Fetching %s from the metaclass" % attr)
> > ... return super().__getattribute__(attr)
> > ...
> > >>> class Demo(metaclass=Meta):
> > ... def __getattribute__(self, attr):
> > ... print("Fetching %s from the class" % attr)
> > ... return super().__getattribute__(attr)
> > ...
> > >>> x = Demo()
> > >>> x * 2
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in <module>
> > TypeError: unsupported operand type(s) for *: 'Demo' and 'int'
> >
> > Neither the metaclass nor the class itself had __getattribute__
>
> Yes - if you go back to my first e-mail on the thread, and the example code,
> that is why I am saying all along the proxy have to explicitly define all
> possible dunder methods.
This is part of the problem: "your first email" is now trying to
function as a brand new proposal, yet you're also saying that this is
part of the deferred evaluation proposal that David Mertz put forward.
Maybe this would have been less confusing if you'd simply proposed it
as a stand-alone feature, instead of answering a different post.
> No, not in Python.
> Once you have a proxy class that cover all dundeer methods to operate and
> return
> the proxied object, whoever will make use of that proxy will have it working
> in a transparent way.
> In any code that don't try direct memory access to the proxied object data.
> "Lelo" objects from that link can be freely passed around and used -
> at one point, if the object is not dropped, code has to go through one of the
> dunder methods -
> there is no way Python code can do any calculation or output the proxied
> object without doing so.
> And that experiment worked fantastically fine in doing so, better than I
> thought it would,
> and that is the only thng I am trying to say.
So your proxy has to have code for every single dunder method, and any
time a new one is devised, it has to be added? That sounds like a
maintenance nightmare.
> > The original proposal, if I'm not mistaken, was that the "deferred
> > thing" really truly would become the resulting object. That requires
> > compiler support, but it makes everything behave sanely: basic
> > identity checks function as you'd expect, there are no bizarre traps
> > with weak references, C-implemented functions don't have to be
> > rewritten to cope with them, etc, etc, etc.
>
> So, as I 've written from the first message, this would require deep suport in
> the language, which the proxy approach does not.
Yes, that proposal requires proper language support. But things that
require no language support aren't even language proposals, they're
just "hey check out this thing that can be done". Of course there's
always a way to do it in pure Python right now; the question is
really: how limited is the existing version, and how cumbersome is it
to write?
What you're proposing is VERY cumbersome - you have to enumerate
*every single dunder method* and make sure they are perfectly proxied
- and limited in a number of ways.
> > Your proposal is basically just a memoized lambda function with
> > proxying capabilities. The OP in this thread was talking about
> > deferred expressions. And my proposal was about a different way to do
> > argument defaults. All of these are *different* proposals, they are
> > not just implementations of each other. Trying to force one proposal
> > to be another just doesn't work.
>
> I am not trying to force anything. My idea was to put on the table
> a way to achieve most of the effects of the initial proposal with
> less effort. I guess this is "python-ideas" for a reason.
You're posting as a response to a different thread. The obvious
implication is that you believe your proposal to be a variant of this
one. If that's not the case, and you really just want this to stand
alone, start a new thread, and then it'll be obvious.
> And the "inplace object mutation" is a thing that, for me, looks
> specially scary in terms of complexity of the runtime.
> We had recently another lenghty thread - about splitting
> class declaration with a "forward class declaration", that after
> some lengthy discussion was dismissed because it would
> also require this.
It does have a lot of scariness, and frankly, I don't think it's worth
the cost; but it does at least have something more to offer than just
"magic lambda function that calls itself at some point".
> In my reading of the problem at hand, a "purely transparent proxy" is
> a nice approach. What one does not want is to compute the
> expression eagerly. And it does not even need to be "purely transparent"
> as __getattribute__ implementation allows for some attribute namespace
> that will allow one to query or otherwise message the underlying object.
If it doesn't need to be transparent, why not just use a perfectly
normal closure (eg a lambda function)?
> There is, of course, _another_ problem - that there are, and not few, code
> paths
> that assume that when a dunder attribute _is_ present, the object have that
> capability. So, having the proxy raise typerror or return NotImplemented
> if the proxied object don't have a certain dunder is not enough.
> (that is, one could check for "__len__" and treat the deferred object
> as a sequnece - "__len__" would be in the proxy, but not on
> the resolved object) - and yes that is a problem for this approach.
Yes. That's part of why it's non-trivial to "just proxy everything".
Proxying is not easy, and usually has limitations.
ChrisA
_______________________________________________
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/6QPEQXWZYI2VXNODXPCQ7XLX43WZU3XG/
Code of Conduct: http://python.org/psf/codeofconduct/
