What is the semantics meaning of 'object'?

Ian Kelly ian.g.kelly at gmail.com
Sun Jun 23 01:40:53 EDT 2013


On Sat, Jun 22, 2013 at 11:23 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Sat, 22 Jun 2013 22:27:10 -0600, Ian Kelly wrote:
>> I actually consider that an up side.  Sure it's inconvenient that you
>> can't delegate all such methods at once just by overriding
>> __getattribute__, but it would be more troublesome to *accidentally*
>> implement such methods because you implemented __getattribute__.
>
> It's hard to see a case where that would be a bad thing.
>
> 1) If the proxied object doesn't include __dunder__ methods, then the
> proxy will just end up up calling the default object dunder methods,
> exactly as if they weren't proxied.
>
> 2) If the proxied object does include dunders, then you generally want
> the proxy to call them, with perhaps one or two exceptions, which need to
> be overridden regardless of whether they are dunders or not.

Proxying objects is not the only use of __getattribute__.

>> And
>> then there are methods that really should not be delegated in the first
>> place, like __del__.
>
> If you're using __del__, you're probably doing something wrong :-)
>
> I suppose that __del__ is a good counter-example, but (1) hardly any
> classes use __del__, and (2) for those that do, it's *way* simpler to
> manually override __del__ in the proxy than to manually delegate every
> dunder method you care about. There are typically a lot of dunder methods
> you care about.

If you manually override __del__ in the proxy, then as far as the
garbage collector is concerned, your proxy object has a __del__ method
(even if it does nothing), and so it will be treated differently from
an object without a __del__ method.

> It is not the case that dunder methods cannot be automatically proxied
> because somebody deliberately designed Python to work that way. It's an
> accidental side-effect of the way new-style classes resolve method calls,
> due to decisions made for other reasons having nothing to do with
> delegation.

Can you elaborate or provide a link?  I'm curious to know what other
reason there could be for magic methods to behave differently from
normal methods in this regard.



More information about the Python-list mailing list