[Python-Dev] PEP 246, Feedback Request

[Phillip J. Eby]

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.