Raymond Hettinger wrote:
There is a natural inclination to do the opposite. We factor code to eliminate redundancy, but that is not always a good idea with an API. The goal for code factoring is to minimize redundancy. The goal for API design is having simple parts that are easily learned and can be readily combined (i.e. the notion of an iterator algebra).
This reminds me of an early programming experience that left me with a fascination. At a time where code had to fit in a couple dozens kilobytes, I once had to make significant room in what was already very tight and terse code. Code factoring *did* provide the room in the end, but the fascinating part came before.
There was strictly no redundancy apparent at first, and finding a usable one involved contemplating code execution paths for hours until some degree of similarity was apparent between two code path families. And then, the fascinating part, was to progressively mutate both *away* from minimality of code, in order to enhance the similarity until it could be factored out.
I was impressed; in various ways. First; that the effort could be characterized quite mechanically and in a sense stupidly as finding a shortest equivalent program, while the subjective feeling was that the task exerted perceptive intelligence to the utmost. Second; by the notion that a global constraint of code minimization could map more locally to a constraint that drew code to expand. Third; that the process resulted in bottom-up construction of what's usually constructed top-down, mimicking the willful design of the latter case, eg. an API extension, as we might call it nowadays.
Cheers, BB -- "hope achieves the square root of the impossible" -- http://mail.python.org/mailman/listinfo/python-list
