Python-Dev February 2004

python-dev@python.org

96 participants
135 discussions

RE: [Python-checkins] python/dist/src/Doc/tools prechm.py, 1.15.18.2, 1.15.18.3

by Tim Peters

> Modified Files: > Tag: release23-maint > prechm.py > Log Message: > SF patch #880552: Fix typo in usage message(prechm.py) > (Contributed by George Yoshida.) ... > > Index: prechm.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Doc/tools/prechm.py,v > retrieving revision 1.15.18.2 > retrieving revision 1.15.18.3 > diff -C2 -d -r1.15.18.2 -r1.15.18.3 > *** prechm.py 23 Sep 2003 20:34:40 -0000 1.15.18.2 > --- prechm.py 8 Feb 2004 19:26:13 -0000 1.15.18.3 > *************** > *** 24,28 **** > > usage_mode = ''' > ! Usage: make_chm.py [-c] [-k] [-p] [-v 1.5[.x]] filename > -c: does not build filename.hhc (Table of Contents) > -k: does not build filename.hhk (Index) > --- 24,28 ---- > > usage_mode = ''' > ! Usage: pre_chm.py [-c] [-k] [-p] [-v 1.5[.x]] filename > -c: does not build filename.hhc (Table of Contents) > -k: does not build filename.hhk (Index) > *************** If the name of the file is prechm.py, then saying pre_chm.py in the usage message appears just as wrong as saying make_chm.py <wink>.

17 years, 5 months

Tests failing on the head

by Jim Fulton

On Red Hat 9: [jim@enterprised src]$ uname -a Linux enterprised.zope.com 2.4.20-28.9 #1 Thu Dec 18 13:45:22 EST 2003 i686 i686 i386 GNU/Linux [jim@enterprised src]$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) ./configure --with-pydebug ... make ... ./python -E -tt ./Lib/test/regrtest.py -l -uall ... 240 tests OK. 8 tests failed: test_curses test_linuxaudiodev test_longexp test_ossaudiodev test_socket_ssl test_tarfile test_timeout test_urllibnet 23 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_bz2 test_cd test_cl test_codecmaps_cn test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_gl test_imgfile test_macfs test_macostools test_nis test_normalization test_pep277 test_plistlib test_scriptpackages test_sunaudiodev test_winreg test_winsound 1 skip unexpected on linux2: test_bz2 <shrug> Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

17 years, 5 months

PEP-0011 up-to-date

by Skip Montanaro

I believe all the 2.4 stuff for PEP-0011 is now complete. Are any edits to the pep itself required? Skip

17 years, 5 months

supporting Quixote PTL files in pydoc

by Skip Montanaro

I have this slight change to pydoc.py which allows it to grok Quixote's PTL-based modules: % cvs diff -u pydoc.py Index: pydoc.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/pydoc.py,v retrieving revision 1.90 diff -c -u -r1.90 pydoc.py cvs diff: conflicting specifications of output style --- pydoc.py 29 Jan 2004 06:37:49 -0000 1.90 +++ pydoc.py 7 Feb 2004 20:07:43 -0000 @@ -2125,10 +2125,15 @@ sys.path.insert(0, '.') try: - opts, args = getopt.getopt(sys.argv[1:], 'gk:p:w') + opts, args = getopt.getopt(sys.argv[1:], 'gk:p:wq') writing = 0 for opt, val in opts: + if opt == '-q': + # support Quixote's PTL + import quixote + quixote.enable_ptl() + continue if opt == '-g': gui() return I realize this may seem a bit like the tail wagging the dog, but PTL functions are so close syntactically and semantically to Python that it seems like a fairly modest change to allow them to be supported. I wonder if something like this could reasonably be slipped into the repository without much fuss? I have a change for pychecker which allows it to check PTL modules as well. For those unfamiliar with it, Quixote's PTL is described here: http://www.mems-exchange.org/software/quixote/doc/PTL.html Skip

17 years, 5 months

test_anydbm segfault on Mandrake 8.1

by Skip Montanaro

