Ok. I think we have identified two sorts of restrictions on the sorts of adaptations one may want to have:
`stateless' the adaptation may only provide a result which does not maintain its own state
`lossless' the adaptation preserves all information available in the original object, it may not discard state
'lossless' isn't really a good term for non-noisy. The key is that a "noisy" adapter is one that alters the precision of the information it provides, by either claiming greater precision than is actually present, or by losing precision that was present in the meaning of the data. (I.e., truncating 12.3 to 12 loses precision, but dropping the middle name field of a name doesn't because the first and last name are independent from the middle name).
Anyway, being non-noisy is only a prerequisite for interface-to-interface adapters, because they're claiming to be suitable for all possible implementations of the source interface.
'statelessness', on the other hand, is primarily useful as a guide to whether what you're building is really an "as-a" adapter. If an adapter has per-adapter state, it's an extremely good indication that it's actually a *decorator* (in GoF pattern terminology).
In GoF, an Adapter simply converts one interface to another, it doesn't implement new functionality. A decorator, on the other hand, is used to "add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects."
In fact, as far as I can tell from the GoF book, you can't *have* multiple adapter instances for a given object in their definition of the "adapter pattern". IOW, there's no per-adapter state, and their examples never suggest the idea that the adapter pattern is intended to add any per-adaptee state, either.
So, by their terminology, PEP 246 is a mechanism for dynamically selecting and obtaining *decorators*, not adapters. As if people weren't already confused enough about decorators. :)
Anyway, for type declaration, IMO statelessness is the key criterion. Type declaration "wants" to have true adapters (which can maintain object identity), not decorators (which are distinct objects from the things they add functionality to).
In other words, while calling adapt directly would allow for any adapter; using the 'Static Typing' short-cut one would be asking for adapters which are both stateless and lossless. Since __conform__ and __adapt__ would sprout two new arguments, it would make those writing adapters think a bit more about the kind of adapter that they are providing.
Unfortunately, in practice this will just lead to people ignoring the arguments, because 1) it's easier and 2) it will make their code work with type declarations! So, it won't actually produce any useful effect.
_______________________________________________ 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
