> 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.
Yes, this is very annoying and I once lost of lot of time because of the
> I think the options are:
> 1: Do nothing. Adapt the tests to deal with the differences.
> 2: Force 3 characters for exponents < 100.
> 3: Force 2 characters for exponents < 100.
I'd go for 3. Rationale: this change will mostly affect scientific code,
which is mostly developed and used on Unix systems.
Thanks for taking care if this nuisance!
I think I found a prolific vein of potential crashes throughout the
The idea is inspired from the discussion Issue1020188 and is quite
simple: find a Py_DECREF(xxx->yyy), where xxx represents any kind of
Python object, and craft a __del__ method so that the same function is
recursively called with the same object.
I recently submitted corrections for 3 problems found this way. Here
are two more examples of this method:
a = self
BaseException.__init__(self, Special(), 0)
BaseException.__init__(self, "other", 1)
MyException() # segfault
f = file(Special2("@temp"), "w")
f.__init__("@temp", "w") # segfault
Issue1020188 (which is still open btw) deals with member reset to
NULL; but any modification of the pointer is potentially concerned.
And the correction is always the same: use Py_CLEAR, or a similar
construction that detach the value from the structure before
I think it would help a lot of code if we had a safe standard way to
set struct members from C. A macro like the following:
(whatever its name) would perform the assignment and expand to code
PyObject* oldobj = lvalue;
lvalue = newobj;
I am currently searching for all places that could benefit of this,
but I am not sure to find a test case for every potential crash.
Most of the time, it is very unlikely that "normal" python code can
fall in these traps (who calls f.__init__ in a __del__ method?), with
the exception of the one corrected by r60871.
Should we however intensively search and correct all of them?
Is there a clever way to prevent these problems globally, for example
by delaying finalizers "just a little"?
Amaury Forgeot d'Arc
> A simple way to do this would be to push objects whose
> refcounts had reached 0 onto a list instead of finalizing them
> immediately, and have PyEval_EvalFrameEx periodically swap
> in a new to-delete list and delete the objects on the old one.
Some of the memory management threads discussed something similar to
this, and pointed to IBM papers on Java. By adding states like
"tenatively finalizable", the cost of using multiple processors was
The down side is that objects which could be released (and recycled)
immediately won't be -- which slows down a fair number of real-world
programs that are used to the CPython refcount model. If the resource
not being immediately released is scarce (such as file handles), it
gets even worse.
Should dir(module) use __all__ when defined?
['Empty', 'Full', 'LifoQueue', 'PriorityQueue', 'Queue', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', '_time', 'deque', 'heapq']
['Empty', 'Full', 'Queue', 'PriorityQueue', 'LifoQueue']
I like the second one better.
While implementing "".format(), I need to call the builtin format()
function, which I've already implemented (in
bltinmodule.c:builtin_format()). In the py3k branch, I just hardcoded
the same functionality into "".format(), which seems like the wrong
thing to do, given how complex the code is.
I see 2 approaches:
1: exposing builtin_format(), probably giving it another name
(PyObject_Format?) and moving it somewhere other than bltinmodule.c.
2: Instead of calling the C code directly, lookup "format" in Python's
builtins, and call it. This, I think, would allow you to override the
global format() function if you wanted to modify the behavior (although
I can't think of any use case for wanting to do that).
I don't see where either behavior is specified in the PEP.
If option 2 is preferred, could someone give me a pointer to how to find
a builtin function from C code?
On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.5.2 (release candidate 1).
This is the second bugfix release of Python 2.5. Python 2.5 is now in
bugfix-only mode; no new features are being added. According to the
release notes, over 100 bugs and patches have been addressed since
Python 2.5.1, many of them improving the stability of the interpreter,
and improving its portability.
For more information on Python 2.5.2, including download links for
various platforms, release notes, and known issues, please see:
Highlights of this new release include:
Bug fixes. According to the release notes, at least 100 have been fixed.
Highlights of the previous major Python release (2.5) are available
from the Python 2.5 page, at
Enjoy this release,
Martin v. Loewis
Python Release Manager
(on behalf of the entire python-dev team)
The 2.5 maintenance branch will be frozen tomorrow (Thursday)
around 7:00 UTC. Please don't make any changes to the branch
after that point unless you are directly involved in the release
If there are any issues that you think should be considered
before the 2.5.2 release, please assign them to me with high
I've just filed issue2114 (http://bugs.python.org/issue2114) because
test_decimal.py fails on OSX 10.3 with Python 2.5.2c1 (using the
python.org build that will be released soon). The same test passes on
OSX 10.4 and 10.5 (both Intel and PPC) using the exact same binaries.
IIRC the 2.5.1 release had no unexpected test failures on OSX 10.3, so
this is a regression in that regard.