[Python-Dev] PEP 246: lossless and stateless

[Phillip J. Eby]

At 10:39 AM 1/15/05 +0100, Just van Rossum wrote:
>That sounds extremely complicated as apposed to just storing the sate
>where it most logically belongs: on the adapter.

Oh, the state will be on the adapter all right.  It's just that for type 
declarations, I'm saying the system should return the *same* adapter each time.

>  And all that to work
>around a problem that I'm not convinced needs solving or even exists. At
>the very least *I* don't care about it in my use case.
>
> > Anyway, as you and I have both pointed out, sticky adaptation is an
> > important use case; when you need it, you really need it.
>
>Maybe I missed it, but was there an example posted of when "sticky
>adaptation" is needed?

No; but Glyph and I have independent use cases for them.  Here's one of 
mine: code generation from a UML or MOF model.  The model classes can't 
contain methods or data for doing code generation, unless you want to cram 
every possible kind of code generation into them.  The simple thing to do 
is to adapt them to a PythonCodeGenerator or an SQLCodeGenerator or 
what-have-you, and to do so stickily.  (Because a code generator may need 
to walk over quite a bit of the structure while keeping state for different 
things being generated.)

You *could* keep state in an external dictionary, of course, but it's much 
easier to use sticky adapters.


>It's not at all clear to me that "sticky" behavior is the best default
>behavior, even with implicit adoptation. Would anyone in their right
>mind expect the following to return [0, 1, 2, 3, 4, 5] instead of [0, 1,
>2, 0, 1, 2]?
>
>   >>> from itertools import *
>   >>> seq = range(10)
>   >>> list(chain(islice(seq, 3), islice(seq, 3)))
>   [0, 1, 2, 0, 1, 2]
>   >>>

I don't understand why you think it would.  What does islice have to do 
with adaptation?