At 08:16 AM 10/15/2006 +0200, Martin v. Löwis wrote: >Greg Ewing schrieb: > >> I could see it being a lot easier to maintain e.g. C > >> compiler plugins for zc.buildout than trying to keep maintaining the > >> distutils' compiler framework indefinitely. > > > > This sounds good. We definitely need *something* with > > a more modular and better documented architecture than > > distutils. > >I definitely disagree. Why are you calling distutils non-modular? >It was designed to be modular and extensible,
No, it's designed to be subclassable and customizable. That is very different from being extensible. setuptools is somewhat extensible. zc.buildout is very extensible. But the distutils are not extensible. The documentation or lack thereof has nothing to do with it. "Modular" is a red herring. The distutils isn't a bad framework, for its time. But it was not designed with extensibility (vs. customizability) in mind. The difference between the two is that an extensible system is one that follows the same rules for extenders as it does for its core developers. For example, in the distutils, there are two ways to register commands: one for extenders, and one for core developers. (Actually, there are three, as there is yet another way added in Python 2.4 for third parties to add commands as well.) Setuptools, in contrast, has one preferred way to register commands, and it follows that way itself. Core, extenders, and third parties all use the same mechanism, so it only needs to be documented once, and the platform is more open. (For backward compatibility, of course, it has to support all the other ways that distutils does it.) Another example is compiler support. Using the techniques of setuptools and zc.buildout, we could allow anybody to write support for a particular C compiler abstraction, to e.g. support cross-compilation. They could distribute that support separately and would not have to be a distutils developer to do so. Other people could use that support for their own projects without having to bundle it in, and create the massive distutils "extensions" used by many larger projects today. The lack of ability to do this is a characteristic design limitation of the distutils (because only core developers of distutils can add new compilers, archive formats, etc.). That doesn't mean the distutils are "bad", it just means that the distutils' architecture is not an "architecture of participation". When a system's architecture is designed for collaboration (as opposed to mere customization via subclassing) it will have more collaboration happening around it. Two of the biggest Python "community" development trends in recent years, setuptools and WSGI, are good demonstrations of how a design can be used to promote collaboration, rather than balkanization. The distutils' design promotes balkanization through project-specific customization, but this can be turned around with a better design that allows more people to participate in development and extension. _______________________________________________ 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
