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?
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
