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

James Y Knight foom at fuhm.net
Tue Jan 16 10:37:11 CET 2007

On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote:

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.

There seems to be rather a lot of confusion. No one is suggesting Python 3.0 be anything less for the sake of backward compatibility. Instead, it has been suggested Python 2.6 (and possibly 2.7) be something more in order to provide for an easier upgrade path. No compromises in Python 3.0.

True: nobody is suggesting python 3.0 be anything less. But, I am
indeed suggesting that Python 3.0 be something more: I am
suggesting that people keep in mind the ease of writing of a program
which can run on both 2.5 and 3.0. And wherever possible, act so as
to preserve that ease. That may indeed involve a "compromise" in 3.0.

Given that Python 3.0 is supposed to be released in ~ 1.5 years (I
guess), around the same time as the 2.6 release, I do think 3.0 ought
to have a compatibility story that doesn't depend on 2.6. My goal
here is not to get Py3.0 to be backwards compatible, it's to get the
intersection of 2.5 and 3.0 to be large enough that I can explicitly
write code to that intersection without having to tear my hair out
and make the code incredibly gross (or worse yet, not be able to do
it at all). See previous iteritems() example.

I really don't see why there's such an urgency for removing things
IMMEDIATELY in Python 3 that don't have a suitable replacement in an
already released version. There's plenty to remove which already does
have a suitable replacement. I think the major cruft all falls into
this category (unicode strings already exist, newstyle classes
already exist, non-string exceptions already exist. The 'bytes' type
doesn't exist yet, but I expect can be introduced in such a way that
it has a useful intersection of functionality with the current method
of using 'str' to hold bytes.)

I'd like to remind everyone that 3.0 won't be the last version of
python ever released (at least, I hope!). Where Py 3.0 introduces a
brand-new way to do something, the old can be removed at a future
date. Mark it as deprecated, so that nobody will use it in new code,
and remove it a few more versions down the line. Getting rid of cruft
is great...but you can't properly call something "cruft" when it's
the only way.

Allowances for writing portable code could make a big difference in
speed of adoption. I expect Python 3.0 will be a "quantum leap", even
if people don't have to rewrite everything from scratch or fork their
codebases to keep compatibility with both releases. There's plenty to
look forward to, and I'd love to actually be able to actually use it.
But I need to be able to run 3rd party libraries, and the 3rd party
libraries must still remain compatible with earlier releases. If
those requirements are incompatible with using Py 3.0, it'll be a shame.

James

More information about the Python-Dev mailing list