Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
[GvR]
We're thin on contributors as it is (have you noticed how few people are submitting anything at all lately?).
The people who are contributing are doing a nice job. Also, it was nice that the change was discussed on the list.
2.6 should be extremely compatible with 2.5 by default.
Good to hear that is still a primary goal. Along the way, I worried that that sentiment had been lost and that little incompatibilities were sneaking in (iirc, the proposed transition plan for leading zeroes was headed down this path).
Does the 2to3 tool work from 2.5 or from 2.6 or does it make difference? If it works from 2.5, I'm thinking my company will make the jump all at once (after the 3.x series stabilizes, gets optimized, and key third-party packages have been migrated). I'm also expecting that some chuck of users will be left in the 2.x world and that they would like highest version to be as clean as possible (with migration features going into the category of things that don't provide them any benefit).
Thanks for zapping this. Raymond
Raymond Hettinger wrote:
Does the 2to3 tool work from 2.5 or from 2.6 or does it make difference? If it works from 2.5, I'm thinking my company will make the jump all at once (after the 3.x series stabilizes, gets optimized, and key third-party packages have been migrated).
It's not guaranteed that it will work from 2.5. The transition plan for 2to3 is: * Get your code working under python2.6 -3 without Python 3.0 deprecation warnings * Use 2to3 to migrate the code from 2.6 to 3.0 Christian
On Jan 3, 2008 1:13 PM, Raymond Hettinger <python@rcn.com> wrote:
We can always use more contributors! (See separate thread.)
2.6 should be extremely compatible with 2.5 by default.
Good to hear that is still a primary goal. Along the way, I worried that that sentiment had been lost and that little incompatibilities were sneaking in (iirc, the proposed transition plan for leading zeroes was headed down this path).
I don't recall vetting (or even seeing) that plan! Without the "-3" option, 2.6 should accept the same syntax (or a superset) as 2.5. With the "-3" flag, however, you may get warnings about stuff that changes in 3.0. I don't like that "-3" would change the accepted syntax; for that, we should use "from __future__ import ...". A hypothetical example for octal numbers: I propose that bare 2.6 accepts either 0777 and 0o777 as octal literals. If you use "python -3", you might get a warning about using 0777, although this is borderline useless since 2to3 will take care of it just fine. If people think it's worth it (I doubt it for this example) we could add "from __future__ import octal_literals" which would prohibit 0777 altogether.
The 2to3 tool works from either baseline, but there is lots of stuff it can't deal with (basically because 2to3 doesn't do type inference, and it's unlikely that it ever will). In 2.6, the "-3" warnings will help you find stuff that you should transform yourself. (Usually there is a transformation that will do the right thing in 2.6 and which will, after conversion by 2to3, continue to do the right thing in 3.0.)
I'm also expecting that some chuck of users will be left in the 2.x world and that they would like highest version to be as clean as possible (with migration features going into the category of things that don't provide them any benefit).
They could either stick with 2.5 (or at least insist on compatibility with 2.5) or use 2.6 without the "-3" flag. They might benefit from the migration features 5 years from now, and until then they shouldn't hurt. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Raymond Hettinger wrote:
Does the 2to3 tool work from 2.5 or from 2.6 or does it make difference? If it works from 2.5, I'm thinking my company will make the jump all at once (after the 3.x series stabilizes, gets optimized, and key third-party packages have been migrated).
It's not guaranteed that it will work from 2.5. The transition plan for 2to3 is: * Get your code working under python2.6 -3 without Python 3.0 deprecation warnings * Use 2to3 to migrate the code from 2.6 to 3.0 Christian
On Jan 3, 2008 1:13 PM, Raymond Hettinger <python@rcn.com> wrote:
We can always use more contributors! (See separate thread.)
2.6 should be extremely compatible with 2.5 by default.
Good to hear that is still a primary goal. Along the way, I worried that that sentiment had been lost and that little incompatibilities were sneaking in (iirc, the proposed transition plan for leading zeroes was headed down this path).
I don't recall vetting (or even seeing) that plan! Without the "-3" option, 2.6 should accept the same syntax (or a superset) as 2.5. With the "-3" flag, however, you may get warnings about stuff that changes in 3.0. I don't like that "-3" would change the accepted syntax; for that, we should use "from __future__ import ...". A hypothetical example for octal numbers: I propose that bare 2.6 accepts either 0777 and 0o777 as octal literals. If you use "python -3", you might get a warning about using 0777, although this is borderline useless since 2to3 will take care of it just fine. If people think it's worth it (I doubt it for this example) we could add "from __future__ import octal_literals" which would prohibit 0777 altogether.
The 2to3 tool works from either baseline, but there is lots of stuff it can't deal with (basically because 2to3 doesn't do type inference, and it's unlikely that it ever will). In 2.6, the "-3" warnings will help you find stuff that you should transform yourself. (Usually there is a transformation that will do the right thing in 2.6 and which will, after conversion by 2to3, continue to do the right thing in 3.0.)
I'm also expecting that some chuck of users will be left in the 2.x world and that they would like highest version to be as clean as possible (with migration features going into the category of things that don't provide them any benefit).
They could either stick with 2.5 (or at least insist on compatibility with 2.5) or use 2.6 without the "-3" flag. They might benefit from the migration features 5 years from now, and until then they shouldn't hurt. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (3)
-
Christian Heimes -
Guido van Rossum -
Raymond Hettinger