Mailman 3 February 2008 - Python-Dev

Backporting PEP 3101 to 2.6
by Eric Smith Feb. 22, 2008

Feb. 22, 2008

(I'm posting to python-dev, because this isn't strictly 3.0 related. Hopefully most people read it in addition to python-3000). I'm working on backporting the changes I made for PEP 3101 (Advanced String Formatting) to the trunk, in order to meet the pre-PyCon release date for 2.6a1. I have a few questions about how I should handle str/unicode. 3.0 was pretty easy, because everything was unicode. 1: How should the builtin format() work? It takes 2 parameters, an object o and a string s, … [View More]

7 16

Nosy lists on issue tracker.
by Benjamin Peterson Feb. 22, 2008

Feb. 22, 2008

Hi, What is the policy regarding nosy lists? Is it appropriate it add people to it besides oneself? As I cannot assign items, I'm sometimes tempted to add someone relevant to the list. (ie Should I add Georg to documentation related issues?) Thanks for your patience, Benjamin -- Benjamin Peterson Composer, Clarinetist, Programmer, Wikipedian, Food enthusiast, and full-time student "Nothing is more beautiful than an oboe; unless it's a chicken stuck in a vacuum cleaner"

4 5

Reminder: bug day on Saturday
by A.M. Kuchling Feb. 21, 2008

Feb. 21, 2008

We have a bug day this Saturday. Join us on IRC and let's see how many issues we can clear up. http://wiki.python.org/moin/PythonBugDay for more. There are currently 69 bugs marked as 'easy', which is probably more than enough, but if you see anything that's suitable for a new developer, please mark it. --amk

2 2

New math functions
by Raymond Hettinger Feb. 20, 2008

Feb. 20, 2008

Was some thought given to possibly adding these as float methods instead of as separate functions? float.isinf() float.isnan() Also, it would be useful to have a new method, float.is_integer(). This would be better than the current approach where we make the test: if x == floor(x). Raymond

5 4

Re: [Python-Dev] int/float freelists vs pymalloc
by Christian Heimes Feb. 20, 2008

Feb. 20, 2008

Andrew MacIntyre wrote: > I seem to recall Tim Peters paying a lot of attention to cache effects > when he went over the PyMalloc code before the 2.3 release, which would > contribute to its performance. Well, I guess we have to ask Uncle Tim on this matter and ask for his opinion. I've no experience with optimization on the level of CPU cache lines. But it sounds interesting. Does somebody have an advice for some articles or a good book? > I tested the updated patch you added to … [View More]

6 10

small Grammar questions
by Andrew Dalke Feb. 20, 2008

Feb. 20, 2008

I'm finishing up a PLY lexer and parser for the current CVS version of the Python grammar. As part of it I've been testing a lot of dark corners in the grammar definition and implementation. Python 2.5 has some small and rare problems which I'm pleased to note have been pretty much fixed in Python 2.6. I have two questions about the grammar definition. Here's a difference between 2.5 and 2.6. % cat x.py c = "This is 'c'" def spam((a) = c): print a spam() % python2.5 x.py This is 'c' % … [View More]

3 6

trunk-math
by Mark Dickinson Feb. 20, 2008

Feb. 20, 2008

