I'm not sure what else this mechanism provides; besides limiting adapters so that they cannot maintain their own state.
* No need to write adapter classes for stateless adapters; just declare methods
* Allows partial adapters to be written for e.g. "file-like" objects without creating lots of mini-interfaces and somehow relating them all
* No need to explain the concept of "interface" to somebody who just knows that the routine they're calling needs a "file" and they need to make their object "work like" a file in some way. (That is, more supportive of "programming for everybody")
* Supports using either concrete or abstract types as effective interfaces
* Doesn't require us to create explicit interfaces for the entire stdlib, if saying something's "like" an existing abstract or concrete type suffices!
* Supports abstract operations like "dict.update" that can automatically flesh out partial adapters (i.e, if you have an object with an operation "like" dict.__setitem__, then a generic dict.update can be used to complete your adaptation)
* Doesn't require anybody to write __conform__ or __adapt__ methods in order to get started with adaptation.
This is really more of a replacement for PEP 245 than 246 in some ways, but of course it relates to 246 also, since the idea would basically be to integrate it with the "global registry" described in 246. In other words, "like" declarations should populate the global registry, and in such a way that state is unified for (per-object) stateful adapters.
_______________________________________________ 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
