[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