Python-Dev May 2005

python-dev@python.org

98 participants
115 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, 3 months

Multiple interpreters not compatible with current thread module

by Jeremy Maxfield

The current threadmodule.c does not seem to correctly support multiple (sub) interpreters. This became apparent when using jep - (a Java/Python bridge) and also seems to cause problems with mod_python. The incompatibility began in Python version 2.3.5 and has been traced to changes to the 2.4 threadmodule.c that were backported to the 2.3 delivery. A bug report was raised on 2005-03-15 (http://sourceforge.net/tracker/index.php?func=detail&aid=1163563&group_id=5…) which covers the problem in more detail. I've just submitted a patch (I hope it's correctly formatted) for threadmodule.c (http://sourceforge.net/tracker/index.php?func=detail&aid=1203393&group_id=5…) adapted from the pre-2.3.5 threadmodule.c (replacing the PyGILState_XXX calls with those from the earlier thread module). The patch works correctly but it will probably re-introduce the problem that the change for threadmodule.c version 2.59 fixed.("Fix for [ 1010677 ] thread Module Breaks PyGILState_Ensure(),and a test case.When booting a new thread, use the PyGILState API to manage the GIL."). The documentation (http://docs.python.org/api/threads.html) states "Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. ", so it looks like that using the PyGilState_XXX functions in the core threadmodule.c means the Py_NewInterpreter() call (i.e. multiple interpreters) is no longer supported when threads are involved. This problem is preventing us upgrading to Python 2.4 so we'd obviously like to see a resolution the next Python release if that were possible... Cheers, Max

15 years, 4 months

Split MIME headers into multiple lines near a space

by Noam Raphael

Hello, I recently used Python to automatically send messages to my gmail account. I was surprised to find out that some of the words in the subjects of messages were split by a space character which came from nowhere. It turns out that the international (Hebrew) subject was split into multiple lines by the email package, sometimes in the middle of words. Gmail treats these line breaks as spaces, so words gets cut into two. I've checked, and there are email clients which ignore the line breaks, so the subject looks ok. I added four lines to the _binsplit function of email.Header, so that if there is a space character in the string, it will be splitted there. This fixes the problem, and subjects look fine again. These four lines (plus a comment which I wrote) are: # Try to find a place in splittable[:i] which is near a space, # and split there, so that clients which interpret the line break # as a separator won't insert a space in the middle of a word. if splittable[i:i+1] != ' ': spacepos = splittable.rfind(' ', 0, i) if spacepos != -1: i = spacepos + 1 These lines should be added before the last three lines of _binsplit. Do you think it's ok? Could this be added to email.Header? (Should I send this as a patch? It's just that the patch list was full of IDLE patches, and this change is really small, so I thought that it would be easier to post it here. Please tell me if I was wrong.) Thank you, Noam Raphael

15 years, 4 months

AST manipulation and source code generation

by Ka-Ping Yee

Would there be any interest in extending the compiler package with tools for AST transformations and for emitting Python source code from ASTs? I was experimenting with possible translations for exception chaining and wanted to run some automated tests, so i started playing around with the compiler package to do source-to-source transformations. Then i started working on a way to do template-based substitution of ASTs and a way to spit source code back out, and i'm wondering if that might be good for experimenting with future Python features. (If there's already stuff out there for doing this, let me know -- i don't intend to duplicate existing work.) -- ?!ng

15 years, 4 months

Closing old bugs

by Raymond Hettinger

