Barry Warsaw writes:
 > I suppose that model precludes even access to %define variables after
 > parsing.

That's right.  If you really want to control the structure of the pat
specifications, you need to deal with it explicitly; create a setting
to control the base directory, and then use os.path.join() to deal
with paths relative to that base.

 > > My usual response has been that it can already be done reasonably
 > > using something like:
 > > 
 > > %define topdir /some/path/to/the/top/of/my/tree
 > > %define logdir $topdir/log
 > > 
 > > some-logfile   $logdir/interesting.log
 > > other-logfile  $logdir/another.log
 > Which is essentially what I do now.

Have your users complained that it's too much?

 > That's the primary motivation, for sure.  The idea is that if ZConfig is
 > going to be the configuration language that Mailman3 site admins use,
 > I'd like to reduce to a minimum the number of options or lines of files
 > they need to look at, decide about, and change.  If they can simply
 > define a basedir and have all the defaults be defined in terms of that,
 > it would be a bonus.

I don't know enough about Mailman3 configuration to know how what's
being done in the config file or how many decisions the site admin
needs to deal with.  Is there something for each list?

 > I'm not sure it's useful, but the style of the schemas I've been writing
 > make all that extra stuff kind of redundant.  I actually depend on the
 > type and attribute names being the same because of the way I dig values
 > out when I post-process stuff in Python.

This sounds very strange to me.  Perhaps we should take a look at it
when we're in the same town tomorrow.


Fred L. Drake, Jr.  <fred at>
PythonLabs at Zope Corporation

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to