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>
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
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
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
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.
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 +--------------------------------------+
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
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/
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!
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/
