> One thing I'm beginning to feel more and more strongly about
> is that round, trunc, ceil and floor all belong in the same
> category, and either should all be builtins or should all
> be in math.
> I should also admit that the 2-arg version of round() was
> borrowed from ABC, but the use case for it there doesn't map
> to Python: in ABC it's the only tool you have for floating point
> formatting on output, while in Python the same thing would
> typically be done with "%.2f" % x rather than round(x, 2).
* Drop the existing second argument for round.
* Fold ceil(), floor(), trunc(), and round() into a single function:
def round(x, mode=):
return math.floor(x) if x>0 else math.ceil(x)
. . .
Maybe we don't need a separate function and magic method for every possible rounding mode.
Also, I think there was some discussion of changing round() to use statistician's rounding. We might as well make it explicit that this is the new default.
P.S. One place to attach the constants is to the function object, so we would write:
x = round(3.1) # ROUND_TO_EVEN
x = round(3.1, round.CEIL)
. . .
At 05:05 PM 1/26/2008 -0800, Neal Norwitz wrote:
>Around Jan 13, the refleak hunting test that is reported on
>python-checkins started to report refleaks on virtually every run. I
>suspect this is due to r59944 (at 2008-01-13 16:29:41) which was from
>patch #1700288 to cache methods. With this patch it makes it much
>harder to spot refleaks. Does anyone have ideas how to fix it? The
>only one I have is to disable the cache with a special flag, env't
>variable, sys variable/function or the like. We could make this
>available only in debug mode. The cache should normally be enabled,
>but could be disabled solely on the refleak runs.
Expose an API to clear the cache, and clear it at shutdown? It
should probably be part of interpreter shutdown anyway.
I want to use the mmap module from python trunk with python 2.5.
On Linux I can easily replace it, as it is a dynamically loaded module. On
it is a builtin module and I fear that I must compile python on windows (or
resort to some other ugly hack)
What is the reason for mmap being a builtin module?
> If you want ABCs to be more easily recognizable
> as such, perhaps we could use a naming convention,
Essentially, that's all I was asking for. It doesn't
really matter to me whether numbers.py gets called
abc_numbers or abc.numbers. Either one would be an
>> The idea that programmers are confused by int(3.7)-->3 may not be nuts, but it doesn't match any experience I've had with any
>> programmer, ever.
> You haven't been doing newbie support in #python lately. Statements like
> Python is rounding wrong are common.
Of course, those floating point repr questions are common, but that wasn't the issue here.
The trunc() protagonists are contending that the int(f) function will be confused with the round(f, n) function. I've never seen
than come up, ever.
Around Jan 13, the refleak hunting test that is reported on
python-checkins started to report refleaks on virtually every run. I
suspect this is due to r59944 (at 2008-01-13 16:29:41) which was from
patch #1700288 to cache methods. With this patch it makes it much
harder to spot refleaks. Does anyone have ideas how to fix it? The
only one I have is to disable the cache with a special flag, env't
variable, sys variable/function or the like. We could make this
available only in debug mode. The cache should normally be enabled,
but could be disabled solely on the refleak runs.
>> Backport of several functions from Python 3.0 to 2.6 including PyUnicode_FromString, PyUnicode_Format and PyLong_From/AsSsize_t.
>> The functions are partly required for the backport of the bytearray type and _fileio module. They should also make it easier to
>> port C to 3.0.
Are you planning to backport bytearrays? I thought we had clearly decided to *not* backport any of the text/bytes model so that the
Py2.6 string/unicode model remained pure.
Guido proposed a couple of harmless aliases for annotation purposes (to help the 2-to-3 tool do the right thing) and that was it.
Your reply was:
> Ah, you like to keep it simple. The aliases are easily to implement.
> Give me twenty minutes to implement it and write some unit tests.
How did we get from two simple aliases to plans for backporting major chucks of the new model? I'm not seeing any limits on
I'm writing a source code editor that translates identifiers and keywords
on-screen into a different natural language. This tool will do no
transformations except at the reversible word level. There is one simple,
avoidable case where this results in nonsense in many languages: "is not". I
propose allowing "not is" as an acceptable alternative to "is not".
Obviously English syntax has a deep influence on python syntax, and I would
never propose deeper syntactical changes for natural-language-compatibility.
This is a trivial change, one that is still easily parseable by an
English-native mind (and IMO actually makes more sense logically, since it
does not invite confusion with the nonsensical "is (not ...)"). The
use-cases where you have to grep for "is not" are few, and the "(is
not)|(not is)" pattern that would replace it is still pretty simple.
> If the decision comes to be that int(float) should be blessed
> as a correct way to truncate a float, I'd agree with Raymond
> that trunc() is just duplication and should be eliminated.
Yay, we've make progress!
> I'd,of course, rather have a spelling that says what it means. :)
I wouldn't fret about this too much. Intrepreting int(f) as
meaning truncate has a *long* history in *many* programming
languages. It is a specious argument int(f) is ambiguous.
No one thinks it means ceil(f).
Go ask a dozen people if they are surprised that int(3.7) returns 3.
No one will be surprised (even folks who just use Excel or VB). It
is foolhardy to be a purist and rage against the existing art:
SQL: "The INT() function returns its numeric argument with any fractional
digits removed and truncates all digits to the right of the decimal
VB: "Both the Int and Fix functions remove the fractional part of
Number and return the resulting integer value."
Excel: "The Int function returns the integer portion of a number."
These docs suggest where the thinking has gone wrong. Writing int(f)
doesn't mean "arbritrary select one of round|ceil|floor|trunc as
a way of getting to an integer"; instead, it means "return the
integer portion (non-fractional component) of a number." The
latter definition seems common and is entirely unambiguous.