[Python-3000] Immutable bytes type and dbm modules

["Martin v. Löwis"]

>> I don't know how to do that. All implementation strategies I
>> can think of have significant drawbacks.
> 
> Can you elaborate about the issues?

It's a decision tree:

0. whichdb fails

1. should the DB APIs use strings or bytes as keys and values?
   Given the discussion of bsddb, I went for "bytes". I replace

   f["1"] = b"1"
 with
   f[b"1"] = b"1"

2. then,  dumbdbm fails, with TypeError: keys must be strings.
   I change __setitem__ to expect bytes instead of basestring

3. it fails with unhashable type: 'bytes' in line 166:

   if key not in self._index:

   _index is a dictionary. It's really essential that the key
   can be found quickly in _index, since this is how it finds
   the data in the database (so using, say, a linear search would
   be no option)

> Not quite. It's the least evil. I'm hoping to put off the decision.

For how long? Do you expect to receive further information that will
make a decision simpler?

> Could you start using str8 instead for now? Or is that not usable for
> a fix? (If so, why not?)

It should work, although I probably will have to fix the index file
generation in dumbdbm (either way), since it uses %r to generate
the index; this would put s prefixes into the file which won't be
understood on reading (it uses eval() to process the index, which
might need fixing, anyway)

> No. List and tuple don't inherit from each other, nor do set and
> frozenset. A common base class is okay. (We didn't quite do this for
> sets but it makes sense for Py3k to change this.)

Ok, so there would be basebytes, I assume.

>> d) should unicode.defenc be frozen?
> 
> Yes. It's currently a str8 isn't it? So that's already the case.

Right.

I think I will have to bite the bullet and use str8 explicitly,
although doing so makes me shudder.

Regards,
Martin