Re: [Zope-dev] Re: [Zope3-dev] ZConfig: Keytype and section type extension
On Mon, 29 Dec 2003 15:48:03 -0500 "Fred L. Drake, Jr." <[EMAIL PROTECTED]> 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] ZConfig: Keytype and section type extension
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. PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] ZConfig: Keytype and section type extension
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 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.) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] ZConfig: Keytype and section type extension
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] ZConfig: Keytype and section type extension
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 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. PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] ZConfig: Keytype and section type extension
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 > . 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: ... Currently, IIRC, the '_name' attribute of the resulting section will be '/foo/bar/baz'. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] ZConfig: Keytype and section type extension
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
> .
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 "[EMAIL PROTECTED]" % (user, host)
This can be especially useful when implementing a section type that
acts as a mapping:
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:
No need to monkey around with the weird stuff. ;-)
-Fred
--
Fred L. Drake, Jr.
PythonLabs at Zope Corporation
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] ZConfig: Keytype and section type extension
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 > > > > 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 . 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