Dear all, I'd like to draw your attention to some of the work that's been going on in the trunk-math branch. Christian Heimes and I have been working on various aspects of Python mathematics, and we're hoping to get at least some of this work into Python 2.6/3.0. Most of the changes are completed or nearly complete, and 2.6/3.0 isn't very far away, so it seems like a good time to try to get some feedback from python-dev. Here's an overview of the changes (overview originally written by … [View More]Christian, edited and augmented by me. I hope Christian will step in and correct me if I misrepresent him or his work here.) Many of the changes were motivated by Christian's work (already in the trunk) in making infinities and nans more accessible and portable for Python users. (See issue #1640.) * Structural reorganization: there are new files Include/pymath.h and Objects/pymath.c with math-related definitions and replacement functions for platforms without copysign, log1p, hypot and inverse hyperbolic functions. * New math functions: inverse hyperbolic functions (acosh, asinh, atanh). * New float methods: is_finite, is_inf, is_integer and is_nan. * New cmath functions: phase, polar and rect, isinf and isnan. * New complex method: is_finite. * Work on math and cmath functions to make them handle special values (infinities and nans) and floating-point exceptions according to the C99 standard. The general philosophy follows the ideas put forth by Tim Peters and co. many moons ago. and repeated in the issue #1640 thread more recently: where the C99 standard (or IEEE 754) specifies raising 'invalid' or 'divide-by-zero' Python should raise a ValueError. Where the C99 standard specifies raising 'overflow' Python should raise OverflowError. 'underflow' and 'inexact' flags are ignored. From a user's perspective, this means that infinities and nans are never produced by math or cmath operations on finite values (but see below). sqrt(-1) will always raise ValueError, instead of returning a NaN. See issue #711019 and the resulting warning at the bottom of the math module documentation. Although complex_abs doesn't live in cmathmodule.c, it was also fixed up this way. * The cmath module has been rescued: it's no longer numerically unsound (see issue #1381). For the majority of functions (sin, cos, tan, sinh, cosh, tanh, asin, acos, atan, asinh, acosh, atanh, exp, sqrt) the real and imaginary parts of the results are always within a few ulps of the true values. (In extensive but non-exhaustive testing I haven't found errors of more than 5 ulps in either the real or imaginary parts for these functions.) For log and log10 the errors can be larger when the argument has absolute value close to 1; this seems pretty much unavoidable without using multiple-precision arithmetic. pow and two-argument log are less accurate; again, this is essentially unavoidable without adding hundreds of extra lines of code. * Many more tests. In addition to a handful of extra test_* methods in test_math and test_cmath, there are over 1700 testcases (in a badly-named file Lib/test/cmath.ctest) for the cmath and math functions, with a testcase format inspired in no small part by the decimal .decTest file format. Most of the testcase values were produced independently of Python using MPFR and interval arithmetic (C code available on request); some were created by hand. * There's a per-thread state for division operator. In IEEE 754 mode 1./0. and 1.%0. return INF and 0./0. NAN. The contextlib has a new context "ieee754" and the math lib set_ieee754/get_ieee754 (XXX better place for the functions?) Some notes: * We've used the C99 standard (especially Annex F and Annex G) as a reference for deciding what the math and cmath functions should do, wherever possible. It seems to make sense to choose to follow some standard, essentially so that all the hard decisions have been thought through thoroughly by a group of experts. Two obvious choices are the C99 standard and IEEE 754(r); for almost all math issues the two say essentially the same thing. C99 has the advantage that it includes specifications for complex math, while IEEE 754(r) does not. (Actually, I've been using draft version N1124 of the C99 standard, not the standard itself, since I'm too cheap to pay up for a genuine version. Google 'N1124' for a copy.) * I'm offering to act as long-term maintainer for the cmath module, if that's useful. * The most interesting and exciting feature, by far (in my opinion) is the last one. By way of introduction, here's a snippet from Tim Peters, in a comp.lang.python posting ( http://mail.python.org/pipermail/python-list/2005-July/330745.html), answering a question from Michael Hudson about 1e300*1e300 and inf/inf. "I believe Python should raise exceptions in these cases by default, because, as above, they correspond to the overflow and invalid-operation signals respectively, and Python should raise exceptions on the overflow, invalid-operation, and divide-by-0 signals by default. But I also believe Python _dare not_ do so unless it also supplies sane machinery for disabling traps on specific signals (along the lines of the relevant standards here). Many serious numeric programmers would be livid, and justifiably so, if they couldn't get non-stop mode back. The most likely x-platfrom accident so far is that they've been getting non-stop mode in Python since its beginning." Christian has found a simple, elegant and practical way to make it possible for Python to raise these exceptions by default, while also allowing serious numeric users access to non-stop mode---i.e., a mode that generates inf from 1/0 instead of raising a Python exception. (I had a much more elaborate plan in mind, involving a thread-local context similar to Decimal's, with control over individual traps and flags. Christian's solution is far more practical.) The idea is that any arithmetic operating under a "with ieee754:" acts like arithmetic on an IEEE 754 platform with no traps enabled: invalid operations like sqrt(-1) produce a nan, division by zero produces an infinity, etc. No Python exceptions related to floating-point are raised. See the thread started by Neal Becker at http://mail.python.org/pipermail/python-list/2008-February/477064.html, entitled "Turn off ZeroDivisionError?" for a recent discussion of these issues. I fear that the per-thread state change seems like something where a PEP might be necessary; it's also not clear right now that Christian and I have exactly the same goals here (discussion is ongoing). But I hope that the rest of the changes are uncontroversial enough to merit consideration for possible inclusion in 2.6/3.0. Thoughts? Mark [View Less]

6 9

Error in PEP3118?
by Thomas Heller Feb. 20, 2008

Feb. 20, 2008

Hi Travis, The pep contains this sample: """ Nested array :: struct { int ival; double data[16*4]; } """i:ival: (16,4)d:data: """ """ I think it is wrong and must be changed to the following; is this correct? """ Nested array :: struct { int ival; double data[16][4]; } """i:ival: (16,4)d:data: """ """ Thomas

7 11

Optional positional-only parameters (was Re: [Python-3000] PEP 3102)
by Joel Bender Feb. 19, 2008

Feb. 19, 2008

Nick Coghlan wrote: > We've also veered fairly far off topic for the Py3k list - further ideas > for positional-only argument syntax or decorators should probably be > kicked around on python-ideas rather than here or python-dev. For a function specification like this: def f(w, x=1, *, y, z=2): ... My preference is for w and x to be positional only, w is required; y and z are keyword only, y is required. I personally like the idea that for functions like range([start,] … [View More]

1 0

Different float formatting on Windows and Linux
by Eric Smith Feb. 19, 2008

Feb. 19, 2008

The tests for float.__format__ are breaking on Windows, because of this issue: http://bugs.python.org/issue1600. Basically, Windows is using 3 digits for exponents < 100, and Linux (and at least MacOS) are using 2. The patch attached to the issue proposes changing all platforms to use at least 3 digits. It affects both '%' formatting and __format__ formatting. Altering all float formatting involving exponents is a pretty big change to make, and I want to get opinions here before … [View More]

2 1