Cited, real implementations to study (or point an agent at) when designing or reviewing adapter-shaped code.
io.TextIOWrapper— the stdlib's flagship adapter: wraps a binary stream and exposes the text-file interface; your code readsstrwhile bytes flow underneath. docs.python.org/3/library/io.html#io.TextIOWrapperfunctools.cmp_to_key— adapts an old-style two-argument comparator to the one-argumentkey=interface; an entire adapter in function form. docs.python.org/3/library/functools.html#functools.cmp_to_keysocket.makefile()— adapts a socket to a file-like object so file-consuming code can speak to the network. docs.python.org/3/library/socket.html#socket.socket.makefile
requeststransport adapters.HTTPAdapteradapts urllib3's connection machinery to theSessionAPI, and users mount custom adapters per URL prefix — the pattern offered as a public extension point. requests.readthedocs.io/en/latest/user/advanced/#transport-adapters- SQLAlchemy dialects. Each dialect adapts one DBAPI driver's quirks (paramstyles, type handling) to a single Core interface, which is why one query API spans many databases. docs.sqlalchemy.org/en/20/dialects/
Every production adapter translates conventions, not just method names:
cmp_to_key bridges calling conventions, TextIOWrapper bridges data
models (bytes vs text), dialects bridge error hierarchies. When reviewing an
adapter, ask what happens to the adaptee's failure modes — an adapter that
only renames methods has usually left the hard mismatch in the client.