[ZODB-Dev] RFC: Pin the type of oids

Tim Peters tim at zope.com
Wed Mar 16 15:31:40 EST 2005


Object ids (oids) have no specified type now.  This is clumsy on several
counts:  various pieces of oid-slinging code attempt to "be general" in
various ways, but they're mutually inconsistent, it's often unclear exactly
what's being assumed, and code gets overly complicated by trying to cater to
generality of kinds that aren't documented, tested or used.

The kind of brain waste this leads to is well illustrated by this comment in
ZODB 3.3's serialize.py:

    # References may be:
    #
    # - A tuple, in which case they are an oid and class.
    #   In this case, just extract the first element, which is
    #   the oid
    #
    # - A list, which is a weak reference. We skip those.
    #
    # - Anything else must be an oid. This means that an oid
    #   may not be a list or a tuple. This is a bit lame.
    #   We could avoid this lamosity by allowing single-element
    #   tuples, so that we wrap oids that are lists or tuples in
    #   tuples.
    #
    # - oids may *not* be False.  I'm not sure why.

AFAIK, the only kind of oid used by anything that ships with ZODB/ZEO or
Zope is of Python type str.  BaseStorage.new_oid() generates 8-byte str
oids, and APE generates str oids of varying lengths, and that's all I'm
aware of.

Does anyone here attempt to use something other than str objects for oids?

If not, I'd like to set the concrete type of oids _in_ concrete:  if o is an
oid, then type(o) is str and len(o) > 0.

Then various code (and excruciating comments like the one above) could be
simplified accordingly.

As Jeremy Hylton noted here:

    http://www.python.org/~jeremy/weblog/030423.html

we could probably save some memory space by using Python longs for oids
instead; and, as he didn't note there (although we talked about it at the
time), we could probably save even more by using Python floats (C double)
for oids.  But that was written two years ago, and there's been no movement
in that direction since -- in reality, we've stuck with str all along, and
I'd like to stop paying for unused fuzzy generality.



More information about the ZODB-Dev mailing list