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

Ron Adam rrr at ronadam.com
Sat Jan 13 01:26:10 CET 2007

Raymond Hettinger wrote:

[A.M. Kuchling]

2.6 wouldn't go changing existing APIs to begin requiring or returning the bytes type[*], of course, but extensions and new modules might use it. The premise is dubious. If I am currently maintaining a module, why would I switch to a bytes type and forgo compatibility with Py2.5 and prior? I might as well just convert it to run on Py3.0 and leave my Py2.5 code as-is for people who want to run 2.x. If I'm writing a new module, what's the point of twisting myself into knots to get it to run on both Py2.6 and Py3.0? That just makes coding harder (by limiting me to the intersection of the feature sets). 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.

Raymond

+1

For me, the thing that will make porting 2.x to 3.x code easy is to make python 3.0 as clean and organized as you can with excellent documentation. Half-way and duel-way approaches will probably not help me as much as this.

It also seems to me that instead of putting 3k warnings into 2.X, a external 3k warnings utility would work just as well. It could generate a list of ("filename", line #, "problem_string") tuples and even cross-reference an upgrade guide by using the problem_string for advice on each item. The upgrade guide could contain examples and suggestions learned from experiences at upgrading pythons library.

Most of the difficulty I have in converting programs is in finding the information I need. The actual editing is not a problem.

I think making external utilities such as these easy to use will go a long way.

Cheers, Ron

More information about the Python-Dev mailing list