Python-Dev November 2005

python-dev@python.org

117 participants
119 discussions

by Peter Astrand

On Wed, 10 Nov 2004, John P Speno wrote: Hi, sorry for the delayed response. > While using subprocess (aka popen5), I came across one potential gotcha. I've had > exceptions ending like this: > > File "test.py", line 5, in test > cmd = popen5.Popen(args, stdout=PIPE) > File "popen5.py", line 577, in __init__ > data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB > OSError: [Errno 4] Interrupted system call > > (on Solaris 9) > > Would it make sense for subprocess to use a more robust read() function > which can handle these cases, i.e. when the parent's read on the pipe > to the child's stderr is interrupted by a system call, and returns EINTR? > I imagine it could catch EINTR and EAGAIN and retry the failed read(). I assume you are using signals in your application? The os.read above is not the only system call that can fail with EINTR. subprocess.py is full of other system calls that can fail, and I suspect that many other Python modules are as well. I've made a patch (attached) to subprocess.py (and test_subprocess.py) that should guard against EINTR, but I haven't committed it yet. It's quite large. Are Python modules supposed to handle EINTR? Why not let the C code handle this? Or, perhaps the signal module should provide a sigaction function, so that users can use SA_RESTART. Index: subprocess.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/subprocess.py,v retrieving revision 1.8 diff -u -r1.8 subprocess.py --- subprocess.py 7 Nov 2004 14:30:34 -0000 1.8 +++ subprocess.py 17 Nov 2004 19:42:30 -0000 @@ -888,6 +888,50 @@ pass + def _read_no_intr(self, fd, buffersize): + """Like os.read, but retries on EINTR""" + while True: + try: + return os.read(fd, buffersize) + except OSError, e: + if e.errno == errno.EINTR: + continue + else: + raise + + + def _read_all(self, fd, buffersize): + """Like os.read, but retries on EINTR, and reads until EOF""" + all = "" + while True: + data = self._read_no_intr(fd, buffersize) + all += data + if data == "": + return all + + + def _write_no_intr(self, fd, s): + """Like os.write, but retries on EINTR""" + while True: + try: + return os.write(fd, s) + except OSError, e: + if e.errno == errno.EINTR: + continue + else: + raise + + def _waitpid_no_intr(self, pid, options): + """Like os.waitpid, but retries on EINTR""" + while True: + try: + return os.waitpid(pid, options) + except OSError, e: + if e.errno == errno.EINTR: + continue + else: + raise + def _execute_child(self, args, executable, preexec_fn, close_fds, cwd, env, universal_newlines, startupinfo, creationflags, shell, @@ -963,7 +1007,7 @@ exc_value, tb) exc_value.child_traceback = ''.join(exc_lines) - os.write(errpipe_write, pickle.dumps(exc_value)) + self._write_no_intr(errpipe_write, pickle.dumps(exc_value)) # This exitcode won't be reported to applications, so it # really doesn't matter what we return. @@ -979,7 +1023,7 @@ os.close(errwrite) # Wait for exec to fail or succeed; possibly raising exception - data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB + data = self._read_all(errpipe_read, 1048576) # Exceptions limited to 1 MB os.close(errpipe_read) if data != "": child_exception = pickle.loads(data) @@ -1003,7 +1047,7 @@ attribute.""" if self.returncode == None: try: - pid, sts = os.waitpid(self.pid, os.WNOHANG) + pid, sts = self._waitpid_no_intr(self.pid, os.WNOHANG) if pid == self.pid: self._handle_exitstatus(sts) except os.error: @@ -1015,7 +1059,7 @@ """Wait for child process to terminate. Returns returncode attribute.""" if self.returncode == None: - pid, sts = os.waitpid(self.pid, 0) + pid, sts = self._waitpid_no_intr(self.pid, 0) self._handle_exitstatus(sts) return self.returncode @@ -1049,27 +1093,33 @@ stderr = [] while read_set or write_set: - rlist, wlist, xlist = select.select(read_set, write_set, []) + try: + rlist, wlist, xlist = select.select(read_set, write_set, []) + except select.error, e: + if e[0] == errno.EINTR: + continue + else: + raise if self.stdin in wlist: # When select has indicated that the file is writable, # we can write up to PIPE_BUF bytes without risk # blocking. POSIX defines PIPE_BUF >= 512 - bytes_written = os.write(self.stdin.fileno(), input[:512]) + bytes_written = self._write_no_intr(self.stdin.fileno(), input[:512]) input = input[bytes_written:] if not input: self.stdin.close() write_set.remove(self.stdin) if self.stdout in rlist: - data = os.read(self.stdout.fileno(), 1024) + data = self._read_no_intr(self.stdout.fileno(), 1024) if data == "": self.stdout.close() read_set.remove(self.stdout) stdout.append(data) if self.stderr in rlist: - data = os.read(self.stderr.fileno(), 1024) + data = self._read_no_intr(self.stderr.fileno(), 1024) if data == "": self.stderr.close() read_set.remove(self.stderr) Index: test/test_subprocess.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_subprocess.py,v retrieving revision 1.14 diff -u -r1.14 test_subprocess.py --- test/test_subprocess.py 12 Nov 2004 15:51:48 -0000 1.14 +++ test/test_subprocess.py 17 Nov 2004 19:42:30 -0000 @@ -7,6 +7,7 @@ import tempfile import time import re +import errno mswindows = (sys.platform == "win32") @@ -35,6 +36,16 @@ fname = tempfile.mktemp() return os.open(fname, os.O_RDWR|os.O_CREAT), fname + def read_no_intr(self, obj): + while True: + try: + return obj.read() + except IOError, e: + if e.errno == errno.EINTR: + continue + else: + raise + # # Generic tests # @@ -123,7 +134,7 @@ p = subprocess.Popen([sys.executable, "-c", 'import sys; sys.stdout.write("orange")'], stdout=subprocess.PIPE) - self.assertEqual(p.stdout.read(), "orange") + self.assertEqual(self.read_no_intr(p.stdout), "orange") def test_stdout_filedes(self): # stdout is set to open file descriptor @@ -151,7 +162,7 @@ p = subprocess.Popen([sys.executable, "-c", 'import sys; sys.stderr.write("strawberry")'], stderr=subprocess.PIPE) - self.assertEqual(remove_stderr_debug_decorations(p.stderr.read()), + self.assertEqual(remove_stderr_debug_decorations(self.read_no_intr(p.stderr)), "strawberry") def test_stderr_filedes(self): @@ -186,7 +197,7 @@ 'sys.stderr.write("orange")'], stdout=subprocess.PIPE, stderr=subprocess.STDOUT) - output = p.stdout.read() + output = self.read_no_intr(p.stdout) stripped = remove_stderr_debug_decorations(output) self.assertEqual(stripped, "appleorange") @@ -220,7 +231,7 @@ stdout=subprocess.PIPE, cwd=tmpdir) normcase = os.path.normcase - self.assertEqual(normcase(p.stdout.read()), normcase(tmpdir)) + self.assertEqual(normcase(self.read_no_intr(p.stdout)), normcase(tmpdir)) def test_env(self): newenv = os.environ.copy() @@ -230,7 +241,7 @@ 'sys.stdout.write(os.getenv("FRUIT"))'], stdout=subprocess.PIPE, env=newenv) - self.assertEqual(p.stdout.read(), "orange") + self.assertEqual(self.read_no_intr(p.stdout), "orange") def test_communicate(self): p = subprocess.Popen([sys.executable, "-c", @@ -305,7 +316,8 @@ 'sys.stdout.write("\\nline6");'], stdout=subprocess.PIPE, universal_newlines=1) - stdout = p.stdout.read() + + stdout = self.read_no_intr(p.stdout) if hasattr(open, 'newlines'): # Interpreter with universal newline support self.assertEqual(stdout, @@ -343,7 +355,7 @@ def test_no_leaking(self): # Make sure we leak no resources - max_handles = 1026 # too much for most UNIX systems + max_handles = 10 # too much for most UNIX systems if mswindows: max_handles = 65 # a full test is too slow on Windows for i in range(max_handles): @@ -424,7 +436,7 @@ 'sys.stdout.write(os.getenv("FRUIT"))'], stdout=subprocess.PIPE, preexec_fn=lambda: os.putenv("FRUIT", "apple")) - self.assertEqual(p.stdout.read(), "apple") + self.assertEqual(self.read_no_intr(p.stdout), "apple") def test_args_string(self): # args is a string @@ -457,7 +469,7 @@ p = subprocess.Popen(["echo $FRUIT"], shell=1, stdout=subprocess.PIPE, env=newenv) - self.assertEqual(p.stdout.read().strip(), "apple") + self.assertEqual(self.read_no_intr(p.stdout).strip(), "apple") def test_shell_string(self): # Run command through the shell (string) @@ -466,7 +478,7 @@ p = subprocess.Popen("echo $FRUIT", shell=1, stdout=subprocess.PIPE, env=newenv) - self.assertEqual(p.stdout.read().strip(), "apple") + self.assertEqual(self.read_no_intr(p.stdout).strip(), "apple") def test_call_string(self): # call() function with string argument on UNIX @@ -525,7 +537,7 @@ p = subprocess.Popen(["set"], shell=1, stdout=subprocess.PIPE, env=newenv) - self.assertNotEqual(p.stdout.read().find("physalis"), -1) + self.assertNotEqual(self.read_no_intr(p.stdout).find("physalis"), -1) def test_shell_string(self): # Run command through the shell (string) @@ -534,7 +546,7 @@ p = subprocess.Popen("set", shell=1, stdout=subprocess.PIPE, env=newenv) - self.assertNotEqual(p.stdout.read().find("physalis"), -1) + self.assertNotEqual(self.read_no_intr(p.stdout).find("physalis"), -1) def test_call_string(self): # call() function with string argument on Windows /Peter Åstrand <astrand(a)lysator.liu.se>

