[Python-Dev] PEP 246: lossless and stateless

[Phillip J. Eby]

At 07:02 PM 1/14/05 -0500, Glyph Lefkowitz wrote:
>For the sake of argument, let's say that SegmentPen is a C type, which
>does not have a __dict__, and that PointPen is a Python adapter for it,
>in a different project.

There are multiple implementation alternatives possible here; it isn't 
necessary that the state be hidden there.  The point is that, given the 
same SegmentPen, we want to get the same PointPen each time we *implicitly* 
adapt, in order to avoid violating the "naive" developer's mental model of 
what adaptation is -- i.e. an extension of the object's state, not a new 
object with independent state.

One possible alternative implementation is to use a dictionary from object 
id to a 'weakref(ob),state' tuple, with the weakref set up to remove the 
entry when 'ob' goes away.  Adapters would then have a pointer to their 
state object and a pointer to the adaptee.  As long as an adapter lives, 
the adaptee lives, so the state remains valid.  Or, if no adapters remain, 
but the adaptee still lives, then so does the state which can be 
resurrected when a new adapter 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.

Anyway, as you and I have both pointed out, sticky adaptation is an 
important use case; when you need it, you really need it.


>This example gets to the heart of what makes interfaces useful to me -
>model/view separation.  Although one might be hard pressed to call some
>of the things I use adaptation for "views", the idea of mediated access
>from a user, or from network protocol, or from some internal code acting
>on behalf of a user is the overwhelming majority of my use-cases.

If every time you pass a "model" to something that expects a "view", you 
get a new "view" instance being created, things are going to get mighty 
confusing, mighty fast.  In contrast, explicit adaptation with 
'adapt(model,IView)' or 'IView(model)' allows you to explicitly control the 
lifecycle of the view (or views!) you want to create.

Guido currently thinks that type declaration should be implemented as 
'adapt(model,IView)'; I think that maybe it should be restricted (if only 
by considerations of "good style") to adapters that are sticky or 
stateless, reserving per-state adaptation for explicit creation via today's 
'adapt()' or 'IFoo(ob)' APIs.


>I wish I had a better suggestion, but I'm still struggling through the
>rest of the thread :).

I'll be starting work on the PEP soon, maybe I'll have a rough draft of at 
least the first few sections ready to post tonight so everybody can get 
started on ripping them to pieces.  The sooner I know about the holes, the 
sooner I can fix 'em.  Or alternatively, the sooner Guido shoots it down, 
the less work I have to do on the PEP.  :)