I'm getting this on Mandrake 8.1: % ./python Lib/test/test_anydbm.py UåSì èÅ2 Segmentation fault Running under gdb I get this for the Python stack: (gdb) ppystack /home/skip/src/python/dist/src/Lib/bsddb/__init__.py (337): _openDBEnv /home/skip/src/python/dist/src/Lib/bsddb/__init__.py (281): hashopen /home/skip/src/python/dist/src/Lib/dbhash.py (15): open /home/skip/src/python/dist/src/Lib/anydbm.py (66): open Lib/test/test_anydbm.py (36): test_anydbm_creation /home/skip/src/python/dist/src/Lib/unittest.py (245): run /home/skip/src/python/dist/src/Lib/unittest.py (419): __call__ /home/skip/src/python/dist/src/Lib/unittest.py (419): __call__ /home/skip/src/python/dist/src/Lib/unittest.py (686): run /home/skip/src/python/dist/src/Lib/test/test_support.py (255): run_suite /home/skip/src/python/dist/src/Lib/test/test_support.py (278): run_unittest Lib/test/test_anydbm.py (88): test_main Lib/test/test_anydbm.py (4): ? and this is the beginning of the gdb stack trace: #0 0x00000000 in ?? () #1 0x402a0d0f in DBEnv_open (self=0x401a6680, args=0x4026494c) at /home/skip/src/python/dist/src/Modules/_bsddb.c:3227 #2 0x080fd98a in PyCFunction_Call (func=0x40264dec, arg=0x4026494c, kw=0x0) at Objects/methodobject.c:93 #3 0x080b3c3d in call_function (pp_stack=0xbfffda7c, oparg=2) at Python/ceval.c:3452 #4 0x080b2080 in eval_frame (f=0x814e024) at Python/ceval.c:2126 #5 0x080b599b in fast_function (func=0x4026048c, pp_stack=0xbfffdb8c, n=0, na=0, nk=0) at Python/ceval.c:3531 #6 0x080b3b29 in call_function (pp_stack=0xbfffdb8c, oparg=0) at Python/ceval.c:3471 #7 0x080b2080 in eval_frame (f=0x8196794) at Python/ceval.c:2126 #8 0x080b2d92 in PyEval_EvalCodeEx (co=0x4021d820, globals=0x402179bc, locals=0x0, args=0x81b8630, argcount=3, kws=0x81b863c, kwcount=0, defs=0x402603b8, defcount=8, closure=0x0) at Python/ceval.c:2676 #9 0x080b5911 in fast_function (func=0x402573e4, pp_stack=0xbfffdd2c, n=3, na=3, nk=0) at Python/ceval.c:3542 ldd tells me this about the _bsddb shared object: % ldd build/lib.linux-i686-2.4/_bsddb.so libdb-3.3.so => /lib/libdb-3.3.so (0x40023000) libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x400b3000) libc.so.6 => /lib/libc.so.6 (0x400bb000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) and rpm suggests I've got Berkeley DB 3.3.11 installed. Is that recent enough for the bsddb package (suggesting a bug in setup.py) or is something else going on? Skip

17 years, 5 months

OSCON Reminder: proposal deadline Februrary 9

by Guido van Rossum

Just a quick reminder: you still have this weekend to submit a proposal for the Python 12 Conference at OSCON: The O'Reilly Open Source Convention (OSCON) will be held July 26-30, 2004 at the Portland Marriott Downtown in Portland, OR. http://conferences.oreillynet.com/os2004/ Proposals Submission Information--Deadline: February 9, 2004 http://conferences.oreillynet.com/cs/os2004/create/e_sess --Guido van Rossum (home page: http://www.python.org/~guido/)

17 years, 5 months

pyconfig.h macro usage

by Skip Montanaro

After Zacks message about configure.in cruft, I zapped the SIZEOF_CHAR macro and noticed it was never used in any .c files. So that got me to thinking (dangerous, I know)... What about: for macro in `egrep '#undef [_A-Z]' pyconfig.h.in \ | awk '{print $2}' \ | sort` do echo -n "$macro: " find . -name '*.[ch]' \ | egrep -v pyconfig \ | xargs egrep $macro \ | wc -l done \ | sort -n -k 2,2 Turns out there are quite a few macros defined in pyconfig.h that are unused: HAVE_DUP2 SIZEOF_FLOAT HAVE_GETPID SIZEOF_UINTPTR_T HAVE_LIBDL SIZEOF_WCHAR_T HAVE_LIBDLD SYS_SELECT_WITH_SYS_TIME HAVE_LIBIEEE TM_IN_SYS_TIME HAVE_LIBRESOLV WITH_DL_DLD HAVE_PTHREAD_INIT WITH_DYLD HAVE_STDARG_H WITH_LIBINTL HAVE_STRDUP _FILE_OFFSET_BITS HAVE_STRPTIME _LARGEFILE_SOURCE HAVE_ST_BLOCKS _MINIX HAVE_SYS_SOCKET_H _NETBSD_SOURCE HAVE_TERMIOS_H _OSF_SOURCE HAVE_TIMEGM _POSIX_1_SOURCE HAVE_TM_ZONE _POSIX_C_SOURCE HAVE_TRUNCATE _POSIX_SOURCE HAVE_UCS4_TCL _REENTRANT RETSIGTYPE __BSD_VISIBLE SIZEOF_DOUBLE __EXTENSIONS__ Any votes for getting rid of them? Skip