11 years

Plea to distribute debugging lib

by David Abrahams

For years, Boost.Python has been doing some hacks to work around the fact that a Windows Python distro doesn't include the debug build of the library. http://www.boost.org/libs/python/doc/building.html#variants explains. We wanted to make it reasonably convenient for Windows developers (and our distributed testers) to work with a debug build of the Boost.Python library and of their own code. Having to download the Python source and build the debug DLL was deemed unacceptable. Well, those hacks have run out of road. VC++8 now detects that some of its headers have been #included with _DEBUG and some without, and it will refuse to build anything when it does. We have several new hacks to work around that detection, and I think we _might_ be able to get away with them for one more release. But it's really time to do it right. MS is recommending that we (Boost) start distributing a debug build of the Python DLL with Boost, but Boost really seems like the wrong place to host such a thing. Is there any way Python.org can make a debug build more accessible? Thanks, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com

13 years, 8 months

FishEye on Python CVS Repository

by Peter Moore

Greetings Python Developers, I'm responsible for setting up free FishEye hosting for community projects. As a long time python user I of course added Python up front. You can see it here: http://fisheye.cenqua.com/viewrep/python/ If you aren't familiar with FishEye, it is a repository browsing, searching, analysis, monitoring..., tool for CVS (SVN coming soon). Cool features include: RSS feeds http://fisheye.cenqua.com/changelog/%7Erss/python/rss.xml Synthetic changesets http://fisheye.cenqua.com/changelog/python/ and Pretty ediffs http://fisheye.cenqua.com/viewrep/python/python/nondist/peps/pep-0343.txt?r… SQL like search http://fisheye.cenqua.com/search/python/?ql= Note that normally FishEye is pretty close to real time (i.e. when run on a local repository), but we can only get SF updates once a day, and they are potentially a bit old when we grab them. Feel free to mail me direct pete _at_ cenqua _dot_ com if you want to tweak the python instance or have any other questions/comments not appropriate for this list. Cheers, Pete. --- +61-414-587637 www.cenqua.com/fisheye

