[Christoph, please keep the python-dev list in the loop here, at least
until they get annoyed and decide we're off-topic. I think this is
crucial to the way they package and deliver Python]
Christoph Ludwig <cludwig(a)cdc.informatik.tu-darmstadt.de> writes:
> On Thu, Jul 07, 2005 at 06:27:46PM -0400, David Abrahams wrote:
>> "Martin v. Löwis" <martin(a)v.loewis.de> writes:
>> > David Abrahams wrote:
>> >> I'm wondering if there has been a well-known recent change either in Python
>> >> or GCC that would account for these new reports. Any relevant
>> >> information would be appreciated.
>> > Python is linked with g++ if configure thinks this is necessary
>> Right. The question is, when should configure "think it's necessary?"
> Just to add to the confusion... I encountered the case that configure decided
> to use gcc for linking but it should have used g++. (It is Python
> PR #1189330 <http://tinyurl.com/dlheb>. This was on a x86 Linux system with
> g++ 3.4.2.)
> Background: The description of --with-cxx in the README of the
> Python 2.4.1 source distribution made me think that I need to
> configure my Python installation with
> --with-configure=/opt/gcc/gcc-3.4.2/bin/g++ if I plan to use C++
> extensions built with this compiler. (That was possibly a
> misunderstanding on my part,
> but Python should build with this option anyway.)
> configure set `LINKCC=$(PURIFY) $(CC)'. The result was that make failed when
> linking the python executable due to an unresolved reference to
> __gxx_personality_v0. I had to replace CC by CXX in the definition of LINKCC
> to finish the build of Python.
> When I looked into this problem I saw that configure in fact builds a test
> executable that included an object file compiled with g++. If the link step
> with gcc succeeds then LINKCC is set as above, otherwise CXX is
> used. Obviously, on my system this test was successful so configure decided
> to link with gcc. However, minimal changes to the source of the test program
> caused the link step to fail. It was not obvious to me at all why the latter
> source code should cause a dependency on the C++ runtime if the original
> code does not. My conclusion was that this test is fragile and should be
Sounds like it. I have never understood what the test was really
checking for since the moment it was first described to me, FWIW.
> If Python is built with --with-cxx then it should be linked with CXX
> as well.
> I gather from posts on the Boost mailing lists that you can import
> Boost.Python extensions even if Python was configured
Yes, all the tests are passing that way.
> (On ELF based Linux/x86, at least.) That leaves me wondering
> * when is --with-cxx really necessary?
I think it's plausible that if you set sys.dlopenflags to share
symbols it *might* end up being necessary, but IIRC Ralf does use
sys.dlopenflags with a standard build of Python (no
--with-cxx)... right, Ralf?
> * what happens if I import extensions built with different g++ versions? Will
> there be a conflict between the different versions of libstdc++ those
> extensions depend on?
Not unless you set sys.dlopenflags to share symbols.
It's conceivable that they might conflict through their shared use of
libboost_python.so, but I think you have to accept that an extension
module and the libboost_python.so it is linked with have to be built
with compatible ABIs anyway. So in that case you may need to make
sure each group of extensions built with a given ABI use their own
libboost_python.so (or just link statically to libboost_python.a if
you don't need cross-module conversions).
See http://python.org/sf/1454485 for the gory details. Basically if
you create a unicode array (array.array('u')) and try to append an
8-bit string (ie, not unicode), you can crash the interpreter.
The problem is that the string is converted without question to a
unicode buffer. Within unicode, it assumes the data to be valid, but
this isn't necessarily the case. We wind up accessing an array with a
negative index and boom.
This is perhaps somewhat simplified and not exactly accurate.
Probably best to look over the patch and make comments there on how
best to fix this issue.
There are 5 tests that leak references that are present in 2.4.3c1,
but not on HEAD. It would be great if someone can diagnose these and
suggest a fix.
test_doctest leaked [1, 1, 1] references
test_pkg leaked [10, 10, 10] references
test_pkgimport leaked [2, 2, 2] references
test_traceback leaked [11, 11, 11] references
test_unicode leaked [7, 7, 7] references
test_traceback leaks due to test_bug737473.
When you assign a bug/patch to me, somehow SourceForge doesn't send me
an email. (Is this understood behavior? Can it be changed?) Since I
don't monitor my SF personal page regularly any more, that means that
the issue will remain in limbo forever or until someone points me to
it. So if you want me to take any particular action (even rejecting
something) please send me a separate email!
--Guido van Rossum (home page: http://www.python.org/~guido/)
some time ago, someone posted in python-list about icons using the Python
logo from the new site design . IMO they are looking great and would
be a good replacement for the old non-scaling snakes on Windows in 2.5.
While we're at it, Python (and IDLE) .desktop files could be added to the
distribution, making it easier for newbies on *ix platforms to start up
a shell or the IDE, together with .png versions of the new icons. A pre-
liminary .desktop file is available at , I have already created a
corresponding Makefile rule locally.
What do people think?
I made a plea for help months ago (just checked, and it was Jan 2004! time
flies like a fruit or something, ref
about directions to fix the borken Tix.Grid widget; I had no replies.
I finally found some spare time (too little, though, much work, wife
expecting etc) and I started work on it, and at the moment it can be added
in a window and has some functionality, but I need a lot more finding my way
about using tcl/tk --I have almost zero knowledge of the language.
I would like to know if supplying a patch for it sometime in the next couple
of weeks would be considered a patch (since the widget currently is not
working at all, its class in Tix.py contains just a pass statement) or a
feature (ie extra functionality) for the 2.5 branch...
The checkins list has been struggling with generator reference leaks;
the latest conclusion was that some are unavoidable because of __del__
cycles. That sort of defeats the purpose of resource managers. (Yes,
it can be worked around on a case-by-case basis.)
As I see it, part of the problem is that
(1) When there is a cycle, python refuses to guess.
(2) There is no way for a __del__ method to hint at ordering constraints.
(3) There is no lightweight version of __del__ to say "I don't care
about ordering constraints."
How about using an (optional) annotation on __del__ methods, to
indicate how cycles should be broken?
As a strawman proposal:
deletes = [obj for obj in cycle if hasattr(obj, "cycle")]
for obj in deletes:
Lightweight __del__ methods (such as most resource managers) could set
the cycle attribute to True, and thereby ensure that they don't cause
unbreakable cycles. Fancier object frameworks could use different
values for the cycle attribute. Any object whose __del__ is not
annotated will still be at least as likely to get finalized as it is
it's time for the 7th Python Bug Day. The aim of the bug day is to close
as many bugs, patches and feature requests as possible, this time with a
special focus on new features that can still go into the upcoming 2.5 alpha
The bug day will take place on Friday, March 31st, running from
1PM to 7PM GMT (9AM to 3PM Eastern time). You don't need to be around all day;
feel free to stop by for a few hours and contribute.
Where and How?
To join, stop by the IRC channel #python-dev on irc.freenode.net, where
efforts will be discussed and coordinated. We'll collaboratively go through
the Python bug database at SourceForge and fix things as they come up.
IMPORTANT: *No* prior knowledge of the Python source is necessary to
participate! You'll get all assistance the developers can offer for starting
up with helping, this is in fact a good opportunity to learn the basics.
Bug day participation helps the developers and makes Python 2.5 a better
release by reducing the backlog of bugs and patches. Plus, it's fun!
For instructions and more information, see the Wiki page at
We've made a lot of improvement with testing over the years.
Recently, we've gotten even more serious with the buildbot, Coverity,
and coverage (http://coverage.livinglogic.de). However, in order to
improve quality even further, we need to do a little more work. This
is especially important with the upcoming 2.5. Python 2.5 is the most
fundamental set of changes to Python since 2.2. If we're to make this
release work, we need to be very careful about it.
In order to do the best possible job and avoid silly errors, there
shouldn't be any checkins which could change behaviour that do not
include a test. I'm not talking about updating comments or string
constants. But even trivial changes can cause regressions or
incompatible changes. Just like failing tests, code checked in
without tests is fair game for being reverted if there is anything
If you really can't figure out any way to test the change, please
describe why in your checkin message. Just make sure it's true. It
would be quite embarrassing to have your whole theory trashed when
Uncle Timmy comes along 5 minutes later and checks in the test you
just claimed was impossible. :-)
For about a week, I have been reading and occasionally posting to the new
pydev-3000 mailing list via the gmane mirror gmane.comp.lang.devel.3000.
Today, it has disappeared and was still gone after reloading their
newsgroup list. Was this intentional on the part of the mail list
maintainers? (I certainly hope not!) Or is it a repairable glitch
somewhere between the list and gmane?
Terry Jan Reedy