again

Add comment about use (or lack thereof) of classFactory in Zope.

application; needs work, but this should get most projects going

- add discussion of the issues surrounding keys and multikeys with
  name="+" and default values

the deprecation warning for setLocalTransaction().

This changes the behavior slightly for invalidations.  A Connection
will receive invalidations even if it didn't have any modified objects
in the transaction, e.g. db.undo() or a read-only transaction.  For
this to work, it assumes that the thread that called db.open() is the
thread that is going to use the connection.  If this isn't true, the
synch argument to db.open() can be used to disable the new feature.

note the different default hostname for an inet-address on Windows and Unix

ZServer package.

aren't needed any more

is an API shim to the logging module.  No more competing initializations!

implementation.  The configuration aspects of zLOG are about to disappear.

can import just one of eventlog and logger if desired.  This is needed for
Zope 2 to allow the main Zope configuration to only use eventlog, since the
name "logger" is used for something else.

think they're allowed to do it.  For now, just let zLOG initialize
everything; we can figure out the right way to make zLOG and logging
co-habitate later.

- don't dump everything into the "event" logger;
  use the subsystem argument to zLOG.LOG to get a specific logger
- move some comments into docstrings

constructor (potentially) changes the directory

places.

be done as late as possible (if ever)

DB._closeConnection() sets the connection's _db member to None now, under
protection of the lock it holds anyway.  At a deeper level, it's unclear
why _db keeps getting set and unset to begin with, but no time for that
now (and there are already XXX comments about it in the code).

Alas, I wasn't able to write a test that provoked the original bug in
finite time (it's a tiny timing hole), except via calling sleep() between
two lines that don't exist anymore.  Good enough.

an object as a non-negative integer.  Code trying to pass addresses to
an %x format uses positive_id(), and this avoids a Python FutureWarning
about applying %x to negative ints.  The primary difference between this
and the last stab is that positive_id() should work OK on 64-bit boxes
too.  What we really want here is C's %p format code, but in Python we
can't even reliably know the width of native addresses.

negative ints *as* negative ints when fed into %x formats.  Python 2.3
still renders them as positive ints, but spews

FutureWarning: %u/%o/%x/%X of negative int will return a signed string
               in Python 2.4 and up

to warn about the impending change.  Jim reported two instances of that
warning when running the tests on a box where addresses happen to "be
negative".  So make the addresses look positive instead (2.3 and 2.4
treat those the same, so 2.3 doesn't warn about those).

Problem:  it occurs to me now that I'm assuming addresses fit in 32
bits here.