Any thoughts on making this package more prominent on the Python.org
pages? Like under the primary Python 2.1.1 and Python 2.2 download links?
Command line: (longexp crashes purify for some reason)
./python -E -tt ./Lib/test/regrtest.py -u network -x test_longexp.py
168 tests OK.
1 test failed:
15 tests skipped:
test_al test_bsddb test_cd test_cl test_curses test_dl test_gl
test_imgfile test_linuxaudiodev test_nis test_ntpath test_openpty
test_sundry test_winreg test_winsound
test test_socket_ssl crashed -- socket.sslerror: SSL_CTX_new error
When running test_curses:
test test_curses crashed -- _curses.error: curs_set() returned ERR
Uninitialized Memory Reads (don't think these are python's fault):
Potential Memory Leaks:
1012 from 4 different allocating points -- all in WeakRef
Things look great!
Let me know if any of the skipped tests ought to have been run.
Most likely possibility seems to be bsddb, sundry also needs bsddb.
> Guido van Rossum wrote:
> > What's a potential leak? Could it be that these are in cycles? The
> > reported blocks are all weak reference objects; most of then are
> > allocated by add_subclass(), which uses weak refs for the list of
> > subclasses of a given (new-style) class. I suppose most weak refs are
> > in cycles (else there would be no need for weak refs).
Neal replied (in private email):
> From page 157 of this doc:
> A PLK message describes heap memory that you might have
> leaked. You have pointers only to the middle of the region. PLK is a
> warning message.
> Memory in use can sometimes appear as a PLK if the pointer
> returned by malloc is offset. A common cause is referencing a
> substring within a large string. Another example is when a
> pointer to a C++ object is cast to the second or later base class of a
> multiply-inherited object. It is offset past the other base class
> Truly leaked memory can sometimes appear as a PLK, if some
> non-pointer integer within the program space, when interpreted
> as a pointer, points within an otherwise leaked block of memory.
> This is rather rare. Inspect the code to differentiate between these
> causes of PLK reports.
Thanks, that's very helpful! Here's how I now understand what's
happened. Weak references are garbage collected, which means that the
malloc pointer points 12 bytes *before* the start of the object as the
rest of Python knows about it. Objects in the free list are linked
together via their object pointer, so they are only known via a
pointer into their "middle". We don't see this warning for other
GC'ed objects, because they are in one of the collector's linked
lists, which point to the start of the GC header which is the
malloc'ed pointer. But freed weak references are not known to the
So I'm confident that these are not leaks.
--Guido van Rossum (home page: http://www.python.org/~guido/)
just had reason to be looking at dumbdbm.py - perhaps
"terminallybrokendbm.py" would be a better name. There's a whole host of
"oh. my. god." type things in there that are just broken, with massive
dataloss problems if you end up (innocently) getting it from anydbm.py.
I'm going to fix it either this arvo/evening or tomorrow, but it really
shouldn't go out as part of 2.2 in it's current form. Is it too late to
consider either fixing it or removing it from anydbm's list?
Apple "wisely" changed their uname version numbering scheme with a
micro-release (10.1.1). Of course, nobody cares about this, except Python,
which stuffs the version into sys.platform, from where it is used by a
Anyway, where sys.platform used to be "darwin1" upto and including 10.1.0 it
is now "darwin5" for 10.1.1 (and it will go up to "darwin6" for 10.2, etc).
I am of a mind to take the "1" out of sys.platform, so that it becomes
Good idea or not?
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++
Veja meu site pessoal. Basta clicar no endereço
abaixo. GARANTO SER SUI-GENERIS - CLIQUE ABAIXO:
Mais de 162.000 internautas visitaram a PG., existe 6 Álbuns:
Se você quiser, por favor, indique minha Home Page, a outros
Internautas. Mais detalhes, se comunique, passe um e-mail, que
responderei brevemente. Dentro da Home Page, ao lado das fotos,
você poderá saber muito mais sobre mim!
Beijos:- Keila - Curitiba - Pr
- Podes falar comigo, direto dela. Brevemente uma Carta Aberta.
- Embora derrubem a página eu a subo em 3 horas novamente.
"Esta mensagem é enviada com a complacência da nova legislação
correio eletrônico, Seção 301, Parágrafo (a) (2) (c) Decreto S. 1618,
Título Terceiro aprovado pelo "105º Congresso Base das Normativas
Internacionais sobre o SPAM". Este E-mail não poderá ser considerado
SPAM quando incluir uma forma de ser removido. Para ser removido
de futuros correios, simplesmente responda indicando
no Assunto: REMOVER"
"Martin v. Loewis" <martin(a)v.loewis.de> writes:
> > It's hard. Bugzilla has some good features there w.r.t. "unverified"
> > vs. "new" vs. "accepted" and "fixed" vs "resolved", QA contacts, keyword
> > handling for milestone/release targets, etc. I'm not sure how the SF
> > bugtracker compares in practice but from a distance it seems a little
> > weak there.
> SF recommends to use the Group for "unsupported",
> "unverified". Unfortunately, the filtering capabilities leave a lot of
Is roundup usable yet? I played with it a bit yesterday, but I'm not
really sure what's needed. It would have the advantage that if it
didn't do something we needed, we could probably club it into doing it
I never disputed the Perl hacking skill of the Slashdot creators.
My objections are to the editors' taste, the site's ugly visual
design, and the Slashdot community's raging stupidity.
Andrew Kuchling just unassigned from himself a whole slew of
distutils-related bug reports. It appears that neither Andrew nor
Greg Ward (the original maintainer) has the time to maintain this code
any more. No-one at PythonLabs understands it or has the time to
learn about it. So it's effectively orphaned.
Does anybody want to volunteer?
--Guido van Rossum (home page: http://www.python.org/~guido/)
I just tried (1,2,3) == [1,2,3] and found that the compare
returns false. Is that intended ?
Background: 1.0 == 1 == 1L also works, so it seems natural
that comparing sequences of different types should work in the
same way. I would even expect a two iterators to compare equal
if they always return the same values (this could cause an endless
loop for some endless iterators ;-).
CEO eGenix.com Software GmbH
Consulting & Company: http://www.egenix.com/
Python Software: http://www.lemburg.com/python/