[Python-Dev] PEP 246, Feedback Request (original) (raw)

Phillip J. Eby pje at telecommunity.com
Sun Jan 16 05:36:00 CET 2005

At 11:04 PM 1/15/05 -0500, Clark C. Evans wrote:

topic: a glossary overview: It seems that we are having difficulty with words that have shifting definitions. The next PEP edit will need to add a glossary that nails down some meanings of these words. Following are a few proposed terms/meanings.

It would also be helpful to distinguish between 1-to-1 "as a" adapters, and 1-to-many "view" adapters. There isn't a really good terminology for this, but it's important at least as it relates to type declarations.

- Any exception other than adapt.AdaptException(TypeError) causes the adapt() call to fail, and the exception to be raised to the caller of adapt(); the 'default' value is not returned in this case. - At any stage of adaption, if adapt.AdaptException(TypeError) is raised, then the adaptation process stops, as if None had been returned from each stage. - If all adaption stages return None, there are two cases. If the call to adapt() had a 'default' value, then this is returned; otherwise, an adapt.AdaptException is raised.

-1; This allows unrelated AdaptExceptions to end up being silently caught. These need to be two different exceptions if you want to support stages being able to "veto" adaptation. Perhaps you should have a distinct VetoAdaptation error to support that use case.

topic: transitivity ... proposal: ... feedback: I'm looking for warts in this plan, and verification if something like this has been done -- comments how well it works. Alternative approaches?

I'll try to think some more about this one later, but I didn't see any obvious problems at first glance.

topic: declaration (aka Guido's syntax) and intrinsic adaption overview: Guido would like his type declaration syntax (see blog entry) to be equivalent to a call to adapt() without any additional arguments. However, not all adapters should be created in the context of a declaration -- some should be created more explicitly. We propose a mechanism where an adapter factory can register itself as not suitable for the declaration syntax.

It would be much safer to have the reverse be the default; i.e., it should take special action to declare an adapter as being suitable for use with type declarations.

IOW, sticky intrinsic adapters should be the default, and volatile accessories should take an extra action to make them usable with type declarations.

feedback: This is the simplest solution I heard on the list; the word 'intrinsic' was given by Alex. Is there a better word?

Sadly, no. I've been playing with words like "extender", "mask", "personality" etc. to try and find a name for a thing you only reasonably have one of, versus things you can have many of like "accessory", "add-on", etc.

topic: adaptee (aka origin) overview: There was discussion as to how to get back to the original object from an adapter. Is this in scope of PEP 246? proposal: - we specify an adaptee property, to be optionally implemented by an adapter that provides a reference adaptee - the adapt.register method has an optional argument, 'adaptee', that defaults to False; if it is True, adapt() calls will stuff away into a weak-reference mapping from adapter to adaptee. - an adapt.adaptee(adaptor) function which returns the given adaptee for the adaptor; this first checks the weak-reference _table, and then checks for an adaptee feedback: Is this useful, worth the complexity?

This is tied directly to intrinsicness and stickyness. If you are intrinsic, you must have adaptee, so that adapt can re-adapt you safely. If you are intrinsic, you must be stateless or sticky. (Stateless can be considered an empty special case of "sticky") So, you might be able to combine a lot of these options to make the interface cleaner.

Think of it this way: if the adapter is intrinsic, it's just a "personality" of the underlying object. So you don't want to re-adapt a personality, instead you re-adapt the "original object".

But for a non-intrinsic adapter, the adapter is an independent object only incidentally related to the original adaptee, so it is now an "original object" of its own.

topic: sticky overview: Sticky adapters, that is, ones where there is only one instance per adaptee is a common use case. Should the registry of PEP 246 provide this feature?

Ideally, yes.

proposal: - the adapt.register method has an optional argument, 'sticky', that defaults to False

Make it default to whatever the 'intrinsic' setting is, because the only time you don't care for an intrinsic adapter is if the adapter is completely stateless. Or, better yet, call it 'volatile' or something and default to False. (I.e, you have to be say you're willing to have it volatile.)

If you get all of these features, it's going to come mighty close to the functionality I've written up in my PEP; the primary difference is that mine also includes a more concrete notion of "interface" and defines a way to create intrinsic adapter factories automatically, without having to write adapter classes. For volatile/accessory adapters, you still have to write the classes, but that's sort of the point of such adapters.

More information about the Python-Dev mailing list