[Python-3000] Immutable bytes type and dbm modules
shiblon at gmail.com
Tue Aug 7 02:09:11 CEST 2007
On 8/6/07, Guido van Rossum <guido at python.org> wrote:
> 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.
But all other string literals produce immutable types:
u"" (going away, but still)
and hopefully b""
Wouldn't it be confusing to have b"" be the only mutable quote-delimited
literal? For everything else, there's bytes().
> 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/)
> Python-3000 mailing list
> Python-3000 at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-3000