On Jan 4, 2008 8:50 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Jan 4, 2008 12:13 AM, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
On Jan 3, 2008 10:37 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
Well, as issue 1689 states, the backporting was commited by Jeffrey on
rev 5967 [2], so
Guido What code would break if we loosened this restriction?
I don't know how much, but I do know I've relied on this behavior before.
(In fact, I've asked about it before.) I guess the counter question to
yours would be, What would be gained by loosening this restriction? If
the answer
On Jan 4, 2008 10:16 PM, [EMAIL PROTECTED] wrote:
On 4 Jan, 10:45 pm, [EMAIL PROTECTED] wrote:
[GvR to Tim]
Do you have an opinion as to whether we should
adopt round-to-even at all (as a default)?
For the sake of other implementations (Jython, etc) and for ease of
reproducing the results
On Jan 5, 2008 12:56 AM, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
On Jan 4, 2008 8:50 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Jan 4, 2008 12:13 AM, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
On Jan 3, 2008 10:37 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
Well, as issue 1689
On Jan 5, 2008 6:58 AM, [EMAIL PROTECTED] wrote:
Guido What code would break if we loosened this restriction?
I don't know how much, but I do know I've relied on this behavior before.
(In fact, I've asked about it before.) I guess the counter question to
yours would be, What would be
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
On Jan 5, 2008 8:56 AM, Guido van Rossum [EMAIL PROTECTED] 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
Added Python to the referenced article (because I believe Python
should be seen everywhere C#, PHP, Visual Basic, etc., are seen).
Please let me know if the article needs updating/fixing.
http://en.wikipedia.org/wiki/Rounding
---
Art Rasmussen
___
On Sat, Jan 05, 2008 at 05:35:45PM -0200, Facundo Batista wrote:
2008/1/5, Art Rasmussen [EMAIL PROTECTED]:
Added Python to the referenced article (because I believe Python
should be seen everywhere C#, PHP, Visual Basic, etc., are seen).
Please let me know if the article needs
On Jan 4, 2008 12:05 PM, Tim Delaney [EMAIL PROTECTED] wrote:
history of insertions and deletions. If items(), keys(), values(),
iteritems(), iterkeys(), and itervalues() are called with no intervening
modifications to the dictionary, the lists will directly correspond.
I looked over the Java
2008/1/5, Art Rasmussen [EMAIL PROTECTED]:
Added Python to the referenced article (because I believe Python
should be seen everywhere C#, PHP, Visual Basic, etc., are seen).
Please let me know if the article needs updating/fixing.
Well, don't know.
It talks about the rounding in Python, but
This is a VERY VERY rough draft of a PEP. The idea is that there should be
some formal way that reST parsers can differentiate (in docstrings) between
variable/function names and identical English words, within comments.
PEP: XXX
Title: Catching unmarked identifiers in docstrings
Version:
On 04:54 pm, [EMAIL PROTECTED] wrote:
On Jan 4, 2008 10:16 PM, [EMAIL PROTECTED] wrote:
Having other rounding methods *available*, though, would be neat. The
only application I've ever worked on where I cared about the
difference,
the user had to select it (since accounting requirements
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
On Jan 5, 2008 2:36 PM, Christian Heimes [EMAIL PROTECTED] 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
On Jan 5, 2008 5:54 PM, [EMAIL PROTECTED] wrote:
At first I didn't realize why I'd missed this feature. While the
rounding *modes* are well documented, though, after 20 minutes of
reading documentation I still haven't found a method or function that
simply rounds a decimal to a given
[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
[Mark Dickinson]
quantize is about as close as it gets. Note that it's a Decimal method as
well as a Context method, so you can invoke it directly on a given decimal:
Decimal(2.34567).quantize(Decimal(0.01))
Decimal(2.35)
This reads better in many cases if you define a constant first,
On Jan 4, 2008 1:31 PM, Tim Peters [EMAIL PROTECTED] 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
On Sat, Jan 05, 2008, [EMAIL PROTECTED] wrote:
At first I didn't realize why I'd missed this feature. While the
rounding *modes* are well documented, though, after 20 minutes of
reading documentation I still haven't found a method or function
that simply rounds a decimal to a given
On Jan 5, 2008 3:34 PM, Mark Dickinson [EMAIL PROTECTED] wrote:
On Jan 5, 2008 5:54 PM, [EMAIL PROTECTED] wrote:
At first I didn't realize why I'd missed this feature. While the
rounding *modes* are well documented, though, after 20 minutes of
reading documentation I still haven't found
I think pep 3141's round(x, ndigits) does (1). The only thing it
doesn't support yet is specifying the rounding mode. Perhaps the pep
should say that round() passes any extra named arguments on to the
__round__() method so that users can specify a rounding mode for types
that support it?
[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
[Tim]
I agree it's far from obvious to most how
to accomplish rounding using the decimal facilities.
FWIW, there is an entry for this in the Decimal FAQ:
http://docs.python.org/lib/decimal-faq.html
Raymond
___
Python-Dev mailing list
24 matches
Mail list logo
