[Zope-dev] Re: Mountpoints

2005-10-29 Thread Florent Guillaume
Chris McDonough wrote: This merge has been done. Since "zopectl test " no longer appears to do the right thing and I can't seem to get test.py to run anything except the entire test suite, I didn't create any new tests because I wouldn't have had the time to create tests and run them iteratively

Re: [Zope-dev] Re: Mountpoints

2005-10-21 Thread Tim Peters
[Chris McDonough] |> Note that I don't have a strong opinion about this either way but I will > note that at least Zope 2's subclass of the "zodb" config handler will > need to continue to be willing to use the section title as the database > name for backwards compatibility reasons, as people who

Re: [Zope-dev] Re: Mountpoints

2005-10-21 Thread Chris McDonough
On Fri, 2005-10-21 at 11:13 -0400, Jim Fulton wrote: > > > > Not really: a DB's database_name was introduced specifically for the > > new-in-ZODB-3.5 multidatabase feature, and has no meaning or use apart > > from its multidatabase role. That's better explained in the ZConfig > > section for th

[Zope-dev] Re: Mountpoints

2005-10-21 Thread Jim Fulton
Tim Peters wrote: [Tim Peters] I think it's worse, but mostly because a key with name "name" is also an option in _related_ sections, but with unrelated meaning. For example, if you had a nested section there it could also have specified a "name" key, which would have nothing to do with the

[Zope-dev] Re: Mountpoints

2005-10-21 Thread Tim Peters
[Tim Peters] >> I think it's worse, but mostly because a key with name "name" is also >> an option in _related_ sections, but with unrelated meaning. For >> example, if you had a nested section there it could also >> have specified a "name" key, which would have nothing to do with the >> key nam

[Zope-dev] Re: Mountpoints

2005-10-21 Thread Florent Guillaume
Tim Peters wrote: I think it's worse, but mostly because a key with name "name" is also an option in _related_ sections, but with unrelated meaning. For example, if you had a nested section there it could also have specified a "name" key, which would have nothing to do with the key named "name