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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