There should be some greater care exercised in closing old bugs. Marking them "deprecated" and then erasing them is only a good strategy if we have no means of reproducing the error or ascertaining what the OP was talking about. For instance, in www.python.org/sf/640553 , it was possible for a reviewer to directly verify whether usr/local local was still being used in setup.py. Likewise, www.python.org/sf/728515 should not have been closed (Martin's post could have been taken as a clue that the bug was valid and simply waiting for some volunteer to submit a patch). Old age and a missing OP is not sufficient reason to close a bug. If the report is clear and the bug is potentially still valid, it should be left open. Efforts to clear old bugs should focus on fixing them or making a conscious Won't Fix decision (with old age possibly indicating that there is not a real problem in practice). Raymond P.S. When setting a time deadline for an OP to respond, we should use some terminology other than "deprecated". The word doesn't fit well and can be confused with the unrelated topic of module or feature deprecation.

15 years, 4 months

Re: [Python-Dev] Adventures with Decimal

by Greg Ewing

Raymond Hettinger wrote: > IMO, user input (or > the full numeric strings in a text data file) is sacred and presumably > done for a reason -- the explicitly requested digits should not be > throw-away without good reason. I still don't understand what's so special about the input phase that it should be treated sacredly, while happily desecrating the result of any *other* operation. To my mind, if you were really serious about treating precision as sacred, the result of every operation would be the greater of the precisions of the inputs. That's what happens in C or Fortran - you add two floats and you get a float; you add a float and a double and you get a double; etc. > Truncating/rounding a > literal at creation time doesn't work well when you are going to be > using those values several times, each with a different precision. This won't be a problem if you recreate the values from strings each time. You're going to have to be careful anyway, e.g. if you calculate some constants, such as degreesToRadians = pi/180, you'll have to make sure that you recalculate them with the desired precision before rerunning the algorithm. > Remember, the design documents for the spec state a general principle: > the digits of a decimal value are *not* significands, rather they are > exact and all arithmetic on the is exact with the *result* being subject > to optional rounding. I don't see how this is relevant, because digits in a character string are not "digits of a decimal value" according to what we are meaning by "decimal value" (i.e. an instance of Decimal). In other words, this principle only applies *after* we have constructed a Decimal instance. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg.ewing(a)canterbury.ac.nz +--------------------------------------+

15 years, 4 months

PEP 342/343 status?

by Brett C.

Been rather quite around here lately so I just wanted to do a quick check to see what the status is on PEPs 342 and 343. I noticed Nick's PEP is still not up. Probably too busy with that fix for genexps in the AST branch, huh, Nick? =) Guido, you need something hashed out from us at this point, or do you have this all settled in your head and are just waiting for time to lock it down in the PEP? Or should the PEPs be changed from draft to final and an implementation (which I am *not* volunteering for =) is now needed? -Brett

15 years, 4 months

Old Python version categories in Bug Tracker

by Facundo Batista

People: As the process of deprecating old bugs evolves, the following categories got empty: Python 2.1.1 Python 2.1.2 Python 2.2.1 Python 2.2.1 candidate Python 2.2.2 The SF interface doesn't allow to delete old categories, but maybe we could ask SF support to do it, as nowadays doesn't make sense to open a bug in these categories. As an infortunate example, somebody opened today a bug in the "Python 2.2" category, :( What do you think? Thanks. . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

15 years, 4 months

Request for dev permissions

by Reinhold Birkenfeld

Hello, would anybody mind if I was given permissions on the tracker and CVS, for fixing small things like bug #1202475. I feel that I can help you others out a bit with this and I promise I won't change the interpreter to accept braces... Reinhold -- Mail address is perfectly valid!

15 years, 4 months

Deprecating old bugs, now from 2.2.2

by Facundo Batista

Going on with the old bugs checking, here are the results for 2.2.2 (and one from 2.2.1). When I'll finish this will be put in an informational PEP. When I verified the bug, I filled two fields: - Summary: the same subject as in SF - Group: the bug's group at verifying time. - Bug #: the bug number - Verified: is the date when I checked the bug. - Action: is what I did then. If the bug survived the verification, the next two fields are applicable (if not, I put a dash, the idea is to keep this info easily parseable): - Final: is the action took by someone who eliminated the bug from that category (closed, moved to Py2.4, etc). - By: is the someone who did the final action. So, here's the info... Summary: Python Interpreter shell is crashed Group: 2.2.2 Bug #: 1100673 Verified: 15-Jan-2005 Action: Deprecation alerted. Works ok for me. Final: Closed. Rejected. By: mwh Summary: popen3 under threads reports different stderr results Group: 2.2.2 Bug #: 856706 Verified: 15-Jan-2005 Action: Closed as duplicate of #853411 Final: - By: - Summary: CGIHTTPServer cannot manage cgi in sub directories Group: 2.2.2 Bug #: 778804 Verified: 15-Jan-2005 Action: Closing as Fixed (was fixed already). Final: - By: - Summary: popen does not like filenames with spaces Group: 2.2.2 Bug #: 774546 Verified: 15-Jan-2005 Action: Deprecation alerted. Should be closed with "Won't fix" specially now that we have the subprocess module. Final: Closed. Out of date. By: rhettinger Summary: popen4 doesn't close filedescriptors when in Threads Group: 2.2.2 Bug #: 768649 Verified: 15-Jan-2005 Action: Deprecation alerted. Works ok for me. Final: Closed: Won't fix. By: facundobatista Summary: Sudden death with SIGSEGV in RtlEnterCriticalSection Group: 2.2.2 Bug #: 763190 Verified: 15-Jan-2005 Action: Deprecation alerted. Don't have the context to try it. Final: Closed: Won't fix. By: facundobatista Summary: can't CNTRL-C when running os.system in a thread Group: 2.2.2 Bug #: 756940 Verified: 15-Jan-2005 Action: Deprecation alerted. There's other bug similar to this (#756924) and a patch for it (that has been accepted), but can't try it right now. Final: Closed: Won't fix. By: facundobatista Summary: Calling socket.recv() with a large number breaks Group: 2.2.2 Bug #: 756104 Verified: 15-Jan-2005 Action: Changed to Py2.4. The bug is still there (but in the documentation). Final: - By: - Summary: ftplib.retrbinary fails when called from retrlines callback Group: 2.2.2 Bug #: 751758 Verified: 15-Jan-2005 Action: Changed to Py2.4. The bug is still there. Final: - By: - Summary: CGIHTTPServer does not handle scripts in sub-dirs Group: 2.2.2 Bug #: 737202 Verified: 15-Jan-2005 Action: Deprecation alerted. There's a patch, but actual code has something very similar to it, don't have the context to try if it's fixed. Final: Changed to Py2.4. The bug is still there. By: facundobatista Summary: socketmodule.c: inet_pton() expects 4-byte packed_addr Group: 2.2.2 Bug #: 730222 Verified: 15-Jan-2005 Action: Deprecation alerted. Don't have the context to see if it's already solved (there's a not-applied patch). Final: Closed: Won't fix. By: facundobatista Summary: mmap's resize method resizes the file in win32 but not unix Group: 2.2.2 Bug #: 728515 Verified: 15-Jan-2005 Action: Deprecation alerted. Don't know enough about it to check ir or reproduce it. Final: Closed: Won't fix. By: facundobatista Summary: Core Dumps : Python2.2.2 Group: 2.2.2 Bug #: 727241 Verified: 15-Jan-2005 Action: Deprecation alerted. Not sure if it's a Python or IRIX bug. Final: Closed: Won't fix. By: facundobatista Summary: inspect, class instances and __getattr__ Group: 2.2.2 Bug #: 718532 Verified: 15-Jan-2005 Action: Deprecation alerted. Not sure if there's a bug. Final: Changed to Py2.4. By: facundobatista Summary: "build_ext" "libraries" subcommand not s Group: 2.2.2 Bug #: 716634 Verified: 15-Jan-2005 Action: Deprecation alerted. Not sure if there's a bug. Final: Closed: Won't fix. By: facundobatista Summary: SEEK_{SET,CUR,END} missing in 2.2.2 Group: 2.2.2 Bug #: 711830 Verified: 15-Jan-2005 Action: Deprecation alerted. Not sure if there's a bug. Final: Closed. Fixed. By: loewis Summary: codecs.open and iterators Group: 2.2.2 Bug #: 706595 Verified: 15-Jan-2005 Action: Deprecation alerted. Couldn't reproduce the problem, don't know enough about the subject to be sure if it's a bug or not. Final: Closed. Out of date. By: doerwalter Summary: test_atexit fails in directories with spaces Group: 2.2.2 Bug #: 705792 Verified: 15-Jan-2005 Action: Closing as Fixed (was fixed already). Final: - By: - Summary: --without-cxx flag of configure isn't documented. Group: 2.2.2 Bug #: 702147 Verified: 15-Jan-2005 Action: Deprecation alerted. The offerent never send the proposed patch for docs, really not clear if there's something to be fixed. Final: Closed. Out of date. By: bcannon Summary: Thread running (os.system or popen#) Group: 2.2.2 Bug #: 701836 Verified: 15-Jan-2005 Action: Deprecation alerted. Works ok for me. Final: Closed: Won't fix. By: facundobatista Summary: Canvas origin is off-canvas in create_<item>(). Worka Group: 2.2.2 Bug #: 700650 Verified: 15-Jan-2005 Action: Deprecation alerted. Missing attached file, depend on that to verify the bug. Final: Closed: Won't fix. By: facundobatista Summary: Canvas Widget origin is off-screen Group: 2.2.2 Bug #: 699816 Verified: 15-Jan-2005 Action: Deprecation alerted. Missing attached file, depend on that to verify the bug. Final: Closed: Won't fix. By: facundobatista Summary: imaplib: parsing INTERNALDATE Group: 2.2.2 Bug #: 698706 Verified: 15-Jan-2005 Action: Changed to Py2.4. The bug is still there. Final: - By: - Summary: _iscommand() in webbrowser module Group: 2.2.2 Bug #: 687747 Verified: 15-Jan-2005 Action: Deprecation alerted. Don't have the context to try it. Final: Changed to Py2.3. By: facundobatista Summary: Profilier hooked into SystemExit Group: 2.2.2 Bug #: 687297 Verified: 11-Jan-2005 Action: Deprecation alerted. Don't have the context to try it. Final: Closed: Won't fix. By: facundobatista Summary: Incorrect permissions set in lib-dynload. Group: 2.2.2 Bug #: 680379 Verified: 11-Jan-2005 Action: Deprecation alerted. Don't have the context to try it. Final: Closed: Fixed. By: facundobatista Summary: String formatting operation Unicode problem. Group: 2.2.2 Bug #: 676346 Verified: 11-Jan-2005 Action: Deprecation alerted. Don't know enough about it to be sure if it's really a bug. Final: Closed: Fixed. By: facundobatista Summary: Py_Main() does not perform to spec Group: 2.2.2 Bug #: 672035 Verified: 11-Jan-2005 Action: Closing it, put in "Fixed" previously but still was "Open". Final: - By: - Summary: os.popen+() can take string list and bypass shell. Group: 2.2.2 Bug #: 666700 Verified: 11-Jan-2005 Action: Deprecation alerted. Not sure if there's a bug. Final: Closed: Fixed. By: facundobatista Summary: doctest and exception messages Group: 2.2.2 Bug #: 654783 Verified: 11-Jan-2005 Action: Deprecation alerted. Not sure if there's a bug. Final: Closed: Won't fix. By: facundobatista Summary: for lin in file: file.tell() tells wrong Group: 2.2.2 Bug #: 645594 Verified: 11-Jan-2005 Action: Closed because of #1036626 rationale. Final: - By: - Summary: Misuse of /usr/local/in setup.py Group: 2.2.2 Bug #: 640553 Verified: 08-Jan-2005 Action: Deprecation alerted. Because of the bug discussion is not clear to me if the problem actually existed. Final: Closed: Won't fix. By: facundobatista Summary: crash (SEGV) in Py_EndInterpreter() Group: 2.2.2 Bug #: 639611 Verified: 08-Jan-2005 Action: Deprecation alerted. Don't know enough about the subject to be able to reproduce the issue. Final: Closed: Works for me. By: jlgijsbers Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Group: 2.2.2 Bug #: 632323 Verified: 27-Dec-2004 Action: Deprecation alerted. Don't know what to do with this one. It's marked as Invalid but still Open, and it's not clear to me if was a bug, is still a bug, or any of both. Final: Changed to Py2.3. By: facundobatista Summary: test_signal hangs -- signal broken on OpenBSD? Group: 2.2.1 candidate Bug #: 549081 Verified: 26-Dic-2004 Action: Deprecation alerted. I can not try it, don't have that context. For a comment maybe it's already fixed. Final: Closed: Won't fix. By: facundobatista Regards, . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

15 years, 4 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 May 2005