[Python-Dev] The bytes type

Mike Orr sluggoster at gmail.com
Sat Jan 13 00:13:32 CET 2007


On 1/12/07, glyph at divmod.com <glyph at divmod.com> wrote:
> On 06:49 pm, python at rcn.com wrote:
>
> >I think we should draw a line in the sand and resolve not to garbage-up
> Py2.6.
> >The whole Py3.0 project is about eliminating cruft and being free of the
> >bonds of backwards compatibility.  Adding non-essential cruft to Py2.6
> >goes against that philosophy.
>
> Emotionally charged like "cruft" and "garbage" are obscuring the issue.
>
> Let's replace them with equivalents charged in the opposite direction:
>
> "I think we should draw a line in the sand and resolve not to
> compatibility-up Py2.6.  The whole Py3.0 project is about eliminating useful
> libraries and being free of the bonds of working software.  Adding
> non-essential forward-compatibility to Py2.6 goes against that philosophy."

Well put.  Not that I agree.

> The benefit (to me, and to many others) of 3.x over 2.x is the promise of
> more future maintenance, not the lack of cruft.

The benefit (to me, and to many others) of 3.x over 2.x is the promise
of getting rid of cruft.
If we're going to re-add cruft for the sake of temporary
compatibility, we may as well just stick with 2.x.  You have to take a
quantum leap sometimes or you end up working around the same old
mistakes.

For instance, getting rid of the str/unicode dichotomy would be a
wonderful thing. Then if I make a subclass of string I don't have to
think "str or unicode? or two parallel classes?"  It'll also eliminate
the possibility of a stray 8-bit string containing non-ASCII
characters from making your program go kablooie UnicodeDecodeError
when it's in a "%" or ".join()", or at least localize the problem to
ONE place (the string constructor) where it'll be in every
programmer's face and they'll all hopefully learn to handle it
consistently and not pass bad strings to other packages.

Getting rid of old-style classes would be nice too.

-- 
Mike Orr <sluggoster at gmail.com>


More information about the Python-Dev mailing list