This past September, Phillip Eby and I discussed a variety of ZConfig issues on one list or another. Two particular issues I've thought more about, and think I'm reversing myself on them. ;-) I'm going to describe each issue in a separate email, including why I've changed my mind about them and what the consequences are for ZConfig users. Please respond to these messages if you think the proposed changes will have a negative impact on working code. "Inheritance" of the datatype when extending a section type ----------------------------------------------------------- Currently, ZConfig section types that "extend" another do not inherit the datatype of the type they extend. Phillip argued that, at least for schema extensions, the datatype should be inherited from the base schema. I thought it better to explicity request the same datatype was a better approach because of way we've been using ZConfig in some of the core packages. Each concrete section type really uses a different datatype; sharing configuration handling is accomplished only within Python. When this is the only way section types are being used, explicit is the only way to do things. While trying to create some fairly basic section types that are easy to specialize using extension, this can be less than desirable. What it boils down to is that it's difficult to create section types that can be easily specialized with a minimum of additional information in the schema; a fair bit of boilerplate is needed to change a small amount of behavior. If we add inheritance of the datatype for section types, this affects only section types that extend another section type where the "base" specifies a datatype and the derived type does not; in that case, the datatype of the base will be used instead of the "null" datatype. If the "null" datatype is needed, section types that expect it to be used can add the attribute datatype="null" to achieve the current effect (in fact, that works now). No existing unit tests are affected. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation