On Mar 31, 2006, at 10:37 PM, Greg Ewing wrote: > Alex Martelli wrote: >> Rather, look (e.g.) at copy_reg for the typical >> kludge that's used to reimplement that crucial design pattern >> that is >> adaptation, over and over and over again. > > I don't see what copy_reg has to do with adaptation.
Funny, it seems so blindingly obvious to me, that copy_reg is nothing but an ad-hoc implementation of an adaptation registry for one special case (while all sorts of special methods perform similar tasks in a different way which has the disadvantage of being necessarily invasive on the type needing to be adapted). > What does it adapt, and to what? It adapts whatever type you're passing to copy_reg.pickle, to the protocol "being picklable". > You seem to be talking about adaptation as if it > were a general way of mapping a class to anything > else at all. We already have one of those, it's > called a dict. A dict is one fine way to implement an adaptation registry (and I believe it's what copy_reg uses for the purpose). But dicts are fine ways of implementing a huge variety of things, from sets (dicts are what we all used to implement sets before module sets.py, and later builtin type set, appeared) to classes, instances, modules, &c, via their respective __dict__s. The existence of dicts is a laughably feeble excuse to avoid having adaptation in Python's standard library, just as it would be to avoid having sets, or classes, instances, modules. > Also, design patterns don't usually have any > generic implementation, and that's okay. It's > the reason they're called *design* patterns. Sure, but as languages get higher-level, and grow powerful libraries and frameworks, the repetitive implementations of many patterns become part of the language/libraries. In machine code, circa 1950, "procedure call/return" was a design pattern, typically and repetitively implemented by placing the PC "somewhere" (that LIFO stacks were the ideal "somewheres" wasn't necessarily clear to all implementers back then) and jumping to a piece of code which ended by restoring the PC from that "somewhere". Since Fortran, languages have embodied the concept; it's not a "design pattern" any more, it's a fundamental language concept. Similarly, at a much higher level, "reactor" is a design pattern, but libraries/frameworks such as ACE and Twisted embody it as a fundamental concept. "Mock Object" is another excellent example of a DP that (in sufficiently high-level languages) can be, and is, usefully embodied in libraries. > >> just little hope that adaptation will actually >> make it into the language in any 2.* release >> (for no good reason). > > The fact that many people are unconvinced by > the case made for it so far seems like a good > reason to me. In the end, the one person that matters, regarding what gets into Python or doesn't, is Guido. When I proposed 'sum', for example, everybody else was starting to take potshots at the idea (as usual: propose *anything* on python-dev, and there will NEVER be a dearth of nay-sayers), but that mattered not a whit, because Guido on that one occasion happened to like the idea. So, the fact that (say) Eby or Martelli or the Twisted folks or the Zope folks like adaptation, and Ewing or Bicking or (etc ec) dislike it, is really a side show. The point that matters, instead, is whether GvR likes it or not. From my viewpoint, the first blocking issue is thus that GvR sees adaptation as necessarily requiring the existence of interfaces as a formal Python concept -- perhaps because that's how PyProtocols and Twisted/Zope deploy it -- and thus won't really consider it until he's blessed some specific form of interfaces. In my view of the issue, while interfaces (or supersets thereof such as protocols) are a great setting for adaptation, there is really no _need_ to formalize a specific packet of interface features to make adaptation already useful. One could have the protocol specification be a *string*, for Pete's sake -- say 'org.python.stdlib.index' to require "an integer value usable as index into a sequence", 'org.python.stdlib.pickle' to require "an object supplying methods reductor and constructor", or whatever; and even with such a minimalistic, entirely conventions-based approach, explicitly using adaptation would still be practically useful, better than the __index__ approach (because it can be noninvasive) and better than the copy_reg approach (because it does not require ad-hoc reimplementation of registries over and over again). Blocking the consideration of adaptation because the best way to formalize interfaces is not yet clear is, in my view, not a good reason. Ah well, these discussions never produce useful results; indeed, that's why I've _almost_ stopped pointing out, each and every time yet another ad-hoc (partial, and hobbled) implementation of adaptation gets adopted, how the fragmentation could be stopped and all such cases usefully unified by accepting protocol-adaptation. Once in a while, I'm moved to sing this refrain again, but thanks to the ensuing discussion I'm soon reminded that there are many more gratifying activities I could pursue instead -- repeated beating of my forehead against suitable brick walls spring to mind as being both more productive and more fun, for example. Alex _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
