[Python-Dev] PEP 246: lossless and stateless (original) (raw)

Phillip J. Eby pje at telecommunity.com
Sat Jan 15 18:25:15 CET 2005

At 10:35 AM 1/15/05 +0100, Alex Martelli wrote:

On 2005 Jan 15, at 02:30, Phillip J. Eby wrote:

is requested. It's too bad Python doesn't have some sort of deallocation hook you could use to get notified when an object goes away. Oh well. For weakly referenceable objects, it does. Giving one to other objects would be almost isomorphic to making every object weakly referenceable, wouldn't it? Or am I missing something...?

I meant if there was some way to listen for a particular object's allocation, like sticking all the pointers you were interested in into a big dictionary with callbacks and having a callback run whenever an object's refcount reaches zero. It's doubtless completely impractical, however. I think we can probably live with only weak-referenceable objects being seamlessly sticky, if that's a word. :)

Actually, I've just gotten to the part of the PEP where I have to deal with stateful adapters and state retention, and I think I'm going to use this terminology for the three kinds of adapters:

The idea is to make it really easy to make any of these, but for the last category you should have to explicitly declare that you want volatility (or at least that you are willing to accept it, if the target type is not weak-referenceable).

In this way, all three kinds of adaptation may be allowed, but it takes one extra step to create a potentially "bad" adapter. Right now, people often create volatile adapters even if what they want is an extender ("sticky adapter"), because it's more work to make a functioning extender, not because they actually want volatility.

So, let's reverse that and make it easier to create extenders than it is to create volatile adapters. And, since in some cases an extender won't be possible even when it's what you want, we could go ahead and allow type declarations to make them, as long as the creator has specified that they're volatile.

Meanwhile, all three kinds of adapters should avoid accidental implicit transitivity by only adapting the "original object". (Unless, again, there is some explicit choice to do otherwise.) This makes the type declaration system a straightforward extension of the COM QueryInterface and Java casting models, where an object's "true identity" is always preserved regardless of which interface you access its operations through.

More information about the Python-Dev mailing list