Mailman 3 January 2008 - Python-Dev

Re: [Python-Dev] functions vs methods (was Re: trunc())
by Raymond Hettinger 28 Jan '08

28 Jan '08

> 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). New idea: * Drop the existing second argument for round. * Fold ceil(), floor(), trunc(), and round() into a single function: def round(x, mode=): if mode==CEIL: return math.ceil(x) elif mode==FLOOR: return math.floor(x) elif mode==TRUNC: return math.floor(x) if x>0 else math.ceil(x) elif mode==ROUND_TO_EVEN: . . . 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. Raymond 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) . . .

1 0

Re: [Python-Dev] functions vs methods (was Re: trunc())
by Raymond Hettinger 28 Jan '08

28 Jan '08

[MvL] > I wouldn't want to propose removal of len(), no. However, > I do think that adding more builtins (trunc in particular) > is bad, especially when they make perfect methods. +1 Raymond

1 0

Re: [Python-Dev] refleaks and caches
by Phillip J. Eby 28 Jan '08

28 Jan '08

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. > >Suggestions? Expose an API to clear the cache, and clear it at shutdown? It should probably be part of interpreter shutdown anyway.

6 8

why is mmap a builtin module on windows?
by Ralf Schmitt 28 Jan '08

28 Jan '08

Hi all, 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 windows 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? Regards, - Ralf

4 10

Re: [Python-Dev] Organization of ABC modules
by Raymond Hettinger 28 Jan '08

28 Jan '08

> 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 improvement. Raymond

7 10

Re: [Python-Dev] trunc()
by Raymond Hettinger 27 Jan '08

27 Jan '08

[Raymond Hettinger] >> 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. [Christian Heimes] > 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. Raymond

1 0

refleaks and caches
by Neal Norwitz 27 Jan '08

27 Jan '08

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. Suggestions? n

1 0

Re: [Python-Dev] [Python-checkins] r60283 - in python/trunk: Include/longintrepr.h Include/longobject.h Include/unicodeobject.h Misc/NEWS Modules/_fileio.c Objects/longobject.c Objects/unicodeobject.c setup.py
by Raymond Hettinger 26 Jan '08

26 Jan '08

[christian.heimes] >> 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 Py3.0-->Py2.6 contamination. Raymond

4 4

Simple syntax proposal: "not is"
by Jameson "Chema" Quinn 26 Jan '08

26 Jan '08

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.

7 7

Re: [Python-Dev] trunc()
by Raymond Hettinger 26 Jan '08

26 Jan '08

> 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 point." www.basis.com/onlinedocs/documentation/b3odbc/bbjds_int_function.htm VB: "Both the Int and Fix functions remove the fractional part of Number and return the resulting integer value." http://msdn2.microsoft.com/en-us/library/xh29swte.aspx Excel: "The Int function returns the integer portion of a number." http://www.techonthenet.com/excel/formulas/int.php 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. Raymond

9 10