17 years, 5 months

Re: [Python-checkins] python/dist/src/Modules collectionsmodule.c, 1.2, 1.3

by Neal Norwitz

On Fri, Feb 06, 2004 at 11:04:59AM -0800, rhettinger(a)users.sourceforge.net wrote: > > + static PyObject * > + deque_extend(dequeobject *deque, PyObject *iterable) > + { > + PyObject *it, *item; > + > + it = PyObject_GetIter(iterable); > + if (it == NULL) > + return NULL; > + > + while ((item = PyIter_Next(it)) != NULL) { > + deque->rightindex++; > + deque->len++; > + if (deque->rightindex == BLOCKLEN) { > + block *b = newblock(deque->rightblock, NULL); > + if (b == NULL) > + return NULL; In deque_extend and deque_extendleft, doesn't there need to be a Py_DECREF(it); before returning when newblock fails? > + assert(deque->rightblock->rightlink == NULL); > + deque->rightblock->rightlink = b; > + deque->rightblock = b; > + deque->rightindex = 0; > + } > + Py_INCREF(item); > + deque->rightblock->data[deque->rightindex] = item; > + } > + Py_DECREF(it); > + if (PyErr_Occurred()) > + return NULL; > + Py_RETURN_NONE; > + }

17 years, 5 months

RE: [Python-checkins] python/dist/src/Objects weakrefobject.c, 1.15, 1.16

by Tim Peters

> Modified Files: > weakrefobject.c > Log Message: ... > Index: weakrefobject.c > =================================================================== ... and it leaves part of PyWeakref_NewRef() looking like: if (result != NULL) Py_INCREF(result); else { /* Note: new_weakref() can trigger cyclic GC, so the weakref list on ob can be mutated. This means that the ref and proxy pointers we got back earlier may have been collected, so we need to compute these values again before we use them. */ result = new_weakref(ob, callback); if (result != NULL) { if (callback == NULL) { insert_head(result, list); } else { When we call new_weakref(), callback may or may not be NULL. Assume it's NULL. Then we don't get into this code unless the first call to get_basic_refs() said there was not already a canonical weakref-without-callback weakref for ob. Cyclic gc can execute arbitrary Python code, if __del__ methods or callbacks get executed as a result of refcounts falling to 0 during cyclic gc. That code could in turn *create* a canonical weakref-without-callback weakref for ob, even while we're in the middle of creating our own. Suppose it does, and result isn't NULL. Then it looks like insert_head(result, list) is going to insert a second weakref-without-callback weakref for ob. Wouldn't that violate an excruciating global invariant? For example, PyObject_ClearWeakRefs() assumes that callback isn't NULL when it gets beyond the first two weakref objects in a weakref list, and get_basic_refs() assumes it never has to look at more than the first two weakref objects in a weakref list to determine whether a canonical weakref-proxy object for ob exists.

17 years, 6 months

pdb enhancements

by Ilya Sandler

Hello, I was wondering whether I should submit a formal patch for the following pdb enhancements: 1) right now if you do "pdb script" pdb will stop with a confusing > <string>(1)?() and you need to execute "s" before you get to the actual source being debugged, this seems somewhat unexpected and inconvenient A better way would be to go straight to the 1st line of user's code 2) right now when the script exits, the debugger exits too, taking with it all the debugging settings (like breakpoints) this seems very inconvenient Basically the cost of a too early exit is high (as you lose your breakpoints) while the cost of not exiting debugger at all is minimal (you just need to press Ctrl-D to exit when you need it) So I would think that pdb should not exit on script's exit. (and, say, gdb does not exit when program exits...) Do these suggestions make sense? Is implementing them likely to break anything else? Thanks, Ilya PS. I am new on this list and can only hope that the questions are appropriate for python-dev

17 years, 6 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev February 2004