[Python-3000] Immutable bytes type and dbm modules

[Guido van Rossum]

On 8/6/07, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> >> If that is not acceptable, please tell me how else
> >> to fix the dbm modules.
> >
> > By fixing the code that uses them?
>
> I don't know how to do that. All implementation strategies I
> can think of have significant drawbacks.

Can you elaborate about the issues?

> > By using str8 (perhaps renamed to
> > frozenbytes and certainly stripped of its locale-dependent APIs)?
>
> Ok. So you could agree to a frozenbytes type, then? I'll add one,
> reusing the implementation of the bytes object.

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

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

> If that is done:
>
> a) should one of these be the base type of the other?

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.)

> b) should bytes literals be regular or frozen bytes?

Regular -- set literals produce mutable sets, too.

> c) is it still ok to provide a .freeze() method on
>    bytes returning frozenbytes?

I'd rather use the same kind of API used between set and frozenset:
each constructor takes the other as argument.

> d) should unicode.defenc be frozen?

Yes. It's currently a str8 isn't it? So that's already the case.

> e) should (or may) codecs return frozenbytes?

I think it would be more convenient and consistent if all APIs
returned mutable bytes and the only API that creates frozen bytes was
the frozen bytes constructor. (defenc excepted as it's a C-level API
and having it be mutable would be bad.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)