ZConfig: Keytype and section type extension
This is the second of two messages proposing ZConfig changes. "keytype" override and section type extension --------------------------------------------- ZConfig currently requires that derived section types not specify a "keytype" attribute, used to change the interpretation of the keys. The intent is to ensure that keys defined in the base section type will still be recognized and associated with the same (or equivalent) settings for the derived type. In most cases, this is reasonable behavior. Unfortunately, it makes it tedious to specialize general base section types in some cases. Of particular interest is the case of section types that define no specific keys, but accept arbitrary keys using <key name="+" attribute="some_mapping"/> For such cases, it can be desirable to change what keys are inserted into the mapping by changing the keytype of the encosing section type. Allowing keytype overrides would not affect any existing schema, since such schema are currently rejected. One unit test would need to change; the test currently checks that specifying a keytype for a derived section type raises a SchemaError exception. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
On Mon, 2003-12-29 at 00:28, Fred L. Drake, Jr. wrote:
ZConfig currently requires that derived section types not specify a "keytype" attribute, used to change the interpretation of the keys. The intent is to ensure that keys defined in the base section type will still be recognized and associated with the same (or equivalent) settings for the derived type.
In most cases, this is reasonable behavior. Unfortunately, it makes it tedious to specialize general base section types in some cases. Of particular interest is the case of section types that define no specific keys, but accept arbitrary keys using
<key name="+" attribute="some_mapping"/>
For such cases, it can be desirable to change what keys are inserted into the mapping by changing the keytype of the encosing section type.
Allowing keytype overrides would not affect any existing schema, since such schema are currently rejected.
Since I didn't understand what keytype actually provided, even after reading the docs on it several times, I've never found a need for it <wink>. Even with the above, I'm still not 100% sure what specifying keytypes does for me, or why or when I'd want to use it. On the face of the above, if it makes it easier to use generalize base section types, then it might be a good idea. -Barry
Barry Warsaw writes:
Since I didn't understand what keytype actually provided, even after reading the docs on it several times, I've never found a need for it <wink>.
Sounds like I need to improve the docs for this. Changing the keytype allows different interpretations for keys. The only thing required of keys at the lowest level of the parser is that keys do not contain spaces. The "basic-key" datatype is used to create a case-insensitive handling to keys. Setting keytype to "identifier" would require that all keys in sections of that type be Python identifiers, and would be case-sensitive. Another keytype might allow email addresses to be used as keys: def email_address(text): user, host = text.split("@") host = host.lower() # normalize what can be normalized return "%s@%s" % (user, host) This can be especially useful when implementing a section type that acts as a mapping: <sectiontype name="email-mapping" keytype="mypkg.datatypes.email_address" datatype="mypkg.datatypes.mapping"> <key name="+" attribute="mapping"/> </sectiontype> where the additional datatype simply discards the section object and returns the key-value mapping: def mapping(section): return section.mapping
Even with the above, I'm still not 100% sure what specifying keytypes does for me, or why or when I'd want to use it. On the face of the above, if it makes it easier to use generalize base section types, then it might be a good idea.
The specific base section type I wanted to provide as part of a "standard library" of section type was just such a mapping section as described above. If both of the proposals are considered acceptable, I'd be able to provide a basic type that could be specialized to use email addresses as keys very simply: <import package="ZConfig.components.basic" /> <sectiontype name="email-mapping" keytype="mypkg.datatypes.email_address" extends="ZConfig.components.basic.mapping" /> No need to monkey around with the weird <key name="+" .../> stuff. ;-) -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
At 12:52 PM 12/29/03 -0500, Fred L. Drake, Jr. wrote:
Barry Warsaw writes:
Since I didn't understand what keytype actually provided, even after reading the docs on it several times, I've never found a need for it <wink>.
Sounds like I need to improve the docs for this.
Changing the keytype allows different interpretations for keys. The only thing required of keys at the lowest level of the parser is that keys do not contain spaces. The "basic-key" datatype is used to create a case-insensitive handling to keys. Setting keytype to "identifier" would require that all keys in sections of that type be Python identifiers, and would be case-sensitive.
That reminds me... is there any way for section *names* to be case-sensitive, or at least case-preserving? For example, if one were simulating Apache-style configuration like: <Location /Foo/bar/Baz> ... </Location> Currently, IIRC, the '_name' attribute of the resulting section will be '/foo/bar/baz'.
Phillip J. Eby writes:
That reminds me... is there any way for section *names* to be case-sensitive, or at least case-preserving? For example, if one were simulating Apache-style configuration like:
There isn't, but there was at some point. Nobody here at ZC seemed to think it useful at the time, so it was removed as a simplification. What we had was a "nametype" attribute for <sectiontype> elements; it was just another datatype function. I'd be happy to have that back if there's a real use for it. The current situation, where the conversion is coded directly in ZConfig.cfgparser, isn't very flexible. Would it suit your requirements if the name type were associated with the section type, and inherited from the base type if not specified?
Currently, IIRC, the '_name' attribute of the resulting section will be '/foo/bar/baz'.
The _name attribute is an implementation detail; use the getSectionName() method instead. I'm likely to change the _name detail just to be facetious. ;-) -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
At 01:53 PM 12/29/03 -0500, Fred L. Drake, Jr. wrote:
Phillip J. Eby writes:
That reminds me... is there any way for section *names* to be case-sensitive, or at least case-preserving? For example, if one were simulating Apache-style configuration like:
There isn't, but there was at some point. Nobody here at ZC seemed to think it useful at the time, so it was removed as a simplification.
What we had was a "nametype" attribute for <sectiontype> elements; it was just another datatype function.
I'd be happy to have that back if there's a real use for it. The current situation, where the conversion is coded directly in ZConfig.cfgparser, isn't very flexible.
Agreed. :)
Would it suit your requirements if the name type were associated with the section type, and inherited from the base type if not specified?
Yep.
Currently, IIRC, the '_name' attribute of the resulting section will be '/foo/bar/baz'.
The _name attribute is an implementation detail; use the getSectionName() method instead. I'm likely to change the _name detail just to be facetious. ;-)
Well, in that case, can we have a 'getItems()' that returns only the key-value pairs for actual attributes, and does *not* include keys for values that weren't explicitly specified in the configuration file and don't have defaults? In PEAK, the binding.Component class has this constructor currently: def fromZConfig(klass, section): """Classmethod: Create an instance from a ZConfig 'section'""" # ZConfig uses unicode for keys and defaults unsupplied values to None data = dict([(str(k),v) for k,v in section.__dict__.items() if v is not None]) if not hasattr(klass,'_name') and '_name' in data: del data['_name'] if not hasattr(klass,'_matcher') and '_matcher' in data: del data['_matcher'] return klass(**data) As you can see, I'm doing a fair amount of work in order to extract a mapping I can use as keyword arguments for the regular constructor. The standard way in PEAK to make a component configurable by ZConfig is simply to specify "whatevertype.fromZConfig" as the "datatype" in the ZConfig schema. If there were a 'getMapping' method available, the above would become something like: def fromZConfig(klass, section): """Classmethod: Create an instance from a ZConfig 'section'""" data = dict([(str(k),v) for k,v in section.getItems()] data['_name'] = section.getSectionName() return klass(**data) Unless of course the keys were strings rather than Unicode, in which case it'd be even simpler. (The issue here is that Python requires keyword arguments to be strings rather than Unicode, even though attribute names can be Unicode. ZConfig sets attributes using unicode because ZConfig schemas are XML, and therefore Unicode.)
Phillip J. Eby writes:
Well, in that case, can we have a 'getItems()' that returns only the key-value pairs for actual attributes, and does *not* include keys for values that weren't explicitly specified in the configuration file and don't have defaults?
Not a bad idea. It will require snaking information through ZConfig.matcher a bit differently, but shouldn't be particularly difficult.
Unless of course the keys were strings rather than Unicode, in which case it'd be even simpler.
Yes, and so they should be (strings rather than Unicode, that is). I've changed this in CVS. It was never intended that identifiers be Unicode; this was simply an accident of implementation.
(The issue here is that Python requires keyword arguments to be strings rather than Unicode, even though attribute names can be Unicode. ZConfig sets attributes using unicode because ZConfig schemas are XML, and therefore Unicode.)
Annoying, isn't it? Not sure it's worth fixing in Python. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
On Mon, 29 Dec 2003 15:48:03 -0500 "Fred L. Drake, Jr." <fred@zope.com> wrote:
Phillip J. Eby writes: [snip]
(The issue here is that Python requires keyword arguments to be strings rather than Unicode, even though attribute names can be Unicode. ZConfig sets attributes using unicode because ZConfig schemas are XML, and therefore Unicode.)
Annoying, isn't it? Not sure it's worth fixing in Python.
I guess this just furthers my theory that all sufficiently advanced bugs and mis-features are indiscernible from unicode. Or, more succinctly: "Blame Unicode" ;^) -Casey
On Mon, 2003-12-29 at 12:52, Fred L. Drake, Jr. wrote:
Changing the keytype allows different interpretations for keys. The only thing required of keys at the lowest level of the parser is that keys do not contain spaces. The "basic-key" datatype is used to create a case-insensitive handling to keys. Setting keytype to "identifier" would require that all keys in sections of that type be Python identifiers, and would be case-sensitive. Another keytype might allow email addresses to be used as keys:
Ah, that does sound useful! What I think the documentation needs is a kind of overview-slash-motivation-slash-real-life-examples. I'd start with an example configuration file, explain why it was designed that way, then work backwards to the schema and any components being used. That's how I tend to work anyway -- I think about what it is I want my end-users to be able to configure, i.e. I design the user interface for the .conf file first, then I figure out what the schema and component schemas I need to support that. -Barry
participants (4)
-
Barry Warsaw -
Casey Duncan -
Fred L. Drake, Jr. -
Phillip J. Eby