[Python-Dev] The bytes type (original) (raw)

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