Re: PEP on path module for standard library

[mkent]

I really love Jason's 'path' module.  Sadly, I've encountered a serious
problem with using it.  When you try to 'freeze' an application module,
and Jason's 'path' module is present in any of the directories that are
looked at by freeze's module finder (your app doesn't have to import
it), freeze goes into an infinite loop of imports, eventually getting a
'maximum recursion depth' exception.  This seems to be related to
freeze getting confused between 'os.path' and Jason's 'path'.

I encountered this using Jason's latest 'path' module and Python 2.3.2.
 I was able to solve it for my use by renaming path.py to newpath.py
and using 'from newpath import path' in my modules.

I've just notified Jason about this.  I presume a solution like mine
will be used, and look forward to seeing Jason's module in stdlib.

-- 
http://mail.python.org/mailman/listinfo/python-list

Need help:Unable to make runnable Python on AIX 4.3.3

[mkent]

I have a vexing problem and seek some input on how to fix it.

Starting with Python 2.4.0, I have been unable to compile a working
Python on our AIX 4.3.3 development system.  I can compile a working
Python 2.3.x with no problem.

The failure symptom is that Python 2.4.x fails its unit tests on
test_builtin with a Segmentation fault.  Turning on verbose test output
in the Makefile via the '-v' flag yields the following:

(Much output from passing tests elided)
test_open (test.test_builtin.BuiltinTest) ... ok
test_ord (test.test_builtin.BuiltinTest) ... ok
test_pow (test.test_builtin.BuiltinTest) ... ok
test_range (test.test_builtin.BuiltinTest) ... ok
test_reduce (test.test_builtin.BuiltinTest) ... ok
gmake: *** [test] Segmentation fault

Any ideas on how to find/fix this problem?  I'd hate to get locked into
Python 2.3, but that's what will happen if I can't solve this.

-- 
http://mail.python.org/mailman/listinfo/python-list

Problem: using signal.alarm() to stop a run-away os.system() command

[mkent]

I'm trying to use signal.alarm to stop a run-away os.system command.
Can anyone exlain the following behavior?

Given following the trivial program:

import os
import signal

def timeoutHandler(signum, frame):
print "Timeout"
raise ValueError


signal.signal(signal.SIGALRM, timeoutHandler)
signal.alarm(5)

os.system("yes")

signal.alarm(0)


What I expect is that the Linux/UNIX 'yes' command (which runs until
terminated) would be stopped after 5 seconds, when the timeoutHandler
is called, thus raising a ValueError and terminating this example
program.  Instead, the 'yes' command run until it is terminated (by,
say, a kill command), at which time the timeoutHandler is called.  In
other words, the running of the 'yes' command acts like it is blocking
the SIGALRM signal until it terminates, at which time the SIGALRM
signal is raised.  This is quite surprising, and totally defeats my
ability to catch a run-away process.  Can anyone see what I'm doing
wrong?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problem: using signal.alarm() to stop a run-away os.system() command

[mkent]

Thanks, that's the kind of on-target info I needed.  Now, shouldn't
there be some kind of mention of this limitation in the docs?

-- 
http://mail.python.org/mailman/listinfo/python-list

AIX 4.3, Python 2.4.1 fails in test_exceptions with a core dump

[mkent]

I'm attempting to switch from 2.3.2 to 2.4.1 on our AIX 4.3
development system.  I have no problems building Python 2.3.2.  I
build Python 2.4.1 using 'configure --without-threads; gmake;
gmake test', and always get a coredump during the tests on
'test_exceptions'.  I've searched for any reports of this problem on
the Sourceforge bug list and here, with no success.  Has anyone seen
this problem?

-- 
http://mail.python.org/mailman/listinfo/python-list