Return type of round, floor, and ceil in 2.6
I've been backporting pep 3141 to the trunk, and ran into the issue that round, math.floor, and math.ceil, which it specifies to return Integrals, currently return floats. Guido suggested privately that, to make sure that 2.6 is compatible with 2.5, they should keep returning floats for float arguments. Probably this implies that they should also keep returning float for int and long arguments. For other types, we're probably free to do whatever. Consistency across all Real implementations suggests that those 3 functions should always return their argument type. Consistency and compatibility with 3.0 suggest that they should return long for every new type we add them to. What does the list think? Thanks, Jeffrey Yasskin
Consistency and compatibility with 3.0 suggest that they should return long for every new type we add them to. What does the list think?
I think Py2.6 and Py2.5 should be treated with more respect. Will backporting this change can only cause relief or create headaches?. By definition, the Py3.0 release was supposed to be the one big incompatible set of changes. Backporting with a goal of "consistency and compatibility with 3.0" suggests that the backporters may have lost their compass. FWIW, Py2.6 hasn't been released yet and no one *has* to upgrade to it. So, if it is to have any chance of success, it needs to be a better Python than 2.5. IMO, jamming 3.0 junk into 2.x just provides an incentive to skip the upgrade altogether. In the press release for 2.6, we need to be able to say something stronger than: filled with deprecations, two ways to do everything, dozens of tiny incompatibilities all done in the name of 3.0, and runs slower. I think there ought to be a much more agressive standard for 3.0 backports:, "does the proposed backport make 2.6 more attractive?" Remember, for large code bases, upgrading is a PITA (I think Google is still running tons of code on 2.2, 2.3, and 2.4). There needs to be a good incentive for upgrading; otherwise, Py2.6 *will* fail. The specific change suggested here is possibly (and perhaps probably) harmless; however, it is part of a larger trend that is not healthy for the 2.x series. Raymond
2008/1/3, Raymond Hettinger <python@rcn.com>:
I think Py2.6 and Py2.5 should be treated with more respect. Will backporting this change can only cause relief or create headaches?. By definition, the Py3.0 release was supposed to be the one big incompatible set of changes. Backporting with a goal
Well, as issue 1689 states, the backporting was commited by Jeffrey on rev 5967 [2], so this is the time to understand if we want this or not. Personally, I'm -0. I was involved in this because of Decimal, but I can grow some __methods__ in it that can be in the trunk, unused, and when ported to 3k fit ok in the new infrastructure. Regards, [1] http://bugs.python.org/issue1689 [2] http://svn.python.org/view?rev=59671&view=rev -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
I think there ought to be a much more agressive standard for 3.0 backports:, "does the proposed backport make 2.6 more attractive?" Remember, for large code bases, upgrading is a PITA (I think Google is still running tons of code on 2.2, 2.3, and 2.4). There needs to be a good incentive for upgrading; otherwise, Py2.6 *will* fail.
Very well put, Raymond. I wonder, though, whether the appearance of a viable 3.0 will essentially kill the demand for 2.6? Bill
On Jan 3, 2008 12:33 AM, Raymond Hettinger <python@rcn.com> wrote:
Consistency and compatibility with 3.0 suggest that they should return long for every new type we add them to. What does the list think?
I think Py2.6 and Py2.5 should be treated with more respect. Will backporting this change can only cause relief or create headaches?. By definition, the Py3.0 release was supposed to be the one big incompatible set of changes. Backporting with a goal of "consistency and compatibility with 3.0" suggests that the backporters may have lost their compass.
Whoa. Jeffrey is mostly backporting new stuff (such as numbers.py) which doesn't introduce incompatibilities. The backporting is intended to make 2.6 more attractive by allowing developers to do some of the painful work of porting to 3.0 while staying on 2.6.
FWIW, Py2.6 hasn't been released yet and no one *has* to upgrade to it. So, if it is to have any chance of success, it needs to be a better Python than 2.5. IMO, jamming 3.0 junk into 2.x just provides an incentive to skip the upgrade altogether. In the press release for 2.6, we need to be able to say something stronger than: filled with deprecations, two ways to do everything, dozens of tiny incompatibilities all done in the name of 3.0, and runs slower.
Watch your words, Raymond. I don't mind personally, but you run the risk of discouraging contributors by slamming down on them with with words like "jamming 3.0 junk into 2.x", and that's the last thing we want to happen. We're thin on contributors as it is (have you noticed how few people are submitting anything at all lately?). 2.6 should be extremely compatible with 2.5 by default. Its main attraction should be that it is an important stepping stone in the upgrade path from 2.{2,3,4,5} to 3.0 -- going straight from 2.5 to 3.0 will be much harder than going from 2.5 to 2.6, doing a bunch of work while on 2.6, and then going to 3.0. The initial step from 2.5 to 2.6 should be very simple and painless. There will still be plenty of good stuff in 2.6 to encourage folks to upgrade who have no need for 3.0 (yet) -- this is the backported 3.0 stuff that doesn't create incompatibilities (like abc.py and numbers.py).
I think there ought to be a much more agressive standard for 3.0 backports:, "does the proposed backport make 2.6 more attractive?" Remember, for large code bases, upgrading is a PITA (I think Google is still running tons of code on 2.2, 2.3, and 2.4). There needs to be a good incentive for upgrading; otherwise, Py2.6 *will* fail.
The incentive for upgrading will be "you can reach 3.0 easier via 2.6" and perhaps "the latest version of 3rd party software X runs best on 2.6".
The specific change suggested here is possibly (and perhaps probably) harmless; however, it is part of a larger trend that is not healthy for the 2.x series.
Where do you see evidence for a larger trend? I agree that a trend towards making 2.6 less compatible with 2.5 would be a mistake, but I don't think I see it happening. Also, Facundo wrote:
Well, as issue 1689 states, the backporting was commited by Jeffrey on rev 5967 [2], so this is the time to understand if we want this or not.
This is a problem. Right now, in the trunk, math.float(1) returns 1, where it should return 1.0 for compatibility with 2.5. Jeffrey, can you fix this and similar incompatibilities you introduced? -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido, -On [20080103 19:38], Guido van Rossum (guido@python.org) wrote:
We're thin on contributors as it is (have you noticed how few people are submitting anything at all lately?).
When you say this are you talking about code or contributions all over the project, e.g. documentation? Is there a reason that it thinned out? I'm asking since I never really dove into the Python project much aside from using Python here and there, but I seem to get a career using Python almost full-time so perhaps there are things I, and I am sure others, can step up to help out. -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ A frightened mental vortex we will be, a Sun we seek, a Sun we flee...
We're getting a fair number of doc contributions, especially since the docs were converted from Latex to ReST, and especially since the start of the GHOP project. My main gripe is with code contributions to Py3k and 2.6; Py3k is mostly done by a handful of people, and almost nobody is working much on 2.6. --Guido On Jan 3, 2008 11:05 AM, Jeroen Ruigrok van der Werven <asmodai@in-nomine.org> wrote:
Guido,
-On [20080103 19:38], Guido van Rossum (guido@python.org) wrote:
We're thin on contributors as it is (have you noticed how few people are submitting anything at all lately?).
When you say this are you talking about code or contributions all over the project, e.g. documentation?
Is there a reason that it thinned out?
I'm asking since I never really dove into the Python project much aside from using Python here and there, but I seem to get a career using Python almost full-time so perhaps there are things I, and I am sure others, can step up to help out.
-- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ A frightened mental vortex we will be, a Sun we seek, a Sun we flee...
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Thu, Jan 03, 2008 at 11:15:04AM -0800, Guido van Rossum wrote: -> We're getting a fair number of doc contributions, especially since the -> docs were converted from Latex to ReST, and especially since the start -> of the GHOP project. -> -> My main gripe is with code contributions to Py3k and 2.6; Py3k is -> mostly done by a handful of people, and almost nobody is working much -> on 2.6. What needs to be done with 2.6? I'm happy to review patches, although even were commit access on offer I'm too scatterbrained to do a good job of it. Incidentally, I'm planning to set up an SVK repos containing the GHOP doc patches; that way they can stay sync'ed with 2.6 work. I'd be happy to do the same thing with reviewed-and-probably-OK patches, although I don't know if repository proliferation is a generally good idea ;). --titus
2008/1/3, Titus Brown <titus@caltech.edu>:
What needs to be done with 2.6? I'm happy to review patches, although even were commit access on offer I'm too scatterbrained to do a good job of it.
We have 109 patches open for 2.5 [1], and 118 patches open for 2.6 [2]. Note that the added number is less than the sum, as some patchs are marked for both versions, and even some are marked as 3.0 also. And of course I'm not counting bugs, here, just issues marked as patch. I deliberately work only on the trunk (except for some issues regarding Decimal), because of the balance Guido talked about. Regards, [1] http://www.taniquetil.com.ar/cgi-bin/pytickets.py?nropag=0&priority=0&severity=0&component=0&version=2&keyword=2 [2] http://www.taniquetil.com.ar/cgi-bin/pytickets.py?nropag=0&priority=0&severity=0&component=0&version=1&keyword=2 -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
On Thu, Jan 03, 2008 at 05:48:25PM -0200, Facundo Batista wrote: -> 2008/1/3, Titus Brown <titus@caltech.edu>: -> -> > What needs to be done with 2.6? I'm happy to review patches, although -> > even were commit access on offer I'm too scatterbrained to do a good job -> > of it. -> -> We have 109 patches open for 2.5 [1], and 118 patches open for 2.6 [2]. The question is, is reviewing patches a good place to contribute? Also, if I (and others) could have a "core mentor" with commit access, that might streamline things. As it is, I am worried that patch reviews will pass through the ether without leaving a visible trace; that's OK and understandable, but it's demotivating. (I've had a very good experience with Georg and documentation commits for GHOP.) cheers, --titus
The question is, is reviewing patches a good place to contribute? Also, if I (and others) could have a "core mentor" with commit access, that might streamline things. As it is, I am worried that patch reviews will pass through the ether without leaving a visible trace; that's OK and understandable, but it's demotivating.
Keep posting to this list, if you think a patch can be accepted. If you think a patch should be rejected, it would probably be easiest if you just close it.
(I've had a very good experience with Georg and documentation commits for GHOP.)
You can only find out what feedback you get on code reviews when you actually start reviewing :-) I would like to promise guaranteed responses to you, but I feel that recently, I found that I cannot keep up with such promises. But I would hope that some of the active committers will "quickly" commit patches when they find that your review leaves nothing to be added. Regards, Martin
2008/1/3, Titus Brown <titus@caltech.edu>:
The question is, is reviewing patches a good place to contribute? Also, if I (and others) could have a "core mentor" with commit access, that might streamline things. As it is, I am worried that patch reviews will
For a core_mentor/padawan (wink) relationship to work ok, you need that both parties get interested on working on the same stuff. For example, Mark has been working a lot on Decimal, and I have been a merely supervisor and committer of his changes, and we could generate successfully a good patch flow. I don't think that this can be successful when both parties tries to handle wide portions of Python, but I'd love to see a lot of this small sparks of productivity. Now thinking of how to produce this relationships, I think that I will change my approach to the issues. I'll start to be more aggressive when reviewing a patch or bug. Aggressive in the sense of asking/commenting/proposing even if I don't get the full grasp of the issue. This could lead to a better interaction on the mid/long term, even if in the short it appears to increase the noise a little. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Now thinking of how to produce this relationships, I think that I will change my approach to the issues. I'll start to be more aggressive when reviewing a patch or bug. Aggressive in the sense of asking/commenting/proposing even if I don't get the full grasp of the issue. This could lead to a better interaction on the mid/long term, even if in the short it appears to increase the noise a little.
I think this is exactly right. If you don't understand a certain aspect, don't hesitate to ask. Maybe the submitter doesn't understand either, and it was a flaw in the patch, or maybe there is a real issue, and the submitter forgot to comment it properly - it's always the submitter's fault if you don't understand :-) Regards, Martin
On Jan 3, 2008 11:40 AM, Titus Brown <titus@caltech.edu> wrote:
On Thu, Jan 03, 2008 at 11:15:04AM -0800, Guido van Rossum wrote: -> We're getting a fair number of doc contributions, especially since the -> docs were converted from Latex to ReST, and especially since the start -> of the GHOP project. -> -> My main gripe is with code contributions to Py3k and 2.6; Py3k is -> mostly done by a handful of people, and almost nobody is working much -> on 2.6.
What needs to be done with 2.6? I'm happy to review patches, although even were commit access on offer I'm too scatterbrained to do a good job of it.
IMO the main issue with 2.6 is not handling bugs and patches but backporting 3.0 stuff. There's a spreadsheet somewhere that shows there's a huge amount of work to be done: http://spreadsheets.google.com/ccc?key=pCKY4oaXnT81FrGo3ShGHGg (if you can't access it, try the published version: http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGg )
Incidentally, I'm planning to set up an SVK repos containing the GHOP doc patches; that way they can stay sync'ed with 2.6 work. I'd be happy to do the same thing with reviewed-and-probably-OK patches, although I don't know if repository proliferation is a generally good idea ;).
IMO patches should just be applied to the trunk ASAP. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
-> > Incidentally, I'm planning to set up an SVK repos containing the GHOP -> > doc patches; that way they can stay sync'ed with 2.6 work. I'd be happy -> > to do the same thing with reviewed-and-probably-OK patches, although I -> > don't know if repository proliferation is a generally good idea ;). -> -> IMO patches should just be applied to the trunk ASAP. (We're waiting on contributor forms for the GHOP students. That's on my TODO list, too.) --titus
On Jan 3, 2008, at 2:15 PM, Guido van Rossum wrote:
My main gripe is with code contributions to Py3k and 2.6; Py3k is mostly done by a handful of people, and almost nobody is working much on 2.6.
For those of us still using Python 2.4 and earlier, it's hard to be motivated to worry about Python 3.0, no matter how wonderful it looks. (It doesn't help that my own available time appears to decrease daily with the kids and all.) Python 2.6 seems to be entirely targeted at people who really want to be on Python 3, but have code that will need to be ported. I certainly don't view it as interesting in it's own right. -Fred -- Fred Drake <fdrake at acm.org>
On Thu, Jan 03, 2008 at 02:49:27PM -0500, Fred Drake wrote: -> On Jan 3, 2008, at 2:15 PM, Guido van Rossum wrote: -> > My main gripe is with code contributions to Py3k and 2.6; Py3k is -> > mostly done by a handful of people, and almost nobody is working much -> > on 2.6. -> -> For those of us still using Python 2.4 and earlier, it's hard to be -> motivated to worry about Python 3.0, no matter how wonderful it -> looks. (It doesn't help that my own available time appears to -> decrease daily with the kids and all.) -> -> Python 2.6 seems to be entirely targeted at people who really want to -> be on Python 3, but have code that will need to be ported. I -> certainly don't view it as interesting in it's own right. 3k and 26 are, however, the only place where we can propose new features -- which makes it the place for cleanup and additional testing, as well as backwards-incompatible bug fixes... --titus
Titus, Having a "core mentor" would be great but do they really have time for that? I've been lucky at finding people in #python / #python-dev) that can answer development inquiries (or at least verify something is or is not a bug). With respects to the bug tracker, when I select Search and Python 2.6, I retrieved 208 open bugs. At a quick glance, I found two that were windows, but not tagged appropriately. If it's worthwhile, I can spend some time this evening browsing the list of current 2.6 bugs to see if there are any duplicates, collisions, etc. Joseph Armbruster On Jan 3, 2008 2:53 PM, Titus Brown <titus@caltech.edu> wrote:
On Thu, Jan 03, 2008 at 02:49:27PM -0500, Fred Drake wrote: -> On Jan 3, 2008, at 2:15 PM, Guido van Rossum wrote: -> > My main gripe is with code contributions to Py3k and 2.6; Py3k is -> > mostly done by a handful of people, and almost nobody is working much -> > on 2.6. -> -> For those of us still using Python 2.4 and earlier, it's hard to be -> motivated to worry about Python 3.0, no matter how wonderful it -> looks. (It doesn't help that my own available time appears to -> decrease daily with the kids and all.) -> -> Python 2.6 seems to be entirely targeted at people who really want to -> be on Python 3, but have code that will need to be ported. I -> certainly don't view it as interesting in it's own right.
3k and 26 are, however, the only place where we can propose new features -- which makes it the place for cleanup and additional testing, as well as backwards-incompatible bug fixes...
--titus _______________________________________________ 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/josepharmbruster%40gmail.c...
Joseph Armbruster wrote:
With respects to the bug tracker, when I select Search and Python 2.6, I retrieved 208 open bugs. At a quick glance, I found two that were windows, but not tagged appropriately. If it's worthwhile, I can spend some time this evening browsing the list of current 2.6 bugs to see if there are any duplicates, collisions, etc.
The bug tracker is an issue and in my opinion a development hindrance, too. It contains almost 1,400 bugs, about 450 w/o a target version and about 400 more bugs with a target version <= 2.4. The bug tracker was discussed two threads "Bug tracker: meaning of resolution keywords" and "1324 bugs in the tracker" lately. I don't want to repeat the arguments here but Brett's answer http://permalink.gmane.org/gmane.comp.python.devel/90137 is worth reading. Christian
From another angle, there are a lot of "easy" fixes/patches/updates to be done to Python, but I'll be damned if I can figure out which ones are easy meat, or complex, or likely to touch a nerve. Having someone experienced to quickly give an opinion is invaluable. (I'm an overconfident loudmouth, so I don't mind posting to this list, but I
On Thu, Jan 03, 2008 at 03:24:16PM -0500, Joseph Armbruster wrote: -> Having a "core mentor" would be great but do they really have time for -> that? I've been lucky at finding people in #python / #python-dev) that can -> answer development inquiries (or at least verify something is or is not a -> bug). Again, IMO as someone on the lunatic fringe of core development (i.e. I'm a happy spectator, but I'm too busy to actually get much done): Mentoring coders may not be a traditional route for hard-core OSS developers, but it sure can be effective, as I've found with GHOP. For example, many core Python developers can save an outsider hours of effort by simply and quickly outlining the issues involved in a particular patch or coding effort. Having actual committers involved is especially good, because they can evaluate whether or not a patch is likely to be accepted, potentially cutting out more hours of effort; and they can directly commit patches, leading to the very important gratification of an actual commit. think python-dev is pretty intimidating for people new to the hurly burly of OSS development.) As I've said in other responses in this thread, I'm not sure how to make it happen, but I'm leaning towards asking the active GHOP mentors to try to extend the GHOP mentoring effort into a general python-love effort. We've got a good group of experienced people, and it's been a pretty friendly list IMO. cheers, --titus
On Jan 3, 2008 5:24 PM, Titus Brown <titus@caltech.edu> wrote:
On Thu, Jan 03, 2008 at 03:24:16PM -0500, Joseph Armbruster wrote: -> Having a "core mentor" would be great but do they really have time for -> that? I've been lucky at finding people in #python / #python-dev) that can -> answer development inquiries (or at least verify something is or is not a -> bug).
Again, IMO as someone on the lunatic fringe of core development (i.e. I'm a happy spectator, but I'm too busy to actually get much done):
Mentoring coders may not be a traditional route for hard-core OSS developers, but it sure can be effective, as I've found with GHOP.
For example, many core Python developers can save an outsider hours of effort by simply and quickly outlining the issues involved in a particular patch or coding effort. Having actual committers involved is especially good, because they can evaluate whether or not a patch is likely to be accepted, potentially cutting out more hours of effort; and they can directly commit patches, leading to the very important gratification of an actual commit.
I know I am happy to do stuff that way when I have time. I know I am just currently drowning under work for the first half of 2008 (PyCon, my own Py3K stuff, and thesis).
From another angle, there are a lot of "easy" fixes/patches/updates to be done to Python, but I'll be damned if I can figure out which ones are easy meat, or complex, or likely to touch a nerve. Having someone experienced to quickly give an opinion is invaluable. (I'm an overconfident loudmouth, so I don't mind posting to this list, but I think python-dev is pretty intimidating for people new to the hurly burly of OSS development.)
I hope that when it comes time to change the issue tracker schema we can have a reasonable difficulty rating. That should also help for Python bug days since we can say "look at easy bugs if you don't really know C stuff, look at medium if you know C, and tackle hard if you want to dive into the nitty-gritty".
As I've said in other responses in this thread, I'm not sure how to make it happen, but I'm leaning towards asking the active GHOP mentors to try to extend the GHOP mentoring effort into a general python-love effort. We've got a good group of experienced people, and it's been a pretty friendly list IMO.
Could work. Don't know if another list is really needed; couldn't python-dev handle general questions? But then again, that is what the tracker is for. -Brett
On Thu, Jan 03, 2008 at 02:49:27PM -0500, Fred Drake wrote:
Python 2.6 seems to be entirely targeted at people who really want to be on Python 3, but have code that will need to be ported. I certainly don't view it as interesting in its own right.
The bulk of the *language* changes in 2.6 are driven by 3.0, but the abstract base class support is fairly significant even if you don't plan on going to 3.0. There are a fair number of new features in the library: Bill's new SSL code, collections.namedtuple, the signal handling/event loop fix, the new floating point features dealing with infinities and NaNs. None are earth-shattering to me personally, but for the right audience they might be very compelling. So far I view 2.6 as a relatively cautious release, like 2.3. (That assessment may change once I research the numeric changes that just went in.) Most of the action has been in the surrounding tools, like the new documentation format and the adoption of Roundup. --amk
On Jan 3, 2008 11:49 AM, Fred Drake <fdrake@acm.org> wrote:
For those of us still using Python 2.4 and earlier, it's hard to be motivated to worry about Python 3.0, no matter how wonderful it looks. (It doesn't help that my own available time appears to decrease daily with the kids and all.)
Oh, just get rid of the kids. :-)
Python 2.6 seems to be entirely targeted at people who really want to be on Python 3, but have code that will need to be ported. I certainly don't view it as interesting in it's own right.
It will be though -- it will have genuine new features -- yes, backported from 3.0, but new features nevertheless, and in a compatible fashion. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On 3-Jan-08, at 1:07 PM, Guido van Rossum wrote:
On Jan 3, 2008 11:49 AM, Fred Drake <fdrake@acm.org> wrote:
Python 2.6 seems to be entirely targeted at people who really want to be on Python 3, but have code that will need to be ported. I certainly don't view it as interesting in it's own right.
It will be though -- it will have genuine new features -- yes, backported from 3.0, but new features nevertheless, and in a compatible fashion.
I think that there are still tons of people like me for whom 3.0 is still a future concern that is too big to devote cycles to at the moment, but are still very much interested in improving the 2.x series (which improves 3.0) at the same time. I've been inspired by this thread to start working on a few 2.6 items that I had in mind, starting with http://bugs.python.org/ issue1663329 , which mostly just needed documentation and cleanup (now done). Question: should patches include edits to whatsnew.rst, or is the committer responsible for adding a note? -Mike
On Fri, Jan 04, 2008 at 11:45:34PM -0800, Mike Klaas wrote:
Question: should patches include edits to whatsnew.rst, or is the committer responsible for adding a note?
It's OK to submit or commit patches that don't update whatsnew.rst; I'll notice the checkin and decide whether to include the change. --amk
Mike Klaas wrote:
Question: should patches include edits to whatsnew.rst, or is the committer responsible for adding a note?
A patch should contain edits for Misc/NEWS. Patches without documentation and NEWS updates costs the committer more time and reduces the likelihood of a commit. Even a perfect patch costs several minutes of our life time. The patch must be reviewed, applied, compiled, the entire unit test suite must pass and finally it must be committed and the issues needs to be closed, too. Christian
On Jan 5, 2008 2:36 PM, Christian Heimes <lists@cheimes.de> wrote:
Mike Klaas wrote:
Question: should patches include edits to whatsnew.rst, or is the committer responsible for adding a note?
A patch should contain edits for Misc/NEWS. Patches without documentation and NEWS updates costs the committer more time and reduces the likelihood of a commit.
Even a perfect patch costs several minutes of our life time. The patch must be reviewed, applied, compiled, the entire unit test suite must pass and finally it must be committed and the issues needs to be closed, too.
Several minutes?! The average "perfect" patch costs me more like between half an hour and an hour. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
On Jan 5, 2008 2:36 PM, Christian Heimes <lists@cheimes.de> wrote:
A patch should contain edits for Misc/NEWS. Patches without documentation and NEWS updates costs the committer more time and reduces the likelihood of a commit.
Even a perfect patch costs several minutes of our life time. The patch must be reviewed, applied, compiled, the entire unit test suite must pass and finally it must be committed and the issues needs to be closed, too.
Several minutes?! The average "perfect" patch costs me more like between half an hour and an hour.
QOTW. I think this excerpt should show up in the new developer area. --Scott David Daniels Scott.Daniels@Acm.Org
Christian Heimes schrieb:
Mike Klaas wrote:
Question: should patches include edits to whatsnew.rst, or is the committer responsible for adding a note?
A patch should contain edits for Misc/NEWS.
And documentation changes should include proper "versionchanged" or "versionadded" tags if it's not just a bug fix.
Patches without documentation and NEWS updates costs the committer more time and reduces the likelihood of a commit.
Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
-On [20080103 20:39], Guido van Rossum (guido@python.org) wrote:
My main gripe is with code contributions to Py3k and 2.6; Py3k is mostly done by a handful of people, and almost nobody is working much on 2.6.
You don't put the bar high for newbies on the Python project eh? :) I am assumign that most of those contributions code-wise need a fair amount of knowledge of Python's internals? -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Mayoi nagara demo ii aruki dashite...
Jeroen Ruigrok van der Werven wrote:
You don't put the bar high for newbies on the Python project eh? :)
I am assumign that most of those contributions code-wise need a fair amount of knowledge of Python's internals?
It's neither impossible nor too hard to get involved. I got from "haven't done serious C coding in years" to "Python core developer with full svn access" in less than 9 months. OK, I've more than 5 years of Python experience but you don't need it to contribute. You can start by updating or enhancing the existing documentation, writing new docs and tutorials or updating the unit test suite. New tests need to be written and existing test should be ported to the new unit test module. Large parts of Python are written *in* Python. You don't need to be a C coder to contribute. For example you can give a C coder a hand by writing documentation and unit tests for the C coder. This way the C coder can concentrate on the C code and you can enhance your unit testing Fu. :) Christian
On Thu, Jan 03, 2008 at 09:55:44PM +0100, Christian Heimes wrote: -> Jeroen Ruigrok van der Werven wrote: -> > You don't put the bar high for newbies on the Python project eh? :) -> > -> > I am assumign that most of those contributions code-wise need a fair amount of -> > knowledge of Python's internals? -> -> It's neither impossible nor too hard to get involved. I got from -> "haven't done serious C coding in years" to "Python core developer with -> full svn access" in less than 9 months. OK, I've more than 5 years of -> Python experience but you don't need it to contribute. -> -> You can start by updating or enhancing the existing documentation, -> writing new docs and tutorials or updating the unit test suite. New -> tests need to be written and existing test should be ported to the new -> unit test module. As far as I am aware, we/GHOP have patches for all of the tests in 2.6 => unittest or doctest. They have not all been applied yet, but that will come soon. Speaking as someone with a few years experience in Python and quite a bit of C knowledge, it is not at all easy to come up with a way to dive into the core code. For GHOP, it was a bit of a struggle to come up with tasks; I ended up with three main sources of tasks: - a blog post asking people about their favorite poorly documented module; - the 3.0 spreadsheet and some grepping, to figure out which tests still needed to be ported over to unittest/doctest; - a test coverage analysis to figure out which modules were largely untested; A parent of a GHOP student asked us if we could somehow come up with a suggested task list for new contributors (not just GHOP students). While this could be a lot of work, I think the contributions from GHOP to core in the areas of test coverage, test porting, and module documentation indicate that this kind of outreach may be very effective. If you have ideas on how to keep such a task list fresh and up-to-date as well as populated with good, simple tasks, I'm interested in hearing from you! cheers, --titus
On Jan 3, 2008 12:17 PM, Jeroen Ruigrok van der Werven <asmodai@in-nomine.org> wrote:
-On [20080103 20:39], Guido van Rossum (guido@python.org) wrote:
My main gripe is with code contributions to Py3k and 2.6; Py3k is mostly done by a handful of people, and almost nobody is working much on 2.6.
You don't put the bar high for newbies on the Python project eh? :)
I am assuming that most of those contributions code-wise need a fair amount of knowledge of Python's internals?
Actually, it goes all over the place. Some things (like doing "-3" warnings for uses of .keys() that assume the result is a list) required wizard level knowledge; other things are fairly simple. For example, abc.py and _abcoll.py were backported successfully by someone who was learning on the job. Backporting pure Python code often isn't that hard. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
My main gripe is with code contributions to Py3k and 2.6; Py3k is mostly done by a handful of people, and almost nobody is working much on 2.6.
There's a great Duke Ellington quote: ``Without a deadline, baby, I wouldn't do nothing.'' The SSL code in 2.6 is out-of-date (buggy) compared to the code in the 3.x branch, for instance. I just haven't prioritized backporting the 3.x fixes, because there's no schedule for 2.6. Bill
On Jan 3, 2008 10:37 AM, Guido van Rossum <guido@python.org> wrote:
Well, as issue 1689 states, the backporting was commited by Jeffrey on rev 5967 [2], so this is the time to understand if we want this or not.
This is a problem. Right now, in the trunk, math.float(1) returns 1, where it should return 1.0 for compatibility with 2.5. Jeffrey, can you fix this and similar incompatibilities you introduced?
Whoops! I've committed r59707 to fix math.{floor,ceil}. Let me know if you find any other problems. ... Hmm. I've also changed the behavior of round(2.5). I'll change that back tomorrow morning. I haven't seen any answers to the original question. It looks like Decimal is decided by 2.5 too: return a float from everything. Rational, being a completely new type, is up to you guys, but because new support for the conversion routines seems to be rare, it's probably best to have it return floats too. -- Namasté, Jeffrey Yasskin
2008/1/4, Jeffrey Yasskin <jyasskin@gmail.com>:
I haven't seen any answers to the original question. It looks like Decimal is decided by 2.5 too: return a float from everything. Rational, being a completely new type, is up to you guys, but because new support for the conversion routines seems to be rare, it's probably best to have it return floats too.
Sorry, I didn't understand this parragraph. Do you mean that the response in the following case is of type "float"?:
round(decimal.Decimal("2.5")) 3.0
Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
On Jan 4, 2008 4:40 AM, Facundo Batista <facundobatista@gmail.com> wrote:
2008/1/4, Jeffrey Yasskin <jyasskin@gmail.com>:
I haven't seen any answers to the original question. It looks like Decimal is decided by 2.5 too: return a float from everything. Rational, being a completely new type, is up to you guys, but because new support for the conversion routines seems to be rare, it's probably best to have it return floats too.
Sorry, I didn't understand this parragraph.
Do you mean that the response in the following case is of type "float"?:
round(decimal.Decimal("2.5")) 3.0
Yes. -- Namasté, Jeffrey Yasskin
On Jan 4, 2008 11:14 AM, Jeffrey Yasskin <jyasskin@gmail.com> wrote:
On Jan 4, 2008 4:40 AM, Facundo Batista <facundobatista@gmail.com> wrote:
Do you mean that the response in the following case is of type "float"?:
round(decimal.Decimal("2.5")) 3.0
Yes.
That seems a little peculiar to me: wouldn't it be more natural to have round(Decimal_instance) return another Decimal? Mark
2008/1/4, Mark Dickinson <dickinsm@gmail.com>:
That seems a little peculiar to me: wouldn't it be more natural to have round(Decimal_instance) return another Decimal?
Yes. Now I find that now round() delegates its work to __round__: http://docs.python.org/dev/library/functions.html#round This doc says that round() "Return the floating point value x rounded to n digits after the decimal point.". It don't specify if its binary or decimal floating point, ;) Feel free to create an issue and assign to me if you think that this should be done. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
On Jan 4, 2008 8:37 AM, Facundo Batista <facundobatista@gmail.com> wrote:
2008/1/4, Mark Dickinson <dickinsm@gmail.com>:
That seems a little peculiar to me: wouldn't it be more natural to have round(Decimal_instance) return another Decimal?
Yes.
Now I find that now round() delegates its work to __round__:
http://docs.python.org/dev/library/functions.html#round
This doc says that round() "Return the floating point value x rounded to n digits after the decimal point.".
It don't specify if its binary or decimal floating point, ;)
Feel free to create an issue and assign to me if you think that this should be done.
In 3.0, round() of a Decimal should return an int if invoked with 1 arg, a Decimal if invoked with 2. Similar for round() of a float. round() of an int can always return an int. In 2.6, round() should always return a float, regardless of the type of the first arg or the arg count, for best compatibility with 2.5. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Jan 4, 2008 12:13 AM, Jeffrey Yasskin <jyasskin@gmail.com> wrote:
On Jan 3, 2008 10:37 AM, Guido van Rossum <guido@python.org> wrote:
Well, as issue 1689 states, the backporting was commited by Jeffrey on rev 5967 [2], so this is the time to understand if we want this or not.
This is a problem. Right now, in the trunk, math.float(1) returns 1, where it should return 1.0 for compatibility with 2.5. Jeffrey, can you fix this and similar incompatibilities you introduced?
Whoops! I've committed r59707 to fix math.{floor,ceil}. Let me know if you find any other problems. ... Hmm. I've also changed the behavior of round(2.5). I'll change that back tomorrow morning.
Looks like in Python 2.6, round(0.5) right now returns 0.0, whereas in 2.5, it returns 1.0. I think it should return 1.0, for best compatibility with Python 2.5.
I haven't seen any answers to the original question. It looks like Decimal is decided by 2.5 too: return a float from everything.
Right.
Rational, being a completely new type, is up to you guys, but because new support for the conversion routines seems to be rare, it's probably best to have it return floats too.
I think the pre-3.0 rule should be: round(), math.floor(), math.ceil() *always* return a float. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido> Looks like in Python 2.6, round(0.5) right now returns 0.0, Guido> whereas in 2.5, it returns 1.0. Guido> I think it should return 1.0, for best compatibility with Python Guido> 2.5. And for best compatibility with everything else! <0.5 wink> Skip
On Jan 4, 2008 8:58 AM, <skip@pobox.com> wrote:
Guido> Looks like in Python 2.6, round(0.5) right now returns 0.0, Guido> whereas in 2.5, it returns 1.0.
Guido> I think it should return 1.0, for best compatibility with Python Guido> 2.5.
And for best compatibility with everything else! <0.5 wink>
Should I round that to 0 whole winks or 1 whole wink? Rounding 0.5 to 0 is a new fad, called round-to-even, or statistician's rounding. Read http://en.wikipedia.org/wiki/Rounding . It's a standard, and more correct when doing statistical calculations. That's why we've chosen it for Python 3.0. But it should not bleed into Python 2.6. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido> Rounding 0.5 to 0 is a new fad, called round-to-even, or Guido> statistician's rounding. Read Guido> http://en.wikipedia.org/wiki/Rounding . It's a standard, and Guido> more correct when doing statistical calculations. That's why Guido> we've chosen it for Python 3.0. But it should not bleed into Guido> Python 2.6. Thanks for the pointer. Given that it's been an ASTM standard since 1940 and apparently in fairly common use since the early 1900s, I wonder why it's not been more widely used in the past in programming languages. Skip
On Jan 4, 2008 9:25 AM, <skip@pobox.com> wrote:
Guido> Rounding 0.5 to 0 is a new fad, called round-to-even, or Guido> statistician's rounding. Read Guido> http://en.wikipedia.org/wiki/Rounding . It's a standard, and Guido> more correct when doing statistical calculations. That's why Guido> we've chosen it for Python 3.0. But it should not bleed into Guido> Python 2.6.
Thanks for the pointer. Given that it's been an ASTM standard since 1940 and apparently in fairly common use since the early 1900s, I wonder why it's not been more widely used in the past in programming languages.
Because programming language designers rarely are statisticians? -- --Guido van Rossum (home page: http://www.python.org/~guido/)
[skip@pobox.com]
Thanks for the pointer. Given that it's [round-to-even[ been an ASTM standard since 1940 and apparently in fairly common use since the early 1900s, I wonder why it's not been more widely used in the past in programming languages.
Because "add a half and chop" was also in wide use for even longer, is also (Wikipedia notwithstanding) part of many standards (for example, the US IRS requires it if you do your taxes under the "round to whole dollars" option), and-- probably the real driver --is a little cheaper to implement for "normal sized" floats. Curiously, round-to-nearest can be unboundedly more expensive to implement in some obscure contexts when floats can have very large exponents (as they can in Python's "decimal" module -- this is why the proposed decimal standard allows operations like "remainder-near" to fail if applied to inputs that are "too far apart": http://www2.hursley.ibm.com/decimal/daops.html#footnote.8 The "secret reason" is that it can be unboundedly more expensive to determine the last bit of the quotient (to see whether it's even or odd) than to determine an exact remainder).
On Jan 4, 2008 11:31 AM, Tim Peters <tim.peters@gmail.com> wrote:
[skip@pobox.com]
Thanks for the pointer. Given that it's [round-to-even[ been an ASTM standard since 1940 and apparently in fairly common use since the early 1900s, I wonder why it's not been more widely used in the past in programming languages.
Because "add a half and chop" was also in wide use for even longer, is also (Wikipedia notwithstanding) part of many standards (for example, the US IRS requires it if you do your taxes under the "round to whole dollars" option), and-- probably the real driver --is a little cheaper to implement for "normal sized" floats. Curiously, round-to-nearest can be unboundedly more expensive to implement in some obscure contexts when floats can have very large exponents (as they can in Python's "decimal" module -- this is why the proposed decimal standard allows operations like "remainder-near" to fail if applied to inputs that are "too far apart":
http://www2.hursley.ibm.com/decimal/daops.html#footnote.8
The "secret reason" is that it can be unboundedly more expensive to determine the last bit of the quotient (to see whether it's even or odd) than to determine an exact remainder).
Wow. Do you have an opinion as to whether we should adopt round-to-even at all (as a default)? -- --Guido van Rossum (home page: http://www.python.org/~guido/)
[Tim]
Because "add a half and chop" was also in wide use for even longer, is also (Wikipedia notwithstanding) part of many standards (for example, the US IRS requires it if you do your taxes under the "round to whole dollars" option), and-- probably the real driver --is a little cheaper to implement for "normal sized" floats. Curiously, round-to-nearest can be unboundedly more expensive to implement in some obscure contexts when floats can have very large exponents (as they can in Python's "decimal" module -- this is why the proposed decimal standard allows operations like "remainder-near" to fail if applied to inputs that are "too far apart":
http://www2.hursley.ibm.com/decimal/daops.html#footnote.8
The "secret reason" is that it can be unboundedly more expensive to determine the last bit of the quotient (to see whether it's even or odd) than to determine an exact remainder).
[Guido]
Wow. Do you have an opinion as to whether we should adopt round-to-even at all (as a default)?
Yes: yes :-) There's no need to be unduly influenced by "some obscure contexts when floats can have very large exponents", and the decimal standard already weasels its way out of the bad consequences then. I should clarify that the standard "allows" relevant operations to fail then in the same sense the IRS "allows" you to pay your taxes: it's not just allowed, failure is required. Nearest/even is without doubt the rounding method experts want most often, which is half of what makes it the best default. The other half is that, while newbies don't understand why experts would want it, the underlying reasons nevertheless act to spare newbies from subtle numeric problems. As to what the numerically innocent /expect/, "(at least) all of the above" is my only guess. For example (and here I'm making up a very simple one to show the essence), under the Windows native Python "%.0f" % 2.5 produces "3", while under glibc-based implementations (including Cygwin's Python) it produces "2". Over the years I've seen "bug reports" filed against both outcomes. According to the 754 standard, the glibc-based result (nearest/even rounding) is correct, and the Microsoft result is wrong. Why fight it? All the HW float operations do nearest/even rounding now too (by default), ditto the decimal module, and I'm secretly grateful the people who decided on those were downright eager to oppose Excel's numerically innocent implementors ;-)
On Jan 5, 2008 4:20 PM, Tim Peters <tim.peters@gmail.com> wrote:
[Guido]
Wow. Do you have an opinion as to whether we should adopt round-to-even at all (as a default)?
Yes: yes :-)
Thanks for the suggestion, Tim. Here's a new proposed patch to the pep. It still allows type-defined half-rounding behavior so that Decimal can follow the current context. I'll submit it tomorrow unless there are significant objections. Index: pep-3141.txt =================================================================== --- pep-3141.txt (revision 59739) +++ pep-3141.txt (working copy) @@ -205,8 +205,12 @@ def __round__(self, ndigits:Integral=None): """Rounds self to ndigits decimal places, defaulting to 0. - If ndigits is omitted or None, returns an Integral, otherwise - returns a Real. Rounds half toward even. + If ndigits is omitted or None, returns an Integral, + otherwise returns a Real, preferably of the same type as + self. Types may choose which direction to round half. For + example, float rounds half toward even, and Decimal rounds + it according to the current context. + """ raise NotImplementedError @@ -428,10 +432,14 @@ least Integral ``>= x``. 4. ``__round__(self)``, called from ``round(x)``, which returns the - Integral closest to ``x``, rounding half toward even. There is also - a 2-argument version, ``__round__(self, other)``, called from - ``round(x, y)``, which should return a Real. + Integral closest to ``x``, rounding half as the type chooses. + ``float`` will change in 3.0 to round half toward even. There is + also a 2-argument version, ``__round__(self, ndigits)``, called + from ``round(x, ndigits)``, which should return a Real. +In 2.6, ``math.floor``, ``math.ceil``, and ``round`` will continue to +return floats. + Because the ``int()`` conversion implemented by ``float`` (and by ``decimal.Decimal``) is equivalent to but less explicit than ``trunc()``, let's remove it. (Or, if that breaks too much, just add a -- Namasté, Jeffrey Yasskin
On Jan 4, 2008 1:31 PM, Tim Peters <tim.peters@gmail.com> wrote:
Curiously, round-to-nearest can be unboundedly more expensive to implement in some obscure contexts when floats can have very large exponents (as they can in Python's "decimal" module -- this is why the proposed decimal standard allows operations like "remainder-near" to fail if applied to inputs that are "too far apart":
Just to be clear, this problem doesn't come up in round(), right? Because in round(), you just test the evenness of the last digit computed. There is never a need to compute extra digits just to perform the test. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC
[Tim]
Curiously, round-to-nearest can be unboundedly more expensive to implement in some obscure contexts when floats can have very large exponents (as they can in Python's "decimal" module -- this is why the proposed decimal standard allows operations like "remainder-near" to fail if applied to inputs that are "too far apart":
[Daniel Stutzbach]
Just to be clear, this problem doesn't come up in round(), right?
Right! It's unique to 2-argument mod-like functions.
Because in round(), you just test the evenness of the last digit computed. There is never a need to compute extra digits just to perform the test.
Right, round has to compute the last (retained) digit in any case. For mod(x, y) (for various definitions of mod), the result is x - n*y (for various ways of defining an integer n), and there exist efficient ways to determine the final result without learning anything about the value of n in the process. For example, consider Python's pow(10, 100000000, 136). It goes very fast to compute the answer 120, but internally Python never develops any idea about the value of n such that 10**100000000 - 136*n = 120. Is n even or odd? "remainder-near" can care, but there's no efficient way I know of to find out (dividing a 100-million digit integer by 136 to find out isn't efficient ;-)).
On Jan 4, 2008 8:50 AM, Guido van Rossum <guido@python.org> wrote:
On Jan 4, 2008 12:13 AM, Jeffrey Yasskin <jyasskin@gmail.com> wrote:
On Jan 3, 2008 10:37 AM, Guido van Rossum <guido@python.org> wrote:
Well, as issue 1689 states, the backporting was commited by Jeffrey on rev 5967 [2], so this is the time to understand if we want this or not.
This is a problem. Right now, in the trunk, math.float(1) returns 1, where it should return 1.0 for compatibility with 2.5. Jeffrey, can you fix this and similar incompatibilities you introduced?
Whoops! I've committed r59707 to fix math.{floor,ceil}. Let me know if you find any other problems. ... Hmm. I've also changed the behavior of round(2.5). I'll change that back tomorrow morning.
Looks like in Python 2.6, round(0.5) right now returns 0.0, whereas in 2.5, it returns 1.0.
I think it should return 1.0, for best compatibility with Python 2.5.
I haven't seen any answers to the original question. It looks like Decimal is decided by 2.5 too: return a float from everything.
Right.
Rational, being a completely new type, is up to you guys, but because new support for the conversion routines seems to be rare, it's probably best to have it return floats too.
I think the pre-3.0 rule should be: round(), math.floor(), math.ceil() *always* return a float.
These rollbacks, and that of pow(-1,.5)==1j are submitted as r59731. Keep letting me know what else I broke. -- Namasté, Jeffrey Yasskin
On Jan 5, 2008 12:56 AM, Jeffrey Yasskin <jyasskin@gmail.com> wrote:
On Jan 4, 2008 8:50 AM, Guido van Rossum <guido@python.org> wrote:
On Jan 4, 2008 12:13 AM, Jeffrey Yasskin <jyasskin@gmail.com> wrote:
On Jan 3, 2008 10:37 AM, Guido van Rossum <guido@python.org> wrote:
Well, as issue 1689 states, the backporting was commited by Jeffrey on rev 5967 [2], so this is the time to understand if we want this or not.
This is a problem. Right now, in the trunk, math.float(1) returns 1, where it should return 1.0 for compatibility with 2.5. Jeffrey, can you fix this and similar incompatibilities you introduced?
Whoops! I've committed r59707 to fix math.{floor,ceil}. Let me know if you find any other problems. ... Hmm. I've also changed the behavior of round(2.5). I'll change that back tomorrow morning.
Looks like in Python 2.6, round(0.5) right now returns 0.0, whereas in 2.5, it returns 1.0.
I think it should return 1.0, for best compatibility with Python 2.5.
I haven't seen any answers to the original question. It looks like Decimal is decided by 2.5 too: return a float from everything.
Right.
Rational, being a completely new type, is up to you guys, but because new support for the conversion routines seems to be rare, it's probably best to have it return floats too.
I think the pre-3.0 rule should be: round(), math.floor(), math.ceil() *always* return a float.
These rollbacks, and that of pow(-1,.5)==1j are submitted as r59731. Keep letting me know what else I broke.
I think the consensus is against round-to-even in 3.0 -- this requires a PEP update as well as code changes. (Sorry for having caused so much extra work, I should have flagged this earlier.) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Jan 5, 2008 8:56 AM, Guido van Rossum <guido@python.org> wrote:
I think the consensus is against round-to-even in 3.0 -- this requires a PEP update as well as code changes. (Sorry for having caused so much extra work, I should have flagged this earlier.)
I'm not convinced that speed is a real issue in this case, since this is only the explicit round() operation and not rounding for arithmetic operations. But consistency with other languages is important. Does the following patch to the PEP represent the consensus? If so, I'll check it in, and update the py3k branch and wikipedia article to match. I've allowed each type to define its own half-rounding behavior so that Decimal can follow the current context, and float can, once there's a portable way to set it (like C99's fesetround), follow the current rounding mode (if people want that at the time). Index: pep-3141.txt =================================================================== --- pep-3141.txt (revision 59739) +++ pep-3141.txt (working copy) @@ -206,7 +206,10 @@ """Rounds self to ndigits decimal places, defaulting to 0. If ndigits is omitted or None, returns an Integral, otherwise - returns a Real. Rounds half toward even. + returns a Real. Types may choose which direction to round half. For + example, float rounds half away from 0, and Decimal rounds it + according to the active context. + """ raise NotImplementedError @@ -428,14 +431,15 @@ least Integral ``>= x``. 4. ``__round__(self)``, called from ``round(x)``, which returns the - Integral closest to ``x``, rounding half toward even. There is also - a 2-argument version, ``__round__(self, other)``, called from - ``round(x, y)``, which should return a Real. + Integral closest to ``x``, rounding half as the type chooses. There + is also a 2-argument version, ``__round__(self, other)``, called + from ``round(x, y)``, which should return a Real. Because the ``int()`` conversion implemented by ``float`` (and by ``decimal.Decimal``) is equivalent to but less explicit than ``trunc()``, let's remove it. (Or, if that breaks too much, just add a -deprecation warning.) +deprecation warning.) In 2.6, ``math.floor``, ``math.ceil``, and +``round`` will continue to return floats. ``complex.__{divmod,mod,floordiv,int,float}__`` also go away. It would be nice to provide a nice error message to help confused porters, but -- Namasté, Jeffrey Yasskin
participants (20)
-
"Martin v. Löwis" -
A.M. Kuchling -
Bill Janssen -
Brett Cannon -
Christian Heimes -
Daniel Stutzbach -
Facundo Batista -
Fred Drake -
Georg Brandl -
Guido van Rossum -
Jeffrey Yasskin -
Jeroen Ruigrok van der Werven -
Joseph Armbruster -
Mark Dickinson -
Mike Klaas -
Raymond Hettinger -
Scott David Daniels -
skip＠pobox.com -
Tim Peters -
Titus Brown