14 years

pdb: should next command be extended?

by Ilya Sandler

Problem: When the code contains list comprehensions (or for that matter any other looping construct), the only way to get quickly through this code in pdb is to set a temporary breakpoint on the line after the loop, which is inconvenient.. There is a SF bug report #1248119 about this behavior. Solution: Should pdb's next command accept an optional numeric argument? It would specify how many actual lines of code (not "line events") should be skipped in the current frame before stopping, i.e "next 5" would mean stop when line>=line_where_next_N_happened+5 is reached. This would allow to easily get over/out of loops in the debugger What do you think? Ilya

14 years, 2 months

[ python-Patches-790710 ] breakpoint command lists in pdb

by Grégoire Dooms

Hello, This patch is about to celebrate its second birthday :-) https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_i… It seems from the comments that the feature is nice but the implementation was not OK. I redid the implem according to the comments. What should I do to get it reviewed further ? (perhaps just this : posting to python-dev :-) Best, -- Grégoire

14 years, 2 months

problem installing current cvs

by Irmen de Jong

Hi, I'm having 2 problems with the current cvs : During compilation this warning occurs: *** WARNING: renaming "dbm" since importing it failed: build/lib.linux-i686-2.5/ dbm.so: undefined symbol: dbm_firstkey and the 'dbm' module is unavailable. I'm running MandrakeLinux 2005 (10.2) gcc 3.4.3 (I'm also having this problem when compiling python 2.3.5 or 2.4.1) furthermore the 'make install' of current cvs fails halfway trough with the following errors: ..... ..... Compiling /opt/python25/lib/python2.5/bsddb/test/test_associate.py ... Sorry: TabError: ('inconsistent use of tabs and spaces in indentation', ('/opt/python25/lib/python2.5/bsddb/test/test_associate.py', 97, 23, '\t os.mkdir(homeDir)\n')) Compiling /opt/python25/lib/python2.5/bsddb/test/test_basics.py ... Sorry: TabError: ('inconsistent use of tabs and spaces in indentation', ('/opt/python25/lib/python2.5/bsddb/test/test_basics.py', 400, 26, '\t if get_raises_error:\n')) Compiling /opt/python25/lib/python2.5/bsddb/test/test_compare.py ... Sorry: TabError: ('inconsistent use of tabs and spaces in indentation', ('/opt/python25/lib/python2.5/bsddb/test/test_compare.py', 167, 5, '\t"""\n')) ..... ..... Compiling /opt/python25/lib/python2.5/bsddb/test/test_recno.py ... Sorry: TabError: ('inconsistent use of tabs and spaces in indentation', ('/opt/python25/lib/python2.5/bsddb/test/test_recno.py', 38, 46, '\tget_returns_none = d.set_get_returns_none(2)\n')) ..... ..... make: *** [libinstall] Error 1 $ And then it quits. Fixing the tab indentation errors locally makes the problem go away. Regards, Irmen de Jong

14 years, 2 months

Re: [Python-Dev] GCC version compatibility

by David Abrahams

[Christoph, please keep the python-dev list in the loop here, at least until they get annoyed and decide we're off-topic. I think this is crucial to the way they package and deliver Python] Christoph Ludwig <cludwig(a)cdc.informatik.tu-darmstadt.de> writes: > On Thu, Jul 07, 2005 at 06:27:46PM -0400, David Abrahams wrote: >> "Martin v. Löwis" <martin(a)v.loewis.de> writes: >> >> > David Abrahams wrote: >> >> I'm wondering if there has been a well-known recent change either in Python >> >> or GCC that would account for these new reports. Any relevant >> >> information would be appreciated. > [...] >> > Python is linked with g++ if configure thinks this is necessary >> >> Right. The question is, when should configure "think it's necessary?" > > Just to add to the confusion... I encountered the case that configure decided > to use gcc for linking but it should have used g++. (It is Python > PR #1189330 <http://tinyurl.com/dlheb>. This was on a x86 Linux system with > g++ 3.4.2.) > > Background: The description of --with-cxx in the README of the > Python 2.4.1 source distribution made me think that I need to > configure my Python installation with > --with-configure=/opt/gcc/gcc-3.4.2/bin/g++ if I plan to use C++ > extensions built with this compiler. (That was possibly a > misunderstanding on my part, AFAICT, yes. > but Python should build with this option anyway.) > > configure set `LINKCC=$(PURIFY) $(CC)'. The result was that make failed when > linking the python executable due to an unresolved reference to > __gxx_personality_v0. I had to replace CC by CXX in the definition of LINKCC > to finish the build of Python. > > When I looked into this problem I saw that configure in fact builds a test > executable that included an object file compiled with g++. If the link step > with gcc succeeds then LINKCC is set as above, otherwise CXX is > used. Obviously, on my system this test was successful so configure decided > to link with gcc. However, minimal changes to the source of the test program > caused the link step to fail. It was not obvious to me at all why the latter > source code should cause a dependency on the C++ runtime if the original > code does not. My conclusion was that this test is fragile and should be > skipped. Sounds like it. I have never understood what the test was really checking for since the moment it was first described to me, FWIW. > If Python is built with --with-cxx then it should be linked with CXX > as well. U betcha. > I gather from posts on the Boost mailing lists that you can import > Boost.Python extensions even if Python was configured > --without-cxx. Yes, all the tests are passing that way. > (On ELF based Linux/x86, at least.) That leaves me wondering > > * when is --with-cxx really necessary? I think it's plausible that if you set sys.dlopenflags to share symbols it *might* end up being necessary, but IIRC Ralf does use sys.dlopenflags with a standard build of Python (no --with-cxx)... right, Ralf? > * what happens if I import extensions built with different g++ versions? Will > there be a conflict between the different versions of libstdc++ those > extensions depend on? Not unless you set sys.dlopenflags to share symbols. It's conceivable that they might conflict through their shared use of libboost_python.so, but I think you have to accept that an extension module and the libboost_python.so it is linked with have to be built with compatible ABIs anyway. So in that case you may need to make sure each group of extensions built with a given ABI use their own libboost_python.so (or just link statically to libboost_python.a if you don't need cross-module conversions). HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com

14 years, 2 months

PythonCore\CurrentVersion

by "Martin v. Löwis"

What happened to the CurrentVersion registry entry documented at http://www.python.org/windows/python/registry.html AFAICT, even the python15.wse file did not fill a value in this entry (perhaps I'm misinterpreting the wse file, though). So was this ever used? Why is it documented, and who documented it (unfortunately, registry.html is not in cvs/subversion, either)? Regards, Martin

14 years, 3 months

problem with genexp

by Neal Norwitz

There's a problem with genexp's that I think really needs to get fixed. See http://python.org/sf/1167751 the details are below. This code: >>> foo(a = i for i in range(10)) generates "NameError: name 'i' is not defined" when run because: 2 0 LOAD_GLOBAL 0 (foo) 3 LOAD_CONST 1 ('a') 6 LOAD_GLOBAL 1 (i) 9 CALL_FUNCTION 256 12 POP_TOP 13 LOAD_CONST 0 (None) 16 RETURN_VALUE If you add parens around the code: foo(a = i for i in range(10)) You get something quite different: 2 0 LOAD_GLOBAL 0 (foo) 3 LOAD_CONST 1 ('a') 6 LOAD_CONST 2 (<code object <generator expression> at 0x2a960baae8, file "<stdin>", line 2>) 9 MAKE_FUNCTION 0 12 LOAD_GLOBAL 1 (range) 15 LOAD_CONST 3 (10) 18 CALL_FUNCTION 1 21 GET_ITER 22 CALL_FUNCTION 1 25 CALL_FUNCTION 256 28 POP_TOP 29 LOAD_CONST 0 (None) 32 RETURN_VALUE I agree with the bug report that the code should either raise a SyntaxError or do the right thing. n

14 years, 4 months

Fwd: [Python-checkins] commit of r41497 - python/trunk/Lib/test

by Neal Norwitz

I just checked in the modification below. I'm not sure if this behaviour is on purpose or by accident. Do we want to support hex values in floats? Do we want to support p, similar to e in floats? Here are the lines from the test: + self.assertEqual(float(" 0x3.1 "), 3.0625) + self.assertEqual(float(" -0x3.p-1 "), -1.5) n ---------- Forwarded message ---------- From: neal.norwitz(a)python.org <neal.norwitz(a)python.org> Date: Nov 21, 2005 9:17 PM Subject: [Python-checkins] commit of r41497 - python/trunk/Lib/test To: python-checkins(a)python.org Author: neal.norwitz Date: Tue Nov 22 06:17:40 2005 New Revision: 41497 Modified: python/trunk/Lib/test/test_builtin.py Log: improve test coverage in Python/pystrtod.c and Python/mystrtoul.c. Modified: python/trunk/Lib/test/test_builtin.py ============================================================================== --- python/trunk/Lib/test/test_builtin.py (original) +++ python/trunk/Lib/test/test_builtin.py Tue Nov 22 06:17:40 2005 @@ -545,6 +545,34 @@ self.assertEqual(float(unicode(" 3.14 ")), 3.14) self.assertEqual(float(unicode(" \u0663.\u0661\u0664 ",'raw-unicode-escape')), 3.14) + def test_float_with_comma(self): + # set locale to something that doesn't use '.' for the decimal point + try: + import locale + orig_locale = locale.setlocale(locale.LC_NUMERIC, '') + locale.setlocale(locale.LC_NUMERIC, 'fr_FR') + except: + # if we can't set the locale, just ignore this test + return + + try: + self.assertEqual(locale.localeconv()['decimal_point'], ',') + except: + # this test is worthless, just skip it and reset the locale + locale.setlocale(locale.LC_NUMERIC, orig_locale) + return + + try: + self.assertEqual(float(" 3,14 "), 3.14) + self.assertEqual(float(" +3,14 "), 3.14) + self.assertEqual(float(" -3,14 "), -3.14) + self.assertEqual(float(" 0x3.1 "), 3.0625) + self.assertEqual(float(" -0x3.p-1 "), -1.5) + self.assertEqual(float(" 25.e-1 "), 2.5) + self.assertEqual(fcmp(float(" .25e-1 "), .025), 0) + finally: + locale.setlocale(locale.LC_NUMERIC, orig_locale) + def test_floatconversion(self): # Make sure that calls to __float__() work properly class Foo0: @@ -682,6 +710,7 @@ self.assertRaises(TypeError, int, 1, 12) self.assertEqual(int('0123', 0), 83) + self.assertEqual(int('0x123', 16), 291) def test_intconversion(self): # Test __int__() _______________________________________________ Python-checkins mailing list Python-checkins(a)python.org http://mail.python.org/mailman/listinfo/python-checkins

14 years, 6 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev November 2005