Mailman 3 May 2002 - Python-Dev

Re: Distutils confuses Berkeley DB and dbm?
by Skip Montanaro May 30, 2002

May 30, 2002

Okay, after a little investigation (about 30 seconds staring at setup.py), I see where the problem with dbm is. Setup.py has this code to deal with dbm: # The standard Unix dbm module: if platform not in ['cygwin']: if (self.compiler.find_library_file(lib_dirs, 'ndbm')): exts.append( Extension('dbm', ['dbmmodule.c'], libraries = ['ndbm'] ) ) elif self.compiler.find_library_file(lib_dirs, 'db1'): exts.append( Extension('dbm', ['dbmmodule.c'], libraries = ['db1'] ) ) else: exts.append( Extension('dbm', ['dbmmodule.c']) ) That second branch is just plain wrong. (I realize Neil added it in response to a bug report.) While it's true that Berkeley DB does (or did) provide a dbm API, the underlying file is a db1 hash file, which we all should realize by now is horribly broken, and if you've got a workable bsddb there's no sense in trying to trick programmers into thinking they also have real dbm files. I suggest we discard the elif branch. Any argument? Skip

2 2

__module__ of newly-created extension classes
by David Abrahams May 30, 2002

May 30, 2002

When creating new-style classes from within an extension module, the current behavior results in the __module__ attribute being set to the name of the Python module which first imports the extension module. I recall having a similar problem with my own extension classes in Boost.Python v1, but was a little surprised to find that it persists in Boost.Python v2, when creating new-style classes. A trivial inspection reveals this bit of code in typeobject.c: /* Set __module__ in the dict */ if (PyDict_GetItemString(dict, "__module__") == NULL) { tmp = PyEval_GetGlobals(); if (tmp != NULL) { tmp = PyDict_GetItemString(tmp, "__name__"); if (tmp != NULL) { if (PyDict_SetItemString(dict, "__module__", tmp) < 0) return NULL; } } } I can work around this problem, but I wonder if it would be a good idea if Python set __name__ automatically during the import of an extension module? I realize that there are ways to undermine this, e.g. explicitly creating a nested module object. +---------------------------------------------------------------+ David Abrahams C++ Booster (http://www.boost.org) O__ == Pythonista (http://www.python.org) c/ /'_ == resume: http://users.rcn.com/abrahams/resume.html (*) \(*) == email: david.abrahams(a)rcn.com +---------------------------------------------------------------+

3 8

_PyImport_LoadDynamicModule questions
by David Abrahams May 30, 2002

May 30, 2002

On AIX, building a shared library for use by extension modules and which uses the Python 'C' API is way harder than it should be**; the best workaround we could find involves hijacking _PyImport_LoadDynamicModule to load the shared library and patch up the symbol references. _PyImportLoadDynamicModule is undocumented, AFAICT. Am I not supposed to touch it? Is it likely to disappear or change its signature? On a related note, I wonder about all of the _[A-Z] names in Python. I know that at least in C++, these names are reserved to the compiler implementation. I assume the same holds for 'C', and wonder if Python's use of these names is intentional, on the "to be changed someday" list, or something else. Thanks in advance, Dave ** details to follow in later messages; AIX is nasty but I think Python could do a few things to help. +---------------------------------------------------------------+ David Abrahams C++ Booster (http://www.boost.org) O__ == Pythonista (http://www.python.org) c/ /'_ == resume: http://users.rcn.com/abrahams/resume.html (*) \(*) == email: david.abrahams(a)rcn.com +---------------------------------------------------------------+

3 13

Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib/test test_signal.py,1.9,1.10
by Michael Hudson May 30, 2002

May 30, 2002

Guido van Rossum <guido(a)python.org> writes: > > Well, I'm not mixing threads and signals, really. I've now learnt > > that when a signal is directed at a process on BSD it is delivered to > > "a" signal from the set of signals that hasn't blocked it. > ^^^^^^ ^^^^^^^ > > You mean theads, right? thReads, yes :) > > What I need to know, and can't quite work out, is how many threads are > > present when you just execute > > > > $ ./python > > > > and are sitting at the interpreter prompt? Is it just the one (the > > main thread)? That's what I thought, but I'm unable to explain the > > behaviour I'm seeing if that is indeed the case. > > Python doesn't create any threads. On Linux, I know that when you > start your first thread, the thread library creates an extra thread > for some internal reasons. Who knows what BSD does though. I'm not sure either, but I have convinced myself that signal mask handling is just buggered on BSD when the program is compiled in a multi-threaded style (as, in simple C programs don't do what you (well, I) would expect). Note this isn't about actually using threads -- just using "cc -pthreads". Now what do I do? Back my patch out? Not expose the functions on BSD? It works on Linux... Cheers, M. -- ARTHUR: Why should he want to know where his towel is? FORD: Everybody should know where his towel is. ARTHUR: I think your head's come undone. -- The Hitch-Hikers Guide to the Galaxy, Episode 7

