Home Original page

[Python-Dev] PEP 246: lossless and stateless

Phillip J. Eby pje at telecommunity.com
Sat Jan 15 02:06:22 CET 2005 
At 05:37 PM 1/14/05 -0700, Steven Bethard wrote:
>On Fri, 14 Jan 2005 19:02:52 -0500, Glyph Lefkowitz <glyph at divmod.com> wrote:
> > On Fri, 2005-01-14 at 10:07 -0500, Phillip J. Eby wrote:
> >
> > > Maybe I'm missing something, but for those interfaces, isn't it okay to
> > > keep the state in the *adapted* object here?  In other words, if PointPen
> > > just added some private attributes to store the extra data?
> >
> > I have been following this discussion with quite a lot of interest, and
> > I have to confess that a lot of what's being discussed is confusing me.
> > I use stateful adapters quite a bit - Twisted has long had a concept of
> > "sticky" adapters (they are called "persistent" in Twisted, but I think
> > I prefer "sticky").  Sometimes my persistent adapters are sticky,
> > sometimes not.  Just's example of iter() as an adaptation is a good
> > example of a non-sticky stateful adaptation, but this example I found
> > interesting, because it seems that the value-judgement of stateless
> > adapters as "good" is distorting design practices to make other
> > mistakes, just to remove state from adapters.  I can't understand why
> > PJE thinks - and why there seems to be a general consensus emerging -
> > that stateless adapters are intrinsically better.
>
>My feeling here was not that people thought that stateless adapters
>were in general intrinsically better -- just when the adaptation was
>going to be done implicitly (e.g. by type declarations).

Yes, exactly. :)


>When no state is involved, adapting an object multiple times can be
>guaranteed to produce the same adapted object, so if this happens
>implicitly, it's not a big deal.  When state is involved, _some_
>decisions have to be made, and it seems like those decisions should be
>made explicitly...

At last someone has been able to produce a concise summary of my insane 
ramblings.  :)

Yes, this is precisely the key: implicit adaptation should always return an 
adapter with the "same" state (for some sensible meaning of "same"), 
because otherwise control of an important aspect of the system's behavior 
is too widely distributed to be able to easily tell for sure what's going 
on.  It also produces the side-effect issue of possibly introducing 
transitive adaptation, and again, that property is widely distributed and 
hard to "see".

Explicit adaptation to add per-adapter state is just fine; it's only 
*implicit* "non-sticky stateful" adaptation that creates issues.  Thus, the 
PEP I'm working on focuses on making it super-easy to make stateless and 
sticky stateful adapters with a bare minimum of declarations and interfaces 
and such.
More information about the Python-Dev mailing list