[Python-Dev] Readline completion hook silences exceptions.
Hey, I've never posted to this list before but I think it is the right place for discussions such as this: The readline completion hook doesn't reraise exceptions. This is probably a good thing for actually using readline, less useful for debugging a completer. Possibly readline should have a 'debug' mode where it doesn't silence? Richard. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] FreeBSD test suite failure -> curses
So I added my first buildbot yesterday (for FreeBSD and I hope to add a few more different BSD ones to the fray) and I see that it is failing in the test_curses part. I tracked it by hand and somewhere along the test it segfaults. The resulting coredump is not really helpful. (gdb) bt #0 0x281aa61f in pthread_testcancel () from /lib/libpthread.so.2 #1 0x281a2a52 in pthread_mutexattr_init () from /lib/libpthread.so.2 #2 0x28167450 in ?? () Anybody have any hints where I should poke around? -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Looking for the Sun that eclipsed behind black feathered wings... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Readline completion hook silences exceptions.
> The readline completion hook doesn't reraise exceptions. This is > probably a good thing for actually using readline, less useful for > debugging a completer. Possibly readline should have a 'debug' mode > where it doesn't silence? Errors should never pass silently. Unless explicitly silenced. Please submit a patch. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FreeBSD test suite failure -> curses
> So I added my first buildbot yesterday (for FreeBSD and I hope to add a few > more different BSD ones to the fray) and I see that it is failing in the > test_curses part. > > I tracked it by hand and somewhere along the test it segfaults. The > resulting coredump is not really helpful. > > (gdb) bt > #0 0x281aa61f in pthread_testcancel () from /lib/libpthread.so.2 > #1 0x281a2a52 in pthread_mutexattr_init () from /lib/libpthread.so.2 > #2 0x28167450 in ?? () > > Anybody have any hints where I should poke around? If you want to ask for help, that's probably something for the FreeBSD lists. Unfortunately, the FreeBSD threads library is notorious for crashing, hanging, and doing other unpleasant things to Python. If you want to debug this, run Python in a debugger, and run the test suite from there. core files are often not too helpful. For the core file, make sure you select the right thread to inspect - this is probably not the one which caused the crash; use "info threads" as a starting point (hoping that the core file supports that). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Complexity documentation request
Hello all, Is it possible to include algorithm complexity information for the various built-in types (strings, sets, lists, dictionaries...)? This would ease the decision for choosing the correct type. The information could simply be added as a new column in the tables found on pages as the following: http://docs.python.org/lib/types-set.html http://docs.python.org/lib/typesseq.html It took me a while to find some information for my purposes, however I'm not sure whether it's outdated or incomplete. The best sources I found are python-list archive and a PEP: http://www.python.org/dev/peps/pep-3128/ http://mail.python.org/pipermail/python-list/2007-June/446877.html Nevertheless, algorithm complexity is not always the answer. I remember some years ago I preferred using "x in list" rather than "x in set" as member checking in a tight loop, because the list was rather small (10-20 elements) and the overhead for the set was far greater than the better algorithm complexity advantage. So if this information is available, it would be nice to document constant time factors too. :-) Thanks in advance, Dimitris ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