3 2

Returned mail--"on Tue 4 Jul 2000 17"
by postmaster May 30, 2002

May 30, 2002

*** A virus was detected by the security administrator; this message was discarded ***

1 0

Re: [Python-Dev] Re: String module
by Michael Hudson May 30, 2002

May 30, 2002

Neal Norwitz <neal(a)metaslash.com> writes: > Guido van Rossum wrote: > > > BTW, how about deprecating strop while we're at it? > > Right now in string.py, there is: > > from strop import maketrans, lowercase, uppercase, whitespace > letters = lowercase + uppercase > > However, lowercase, uppercase, and letters are already defined > in string.py. It seems the only function being used from strop > is maketrans. Is this correct? Should the others be removed > from string.py? The strop definitions reflect the locale better than the ones in string.py. Cheers, M. -- And then the character-only displays went away (leading to increasingly silly graphical effects and finally to ads on web pages). -- John W. Baxter, comp.lang.python

2 1

Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib/test test_signal.py,1.9,1.10
by Michael Hudson May 30, 2002

May 30, 2002

Michael Hudson <mwh(a)python.net> writes: > Andrew MacIntyre <andymac(a)bullseye.apana.org.au> writes: > > > [test_signal fails on FreeBSD] > It doesn't fail if you disable threading. Oh /good/. Does anyone want to explain BSD threads and their interaction with signals to me? Cheers, M. -- I'll write on my monitor fifty times 'I must not post self-indulgent wibble nobody is interested in to ucam.chat just because I'm bored and I can't find the bug I'm supposed to fix'. -- Steve Kitson, ucam.chat

3 2

Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib/test test_signal.py,1.9,1.10
by Michael Hudson May 30, 2002

May 30, 2002

Guido van Rossum <guido(a)python.org> writes: > > Does anyone want to explain BSD threads and their interaction with > > signals to me? > > Yes. Threads and signals don't mix. Period. (Only half a smiley. :-) Well, I'm not mixing threads and signals, really. I've now learnt that when a signal is directed at a process on BSD it is delivered to "a" signal from the set of signals that hasn't blocked it. What I need to know, and can't quite work out, is how many threads are present when you just execute $ ./python and are sitting at the interpreter prompt? Is it just the one (the main thread)? That's what I thought, but I'm unable to explain the behaviour I'm seeing if that is indeed the case. Cheers, M. -- [3] Modem speeds being what they are, large .avi files were generally downloaded to the shell server instead[4]. [4] Where they were usually found by the technical staff, and burned to CD. -- Carlfish, asr

2 1

Re: [Python-checkins] python/dist/src/Lib/test test_signal.py,1.9,1.10
by Michael Hudson May 30, 2002

May 30, 2002

Andrew MacIntyre <andymac(a)bullseye.apana.org.au> writes: > On Mon, 27 May 2002 mwh(a)users.sourceforge.net wrote: > > > Update of /cvsroot/python/python/dist/src/Lib/test > > In directory usw-pr-cvs1:/tmp/cvs-serv24806/Lib/test > > > > Modified Files: > > test_signal.py > > Log Message: > > This is patch > > > > [ 559250 ] more POSIX signal stuff > > > > Adds support (and docs and tests and autoconfery) for posix signal > > mask handling -- sigpending, sigprocmask and sigsuspend. > > Since this batch of checkins, my FreeBSD autobuilder is failing Oh, um, good. > test_socket: > test test_signal failed -- HUP not pending > > Running the test with -v yields: > test_signal > + sleep 2 > starting pause() loop... > call pause()... > + kill -5 33123 > + sleep 2 > handlerA (5, <frame object at 0x8163e0c>) > pause() returned > call pause()... > + kill -2 33123 > + sleep 2 > handlerB (2, <frame object at 0x8163e0c>) > HandlerBCalled exception caught > call pause()... > + kill -3 33123 > KeyboardInterrupt (assume the alarm() went off) > blocking SIGHUP > sending SIGHUP > test test_signal failed -- HUP not pending > 1 test failed: > test_signal > > > I found the following (apparently) signal related items in the autoconf > generated pyconfig.h: > /* Define to 1 if you have the <signal.h> header file. */ > #define HAVE_SIGNAL_H 1 > > /* Define to 1 if you have the `sigprocmask' function. */ > #define HAVE_SIGPROCMASK 1 The above tests wouldn't have run without this symbol being defined (it's the new one). > /* Define to 1 if you have the `sigrelse' function. */ > /* #undef HAVE_SIGRELSE */ > > {...} > > /* Define as the return type of signal handlers (`int' or `void'). */ > #define RETSIGTYPE void > > > Any hints about where to start looking? > (I'm not au fait with signal() magic :-() Let me try playing on the sf compile farm first. Cheers, M.

1 0

release22-maint vs. release22-branch
by Neil Schemenauer May 30, 2002

May 30, 2002

What's the difference between these two tags? Do we need them both? Neil

3 6