At 03:26 PM 4/8/2006 -0700, Guido van Rossum wrote: >On 4/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > Those are mostly libraries, not frameworks, and for the most part you're > > not *integrating* them. You're not trying to make Perforce store > > information in your database, or to put a database API over Perforce, for > > example. > >OK -- then I feel vindicated that the characterization of "most Python >programmers" as integrators doesn't apply to me. I guess I'm not a >typical Python programmer anyway. :-)
I suspect that the perspective of people like Alex, Jim, and myself is distorted by our being in consulting organizations (like Strakt, my group at Verio, and Zope corp.) where the focus is on having a toolkit that can be used to produce *multiple* applications, or configurable applications. Frameworks, in other words. Verio does a lot of "private label" hosting, where each client has significantly different business rules. Being able to have a core framework whose behavior can be significantly changed by just importing a different ruleset is a very useful concept. Indeed, the one nibble I got about possible consulting involving RuleDispatch was from another firm doing private label web services of a different sort; the same kind of needs apply. I suspect that Zope and Strakt have had similar influences shaping their perception of what a "typical Python programmer" is or does, due to the nature of consulting work. I doubt, however, that we are really "typical", in the sense that most Python programmers do not work for consulting organizations that maintain an organizational "stash" of tools used to create the same kinds of applications over and over again, with variations. They thus don't obtain any economic leverage from having tools that allow extreme customization while retaining modularity. So, approaches that may seem reasonable to you or other typical Python programmers will sometimes be objected to by folks like Alex and Jim and I, in that we will tend to think of a whole series of related applications being written with the approach, rather than just one. It probably also explains why we are usually so intently interested in "meta" features and often pioneer them; again we're thinking about writing entire families of programs. Ironically, this no longer applies to me from a career perspective; I'm not in that business any more. It frequently surprises me when I realize how easy it is to use what I think of as cheap hacks -- but which are quite adequate approaches if you intend to write only one program of the kind you are working on. :) Anyway, as to Alex's "most Python programmers are integrators" comment, I used to think it was reasonable. And it probably sounded reasonable in his organization, and in Zope's. After all, "most Python programmers" in such organizations would be a reasonable assessment. It's just not reasonable in the overall Python ecosphere. _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
