I found out that the directories listed in $CPPFLAGS and $LDFLAGS were
being added in reverse order in setup.py. That meant having ``-I/foo
-I/bar`` was searching /bar first. I fixed setup.py in the trunk so
that the declared order if followed instead.
But should this be backported? It will change how extensions are
compiled if there is more than one version on a machine. Not sure if
we want people to suddenly have what they link against change in a
I was running the test suite today and I was getting a segfault in
test_sqlite. That seemed odd since I had not seen any issues on any
buildbots. And running the test independently was fine.
Noticing that sqlite 3.5.5 was recently available I had MacPorts
update. Unfortunately this didn't fix things. I narrowed things down
to running test_ctypes before test_sqlite as the trigger. In order to
debug I wanted to use a version of sqlite that I had compiled.
So after figuring out which package to download (turned out to be the
amalgamation version with shell.c and the included makefile), and
discovering a bug in setup.py where directories from CPPFLAGS were
being searched in reversed from their declared order, I managed to get
a build with my own version and the problem went away.
So I suspect that sqlite3 from MacPorts is built in such a way as to
cause issues. This on Leopard which might also somehow influence
A request for information:
What non IEEE 754 platforms exist that people care about running Python 2.6,
Python 3.0 and higher on?
By non IEEE 754 platform, I mean a platform where either the C double is not
the usual 64-bit IEEE floating-point format, or where the C double is IEEE
format but the platform deviates in major ways from the IEEE 754
specification. There are a few places (mostly in mathmodule.c,
cmathmodule.c, floatobject.c, longobject.c) where it's not clear that the
code behaves correctly on non-IEEE platforms, and I'm finding it difficult
to determine how broken (or not) it is without having a clear idea of what
possible unusual floating-point formats might come up.
The major non-IEEE floating-point formats that I know of, on big iron, are
the VAX, Cray and IBM formats; I believe anything else is too old to worry
about. Is this true? The IBM format is particularly troublesome because
it's base 16 instead of base 2 (so e.g. multiplying a float by 2 can lose
bits), but it appears that recent IBM machines do both IBM format and IEEE
format floating-point. I assume that the S-390 buildbots are using the IEEE
side---is this true?
At the other end of the spectrum are embedded devices and cellphones. Here
I have no idea what the situation is at all---any information would be
-----BEGIN PGP SIGNED MESSAGE-----
This will be my last email today, I don't want to waste (more of) your
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea(a)argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/
jabber / xmpp:email@example.com _/_/ _/_/ _/_/_/_/_/
~ _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
It is my pleasure to announce that I have been appointed as the release
manager for the upcoming releases. For 2.5.2, I would like to release
a candidate on February 14, and the final version on February 21. As
Guido already mentioned, this will be a bug fix release only; no new
It would be very nice if http://bugs.python.org/issue1692335 fix was included
in 2.5.2. The patch exists, have been tested, reviewed by Georg Brandl, who
says he needs some other developer to review the patches (there is a separate
patch for 2.6). Could please someone look at the issue and help get the
problem fixed in 2.5.2.?