RetroSearch Browse

Mon Oct 12 06:40:21 CEST 2009 · https://mail.python.org/pipermail/python-dev/2009-October/092977.html

[Glyph Lefkowitz ]
> This reasoning definitely makes sense to me; with all the dependency-migration 
> issues 3.x could definitely use some carrots.  However, I don't think I agree with it, 
> because this doesn't feel like a big new feature, just some behavior which has changed.  

The carrots/incentives idea also sounds specious to me. First of all, I consider it 
to be more of a bug fix than a feature -- we've had plenty of bug reports and confusion
surrounding the current implementation and at least one of my scripts is broken 
(occasionally giving wrong answers and the same also is true for decimal.__float__ 
method being similarly afflicted).  Our current dependency on a badly implemented 
libc strtod() function is not a good thing (and not consistent across various Python builds).   
Second, as Glyph points out, the change is too small of an improvement to be a real carrot.

One quick thought on the doctest issue.  If the doctests are being used as originally
intended (as part of validating examples in docstrings), then consider that the docstrings
themselves would actually be improved with the shorter repr.  IMO, it significantly
detracts from examples if they are afflicted with floating point repr issues:

    def average(seq):
         """ Return the arithmetic mean of a sequence.

         >>> average([0.1, 0.5])
         0.29999999999999999

         """
         return sum(seq) / float(len(seq))

Wouldn't this example be much nicer if it returned 0.3 ?

Raymond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091011/1cf7bd4d/attachment.htm>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2009-October/092977.html below:

[Python-Dev] Backport new float repr to Python 2.7?