Luciano Ramalho writes:
A HUGE insight I learned studying Go is that Protocols should be defined near the code that CONSUMES it, and not near the code that PROVIDES it. That's exactly the opposite of how we use ABCs, or Java folks use interfaces (most of the time).
I don't see how that works for "public" protocols or ABCs in a standard library (maybe I drank too much C in my tea?) Yes, I write wrapper classes or factory functions that deal with the niggling details, even if they're only called once. And of course that's near where they're used. For example, Python's "default" 'shift_jis' codec uses an ancient version of the coded character set which errors on about half the Shift JIS files I get nowadays, so I wrote: def open_sjis(f, **kwargs): return open(f, encoding='shift_jisx0213', **kwargs) because I never remember the exact name, and Ireally don't care about the Shift JIS version, only that it's Japanese and not UTF-8. When called, the wrapper function expresses what's going on more clearly than the builtin call would. But that seems more like good programming workflow, not a protocol. Continuing the example, 'open_sjis' ended up in a small personal "tool box". Then it quickly became not a function at all when I realized that I wasn't going to ever add more "fixed" arguments, and I needed the string in many other places: SJIS = 'shift_jisx0213' *Now* that is a personal protocol, serving the same function of telling me "this code deals with a legacy Japanese encoding" and implementing it behind the scenes. But I don't see how that can be "defined close to its consumers", which are all over the place, including interactive sessions. What am I missing, and how might that be applied to Python? Steve