On 8/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 8/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> 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: "" r"" 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 > 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 > [email protected] > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/shiblon%40gmail.com >
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
