[Python-Dev] The bytes type

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