[ python-Bugs-713169 ] test_pty fails on HP-UX and AIX when run after test_openpty
Bugs item #713169, was opened at 2003-04-01 07:35
Message generated for change (Comment added) made by mlorenzen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713169&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_pty fails on HP-UX and AIX when run after test_openpty
Initial Comment:
Here is the output from test_pty.py:
capulet:dist/src > ./python Lib/test/test_pty.py
Calling master_open()
Got master_fd '3', slave_name '/dev/pts/0'
Calling slave_open('/dev/pts/0')
Got slave_fd '4'
Traceback (most recent call last):
File "Lib/test/test_pty.py", line 58, in ?
test_basic_pty()
File "Lib/test/test_pty.py", line 29, in
test_basic_pty
if not os.isatty(slave_fd):
File "Lib/test/test_pty.py", line 50, in handle_sig
raise TestFailed, "isatty hung"
test.test_support.TestFailed: isatty hung
This was running Python 2.3a2 (downloaded from
CVS on Sunday 30th March) built on HP-UX11i.
--
Comment By: Mark Lorenzen (mlorenzen)
Date: 2006-03-07 12:32
Message:
Logged In: YES
user_id=1469902
I have the same problem with Python 2.4.2 running on AIX 5.2.
The test test_pty hangs for 10 seconds after which it is
aborted by a time-out condition. I have traced the system
calls and it turns out that the following scenario occurs:
1) os.write(slave_fd, TEST_STRING_2[:5])
2) os.write(slave_fd, TEST_STRING_2[5:])
3) s2 = os.read(master_fd, 1024)
[...]
4) os.close(slave_fd)
At 3) we only read the first part of the string written in
1) and not the complete string written in both 1) and 2).
The close() call then hangs in 4) (as it is waiting for
slave_fd to be flushed?).
The solution is to continue reading until a newline
character is read ie. readling a complete line. The patch is
shown below.
*** Lib/test/test_pty.py.orig 2004-02-12 7:35:11.0
+
--- Lib/test/test_pty.py2006-03-07 2:05:39.0
+
***
*** 40,47
debug("Writing chunked output")
os.write(slave_fd, TEST_STRING_2[:5])
os.write(slave_fd, TEST_STRING_2[5:])
! s2 = os.read(master_fd, 1024)
! sys.stdout.write(s2.replace("\r\n", "\n"))
os.close(slave_fd)
os.close(master_fd)
--- 40,49
debug("Writing chunked output")
os.write(slave_fd, TEST_STRING_2[:5])
os.write(slave_fd, TEST_STRING_2[5:])
! s2 = "";
! while not s2 or s2[-1] != "\n":
! s2 = s2 + os.read(master_fd, 1024)
! sys.stdout.write(s2.replace("\r\n", "\n"));
os.close(slave_fd)
os.close(master_fd)
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-20 19:05
Message:
Logged In: YES
user_id=33168
Can you test with the patch in bug report:
https://sourceforge.net/tracker/index.php?func=detail&aid=1433877&group_id=5470&atid=105470
? I wonder if that fixes the problem. Though I'm not sure
the same code is executed or not.
--
Comment By: Michael Hoffman (hoffmanm)
Date: 2005-01-25 16:29
Message:
Logged In: YES
user_id=987664
This happens with Python 2.4 on Tru64Unix V5.1 when
compiling using gcc-3.4.3, but not if you use the vendor cc.
--
Comment By: Richard Townsend (rptownsend)
Date: 2004-07-12 08:30
Message:
Logged In: YES
user_id=200117
This still happens with Python-2.4.0a1 on HP-UX11i
--
Comment By: Mark D. Roth (mdr0)
Date: 2004-03-10 17:22
Message:
Logged In: YES
user_id=994239
I'm running into this problem under both AIX 4.3.3 and 5.1.
Is this going to cause a problem if I put python into
produciton, or is it "safe" to ignore it?
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 16:31
Message:
Logged In: YES
user_id=33168
Actually, there is a 'fix' which is really a work-around the
problem. You can disable os.openpty() in pty.master_open.
I added a raise OSError at line 50 (before os.openpty()).
This allows the test to pass. I think Martin and I agreed
that globally disabling wasn't the best solution. That
would probably be in some patch.
Also, just in case it isn't clear--if you run test_pty
BEFORE test_openpty, both tests pass.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 16:02
Message:
Logged In: YES
user_id=33168
I fixed the test hanging, but not the actual bug. The bug
appea
[ python-Bugs-1432525 ] os.listdir doesn't release GIL
Bugs item #1432525, was opened at 2006-02-15 22:45 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jonathan Ellis (ellisj) Assigned to: Georg Brandl (gbrandl) Summary: os.listdir doesn't release GIL Initial Comment: posix_listdir in posixmodule.c does not release the global interpreter lock, blocking all other threads for the duration of the call. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-07 12:48 Message: Logged In: YES user_id=849994 Committed as rev. 42884. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-03 17:48 Message: Logged In: YES user_id=21627 The patch looks fine. Please apply. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-18 11:13 Message: Logged In: YES user_id=1188172 Attaching a patch. Please check. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1442012 ] Traceback in pydoc
Bugs item #1442012, was opened at 2006-03-02 20:04 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442012&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Traceback in pydoc Initial Comment: On some objects I have, calling 'help(obj)' raises an exception. Python 2.4.2, Windows XP. This is the traceback, together with some info from pdb.pm(): >>> help(r) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\site.py", line 328, in __call__ return pydoc.help(*args, **kwds) File "c:\python24\lib\pydoc.py", line 1647, in __call__ self.help(request) File "c:\python24\lib\pydoc.py", line 1691, in help else: doc(request, 'Help on %s:') File "c:\python24\lib\pydoc.py", line 1475, in doc pager(title % desc + '\n\n' + text.document(object, name)) File "c:\python24\lib\pydoc.py", line 296, in document if inspect.isclass(object): return self.docclass(*args) File "c:\python24\lib\pydoc.py", line 1193, in docclass lambda t: t[1] == 'method') File "c:\python24\lib\pydoc.py", line 1143, in spill name, mod, object)) File "c:\python24\lib\pydoc.py", line 301, in document return self.docother(*args) File "c:\python24\lib\pydoc.py", line 1290, in docother chop = maxlen - len(line) TypeError: unsupported operand type(s) for -: '_compointer_meta' and 'int' >>> import pdb >>> pdb.pm() > c:\python24\lib\pydoc.py(1290)docother() -> chop = maxlen - len(line) (Pdb) args self = object = name = Item mod = None maxlen = doc = None (Pdb) where (1)?() c:\python24\lib\site.py(328)__call__() -> return pydoc.help(*args, **kwds) c:\python24\lib\pydoc.py(1647)__call__() -> self.help(request) c:\python24\lib\pydoc.py(1691)help() -> else: doc(request, 'Help on %s:') c:\python24\lib\pydoc.py(1477)doc() -> print value c:\python24\lib\pydoc.py(299)document() -> pass c:\python24\lib\pydoc.py(1193)docclass() -> lambda t: t[1] == 'method') c:\python24\lib\pydoc.py(1143)spill() -> name, mod, object)) c:\python24\lib\pydoc.py(301)document() -> return self.docother(*args) > c:\python24\lib\pydoc.py(1290)docother() -> chop = maxlen - len(line) (Pdb) The problem seems to be that the TextDoc.docother method is called with unexpected arguments. The signature is docother(object, name, mod, maxlen, doc) but it is called with the object to document as the 'maxlen' parameter. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-07 13:42 Message: Logged In: YES user_id=849994 This was already fixed in rev. 39636/7 and will be in 2.4.3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442012&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1444408 ] subprocess test cases fail with noexec-mounted /tmp
Bugs item #108, was opened at 2006-03-06 20:48 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=108&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) >Assigned to: Peter à strand (astrand) Summary: subprocess test cases fail with noexec-mounted /tmp Initial Comment: Hi, on my Linux box two subprocess tests always fail (see below for a log output). The reason is those two tests try to execute files created with tempfile.mkstemp(), which generates files in /tmp. And my /tmp directory forbids to execute files, it is mounted with the "noexec" option. What I expected from the tests is to either find a temporary directory where execution is allowed (eg. the directory where sys.executable lies), or simply skip those tests. Test output: [...] == ERROR: test_args_string (test.test_subprocess.ProcessTestCase) -- Traceback (most recent call last): File "/home/calvin/src/python-svn/Lib/test/test_subprocess.py", line 490, in test_args_string p = subprocess.Popen(fname) File "/home/calvin/src/python-svn/Lib/subprocess.py", line 580, in __init__ errread, errwrite) File "/home/calvin/src/python-svn/Lib/subprocess.py", line 1033, in _execute_child raise child_exception OSError: [Errno 13] Permission denied == ERROR: test_call_string (test.test_subprocess.ProcessTestCase) -- Traceback (most recent call last): File "/home/calvin/src/python-svn/Lib/test/test_subprocess.py", line 532, in test_call_string rc = subprocess.call(fname) File "/home/calvin/src/python-svn/Lib/subprocess.py", line 431, in call return Popen(*popenargs, **kwargs).wait() File "/home/calvin/src/python-svn/Lib/subprocess.py", line 580, in __init__ errread, errwrite) File "/home/calvin/src/python-svn/Lib/subprocess.py", line 1033, in _execute_child raise child_exception OSError: [Errno 13] Permission denied -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=108&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1440831 ] UnicodeWriter: "utf-8" hardcoded instead of self.encoding
Bugs item #1440831, was opened at 2006-03-01 09:04
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1440831&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Rodrigo Daunoravicius (rodelrod)
>Assigned to: Georg Brandl (gbrandl)
Summary: UnicodeWriter: "utf-8" hardcoded instead of self.encoding
Initial Comment:
In the Python Library Reference, 12.20.5 Examples.
In the UnicodeReader/UnicodeWriter example.
class UnicodeWriter:
...
|def writerow(self, row):
||self.writer.writerow([s.encode("utf-8") for s
in row])
should be:
class UnicodeWriter:
...
|def writerow(self, row):
||self.writer.writerow([s.encode(self.encoding)
for s in row])
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-07 13:47
Message:
Logged In: YES
user_id=849994
Thank you, fixed in rev. 42887.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1440831&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1444893 ] Pointer freed twice in Py_InitializeEx()
Bugs item #1444893, was opened at 2006-03-07 15:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1444893&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: athorp (athorp) Assigned to: Nobody/Anonymous (nobody) Summary: Pointer freed twice in Py_InitializeEx() Initial Comment: saved_locale is freed twice in pythonrun.c:Py_InitializeEx(). Example code attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1444893&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1437699 ] robotparser crashes if robots.txt contains non-ASCII
Bugs item #1437699, was opened at 2006-02-23 16:07
Message generated for change (Comment added) made by osvenskan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437699&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: osvenskan (osvenskan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: robotparser crashes if robots.txt contains non-ASCII
Initial Comment:
One-line summary: If the robotparser module encounters
a robots.txt file that contains non-ASCII characters
AND I pass a Unicode user agent string to can_fetch(),
that function crashes with a TypeError under Python
2.4. Under Python 2.3, the error is a UnicodeDecodeError.
More detail:
When one calls can_fetch(MyUserAgent, url), the
robotparser module compares the UserAgent to each user
agent described in the robots.txt file. If
isinstance(MyUserAgent, str) == True then the
comparison does not raise an error regardless of the
contents of robots.txt. However, if
isinstance(MyUserAgent, unicode) == True, then Python
implicitly tries to convert the contents of the
robots.txt file to Unicode before comparing it to
MyUserAgent. By default, Python assumes a US-ASCII
encoding when converting, so if the contents of
robots.txt aren't ASCII, the conversion fails. In other
words, this works:
MyRobotParser.can_fetch('foobot', url)
but this fails:
MyRobotParser.can_fetch(u'foobot', url)
I recreated this with Python 2.4.1 on FreeBSD 6 and
Python 2.3 under Darwin/OS X. I'll attach examples from
both. The URLs that I use in the attachments are from
my Web site and will remain live. They reference
robots.txt files which contain an umlaut-ed 'a' (0xe4
in iso-8859-1). They're served up using a special
.htaccess file that adds a Content-Type header which
correctly identifies the encoding used for each file.
Here's the contents of the .htaccess file:
AddCharset iso-8859-1 .iso8859-1
AddCharset utf-8 .utf8
A suggested solution:
AFAICT, the construction of robots.txt is still defined
by "a consensus on 30 June 1994 on the robots mailing
list" [http://www.robotstxt.org/wc/norobots.html] and a
1996 draft proposal
[http://www.robotstxt.org/wc/norobots-rfc.html] that
has never evolved into a formal standard. Neither of
these mention character sets or encodings which is no
surprise considering that they date back to the days
when the Internet was poor but happy and we considered
even ASCII a luxury and we were grateful to have it.
("ASCII? We used to dream of having ASCII. We only had
one bit, and it was a zero. We lived in a shoebox in
the middle of the road..." etc.) A backwards-compatible
yet forward-looking solution would be to have the
robotparser module respect the Content-Type header sent
with robots.txt. If no such header is present,
robotparser should try to decode it using iso-8859-1
per section 3.7.1 of the HTTP 1.1 spec
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1)
which says, 'When no explicit charset parameter is
provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of
"ISO-8859-1" when received via HTTP. Data in character
sets other than "ISO-8859-1" or its subsets MUST be
labeled with an appropriate charset value.' Section
3.6.1 of the HTTP 1.0 spec says the same. Since
ISO-8859-1 is a superset of US-ASCII, robots.txt files
that are pure ASCII won't be affected by the change.
--
>Comment By: osvenskan (osvenskan)
Date: 2006-03-07 11:32
Message:
Logged In: YES
user_id=1119995
Thanks for looking at this. I have some followup comments.
The list at robotstxt.org is many years stale (note that
Google's bot is present only as Backrub which was still a
server at Stanford at the time:
http://www.robotstxt.org/wc/active/html/backrub.html) but
nevertheless AFAICT it is the most current bot list on the
Web. If you look carefully, the list *does* contain a
non-ASCII entry (#76 --easy to miss in that long list). That
Finnish bot is gone but it has left a legacy in the form of
many robots.txt files that were created by automated tools
based on the robotstxt.org list. Google helps us here:
http://www.google.com/search?q=allintext%3AH%C3%A4m%C3%A4h%C3%A4kki+disallow+filetype%3Atxt
And by Googling for some common non-ASCII words and letters
I can find more like this one (look at the end of the
alphabetical list):
http://paranormal.se/robots.txt
Robots.txt files that contain non-ASCII are few and far
between, it seems, but they're out there.
Which leads me to a nitpicky (but important!) point about
Unicode. As you point out, the spec doesn't mention Unicode;
it says nothing at all on the topic of encodings. My
argument is that just because the spec doesn't mention
encodin
[ python-Bugs-729236 ] building readline module fails on Irix 6.5
Bugs item #729236, was opened at 2003-04-28 23:03
Message generated for change (Comment added) made by gillet
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.3
Status: Closed
Resolution: None
Priority: 5
Submitted By: alexandre gillet (gillet)
Assigned to: Nobody/Anonymous (nobody)
Summary: building readline module fails on Irix 6.5
Initial Comment:
I am trying to build Python2.3b1 on a sgi Irix 6.5 using
MIPSpro Compilers: Version 7.30
I can't get the readline module to build. I get the
following error:
cc -OPT:Olimit=0 -DNDEBUG -O -I. -I../Include
-I/mgl/prog/share/include/ -c ../Modules/readline.c -o
Modules/readline.o
cc-1119 cc: ERROR File = ../Modules/readline.c, Line = 587
The "return" expression type differs from the
function return type.
return completion_matches(text, *on_completion);
^
cc-1552 cc: WARNING File = ../Modules/readline.c, Line
= 732
The variable "m" is set but never used.
PyObject *m;
^
1 error detected in the compilation of
"../Modules/readline.c".
gmake: *** [Modules/readline.o] Error 2
--
>Comment By: alexandre gillet (gillet)
Date: 2006-03-07 18:34
Message:
Logged In: YES
user_id=150999
Tested it with python2.4.2 and readline 5.1. It builds with
no problem.
--
Comment By: SourceForge Robot (sf-robot)
Date: 2006-03-07 03:24
Message:
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 09:15
Message:
Logged In: YES
user_id=1188172
Is this still the case with Python 2.4?
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-21 23:49
Message:
Logged In: YES
user_id=33168
Is HAVE_RL_COMPLETION_MATCHES defined? If so is
rl_completion_matches() defined to return char ** in
readline.h? If HAVE_* is not defined, where is
completion_matches() defined and what does it return?
--
Comment By: alexandre gillet (gillet)
Date: 2003-05-12 18:02
Message:
Logged In: YES
user_id=150999
I was able to compile readline on Irix after changing the
function flex_complete. the function prototyte say it should
return a char** .So we did put the following change and it
works. Is it a right way to do it?
** readline.c 2003-05-09 13:45:38.0 -0700
--- readline.c~ 2003-03-01 07:19:41.0 -0800
***
*** 577,589
/* A more flexible constructor that saves the "begidx" and
"endidx"
* before calling the normal completer */
! static char ** flex_complete(char *text, int start, int end)
{
Py_XDECREF(begidx);
Py_XDECREF(endidx);
begidx = PyInt_FromLong((long) start);
endidx = PyInt_FromLong((long) end);
! return (char **)completion_matches(text,
*on_completion);
}
--- 577,590
/* A more flexible constructor that saves the "begidx" and
"endidx"
* before calling the normal completer */
! static char **
! flex_complete(char *text, int start, int end)
{
Py_XDECREF(begidx);
Py_XDECREF(endidx);
begidx = PyInt_FromLong((long) start);
endidx = PyInt_FromLong((long) end);
! return completion_matches(text, *on_completion);
}
--
Comment By: alexandre gillet (gillet)
Date: 2003-05-12 17:44
Message:
Logged In: YES
user_id=150999
My readline version is 4.3
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-04-29 11:44
Message:
Logged In: YES
user_id=21627
What is your readline version?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1445068 ] getpass.getpass queries on STDOUT not STERR (*nix)
Bugs item #1445068, was opened at 2006-03-07 19:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445068&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jon Lasser (jonlasser) Assigned to: Nobody/Anonymous (nobody) Summary: getpass.getpass queries on STDOUT not STERR (*nix) Initial Comment: Expected behavior of a *nix system would be to get the password query on STDERR, so that (for non-interactive applications) one can send the output of the command to somewhere else, and not be hanging on a password request that was never seen by the user at the terminal. (And also so that output isn't polluted by the password request, when parsing it via a pipeline.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445068&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1439659 ] file to store pickled object should be opened in binary mode
Bugs item #1439659, was opened at 2006-02-27 14:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439659&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Raghuram Devarakonda (draghuram) Assigned to: Nobody/Anonymous (nobody) Summary: file to store pickled object should be opened in binary mode Initial Comment: Hi, To unpickle objects on UNIX that were pickled on windows, the file should be opened in binary mode for read and write on windows. It will be nice to have this mentioned in the doc. Something along these lines will be good enough: "Please note that if you are writing the pickled object to a file on windows, make sure it is opened in binary mode. Otherwise, the file may not be able to be used to unpickle on other non-windows platforms". Thanks, Raghu. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-07 20:30 Message: Logged In: YES user_id=849994 I recently added a note to the docs about this. I it's not enough, feel free to reopen. -- Comment By: Tim Peters (tim_one) Date: 2006-03-06 19:48 Message: Logged In: YES user_id=31435 Pickle files should be opened in binary mode, regardless of pickle protocol, regardless of platform, and regardless of whether reading or writing. That protocol 0 used to be called "text mode" was an historic mistake, and was given that name by a Unix-head who wouldn't know the difference between text and binary mode if it suck its teeth in their posterior and tore off an entire bloody buttock :-) -- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-06 19:03 Message: Logged In: YES user_id=593130 Any text file written with /r/n in Windows can have problems when read on *nix or Mac or ???, so this problem is not specific to pickle or even to Python. I am under the impression that the new universal newline support was intended to fix such problems (when used). But as a Win- only user (currently) I have no experience with it. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2006-03-06 15:12 Message: Logged In: YES user_id=984087 There seems to be a mistane in my earlier comment. I meant the unpickling on *UNIX* fails even if ASCII was used on windows. Raghu. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2006-03-06 15:11 Message: Logged In: YES user_id=984087 Hi, The point is that even if ASCII protocol is used on windows(as I was), the unpickling process would fail on windows. So the pickle file should be opened in binary mode on windows even for ASCII protocol. This may make reading the file in notepad difficult but then, cross platform support should take precedence, I suppose. Another option would be for python to do line end translations for ASCII pickle files. Raghu. -- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-06 03:36 Message: Logged In: YES user_id=593130 For ASCII protocol pickles, intended for human readability, one should use text mode to be able to read the file, for instance, in Notepad. For either binary protocol, I would think binary mode should be best even to reread on Windows. If anything is added, I would put "On Windows, open files in a mode (text/binary) that matches the protocol." at the bottom of http://docs.python.org/lib/node64.html Looking forward to 3.0, when file mode might be more significant (text/binary corresponding to unicode/bytes), the "for windoews' qualifier might be omitted, but this might be premature. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439659&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1439538 ] test -e is not portable (Solaris 2.7)
Bugs item #1439538, was opened at 2006-02-27 10:51 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439538&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Håvard Tveite (havatv) >Assigned to: Martin v. Löwis (loewis) Summary: test -e is not portable (Solaris 2.7) Initial Comment: I was adviced by Barry Warsaw to file a bug on this. I tried to install Python 2.4.2 (and 2.3.5) on Solaris 2.7, but configure failed. The Solaris 2.7 sh does not support "test -e". "test -e" is used two times in configure. The use of "test -e" is not recommended for "Portable Shell Programming": http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_chapter/autoconf_10.html > I replaced "test -e" with "test -r", and it seems to work (configure finishes OK, and the files are found), but I do not know if this is the correct way to do it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439538&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1432525 ] os.listdir doesn't release GIL
Bugs item #1432525, was opened at 2006-02-15 17:45 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 >Status: Open Resolution: Accepted Priority: 5 Submitted By: Jonathan Ellis (ellisj) Assigned to: Georg Brandl (gbrandl) Summary: os.listdir doesn't release GIL Initial Comment: posix_listdir in posixmodule.c does not release the global interpreter lock, blocking all other threads for the duration of the call. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-07 16:09 Message: Logged In: YES user_id=6380 So the patch is broken because there's a continue in the do-while-loop that jumps to the "while (result)" test without setting result. Fixing this by adding a label and a goto (in two places!) creates awful spaghetti code. Before somebody spends more time refactoring such hairy code, I'd like to see a better motivation; the motivation currently provided is a bit thin. Are there use cases where this call takes a long time? -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-07 07:48 Message: Logged In: YES user_id=849994 Committed as rev. 42884. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-03 12:48 Message: Logged In: YES user_id=21627 The patch looks fine. Please apply. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-18 06:13 Message: Logged In: YES user_id=1188172 Attaching a patch. Please check. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1432525 ] os.listdir doesn't release GIL
Bugs item #1432525, was opened at 2006-02-15 22:45 Message generated for change (Comment added) made by ellisj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Jonathan Ellis (ellisj) Assigned to: Georg Brandl (gbrandl) Summary: os.listdir doesn't release GIL Initial Comment: posix_listdir in posixmodule.c does not release the global interpreter lock, blocking all other threads for the duration of the call. -- >Comment By: Jonathan Ellis (ellisj) Date: 2006-03-07 22:36 Message: Logged In: YES user_id=657828 My original use case is on a server back end with fairly busy disks. It's not unusual for listdir to take 100ms. That's a relatively long time to shut down the rest of the system. -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-07 21:09 Message: Logged In: YES user_id=6380 So the patch is broken because there's a continue in the do-while-loop that jumps to the "while (result)" test without setting result. Fixing this by adding a label and a goto (in two places!) creates awful spaghetti code. Before somebody spends more time refactoring such hairy code, I'd like to see a better motivation; the motivation currently provided is a bit thin. Are there use cases where this call takes a long time? -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-07 12:48 Message: Logged In: YES user_id=849994 Committed as rev. 42884. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-03 17:48 Message: Logged In: YES user_id=21627 The patch looks fine. Please apply. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-18 11:13 Message: Logged In: YES user_id=1188172 Attaching a patch. Please check. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1445210 ] embedding Python causes memory leaks
Bugs item #1445210, was opened at 2006-03-08 10:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445210&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Trevorrow (andykt)
Assigned to: Nobody/Anonymous (nobody)
Summary: embedding Python causes memory leaks
Initial Comment:
[This bug has been submitted by others but for some reason it
has been marked Closed. I consider it to be an extremely serious
bug -- if I can't solve it I'm going to have to abandon Python as
my app's scripting language, even though I've fallen in love!]
I've added Python script support to my cross-platfom wxWidgets app
so that users can run .py scripts from within the app to automate the
GUI and do other fancy things. It all works very nicely, except for
one nasty problem: *every* time a script is run there is a memory leak,
usually small (about 10K) but sometimes massive (about 4MB in the
case of one rather complicated script).
The problem occurs on both Mac OS 10.3.9 and Windows 2000.
I'm using Python 2.3 on the Mac and 2.4.2 on Windows.
Every time the user runs a script, my app makes these calls:
(I've removed a lot of irrelevant stuff.)
Py_Initialize();
PyRun_SimpleString("execfile('foo.py')");
Py_Finalize();
It's definitely not a wxWidgets problem. In fact it's quite easy to
see the memory leak using a simple command-line program:
#include
#include
main(int argc, char *argv[])
{
int i;
for (i=0; i<1000; i++) {
Py_Initialize();
Py_Finalize();
printf(".");
if ((i+1) % 50 == 0) printf("\n");
}
}
Note that it doesn't even execute a script. If I run this program on
my Mac and watch its memory usage with Activity Monitor, I see a leak
of about 10K each time through the loop. Similar result on Windows.
Curiously, on both machines, the Py_Finalize() call takes longer and
longer to complete whatever it's doing. The above program takes a
few *minutes* to complete on my 400MHz Mac.
Andrew
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445210&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1432525 ] os.listdir doesn't release GIL
Bugs item #1432525, was opened at 2006-02-15 17:45 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Jonathan Ellis (ellisj) Assigned to: Georg Brandl (gbrandl) Summary: os.listdir doesn't release GIL Initial Comment: posix_listdir in posixmodule.c does not release the global interpreter lock, blocking all other threads for the duration of the call. -- Comment By: Jim Jewett (jimjjewett) Date: 2006-03-07 18:48 Message: Logged In: YES user_id=764593 I think the spaghetti was already there. The gotos can be removed by just reversing the logic (if ! (...)) The XXX comment complains about four versions, but I count either three (windows without opendir, OS2, everything else) or five (the non-OS2 versions are split for unicode). The code getting skipped is repeated because the logic for skipping "." and ".." is repeated four times. (There would be another goto, if the OS2 case allowed threads.) -- Comment By: Jonathan Ellis (ellisj) Date: 2006-03-07 17:36 Message: Logged In: YES user_id=657828 My original use case is on a server back end with fairly busy disks. It's not unusual for listdir to take 100ms. That's a relatively long time to shut down the rest of the system. -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-07 16:09 Message: Logged In: YES user_id=6380 So the patch is broken because there's a continue in the do-while-loop that jumps to the "while (result)" test without setting result. Fixing this by adding a label and a goto (in two places!) creates awful spaghetti code. Before somebody spends more time refactoring such hairy code, I'd like to see a better motivation; the motivation currently provided is a bit thin. Are there use cases where this call takes a long time? -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-07 07:48 Message: Logged In: YES user_id=849994 Committed as rev. 42884. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-03 12:48 Message: Logged In: YES user_id=21627 The patch looks fine. Please apply. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-18 06:13 Message: Logged In: YES user_id=1188172 Attaching a patch. Please check. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1432525 ] os.listdir doesn't release GIL
Bugs item #1432525, was opened at 2006-02-15 17:45 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Jonathan Ellis (ellisj) Assigned to: Georg Brandl (gbrandl) Summary: os.listdir doesn't release GIL Initial Comment: posix_listdir in posixmodule.c does not release the global interpreter lock, blocking all other threads for the duration of the call. -- Comment By: Jim Jewett (jimjjewett) Date: 2006-03-07 18:52 Message: Logged In: YES user_id=764593 I think the spaghetti was already there. The gotos can be removed by just reversing the logic (if ! (...)) The XXX comment complains about four versions, but I count either three (windows without opendir, OS2, everything else) or five (the non-OS2 versions are split for unicode). The code getting skipped is repeated because the logic for skipping "." and ".." is repeated four times. (There would be another goto, if the OS2 case allowed threads.) -- Comment By: Jim Jewett (jimjjewett) Date: 2006-03-07 18:48 Message: Logged In: YES user_id=764593 I think the spaghetti was already there. The gotos can be removed by just reversing the logic (if ! (...)) The XXX comment complains about four versions, but I count either three (windows without opendir, OS2, everything else) or five (the non-OS2 versions are split for unicode). The code getting skipped is repeated because the logic for skipping "." and ".." is repeated four times. (There would be another goto, if the OS2 case allowed threads.) -- Comment By: Jonathan Ellis (ellisj) Date: 2006-03-07 17:36 Message: Logged In: YES user_id=657828 My original use case is on a server back end with fairly busy disks. It's not unusual for listdir to take 100ms. That's a relatively long time to shut down the rest of the system. -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-07 16:09 Message: Logged In: YES user_id=6380 So the patch is broken because there's a continue in the do-while-loop that jumps to the "while (result)" test without setting result. Fixing this by adding a label and a goto (in two places!) creates awful spaghetti code. Before somebody spends more time refactoring such hairy code, I'd like to see a better motivation; the motivation currently provided is a bit thin. Are there use cases where this call takes a long time? -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-07 07:48 Message: Logged In: YES user_id=849994 Committed as rev. 42884. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-03 12:48 Message: Logged In: YES user_id=21627 The patch looks fine. Please apply. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-18 06:13 Message: Logged In: YES user_id=1188172 Attaching a patch. Please check. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1432525 ] os.listdir doesn't release GIL
Bugs item #1432525, was opened at 2006-02-15 17:45 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Jonathan Ellis (ellisj) Assigned to: Georg Brandl (gbrandl) Summary: os.listdir doesn't release GIL Initial Comment: posix_listdir in posixmodule.c does not release the global interpreter lock, blocking all other threads for the duration of the call. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-07 23:07 Message: Logged In: YES user_id=6380 Well, the difference is that before the patch was applied it worked, and now it's broken. So somebody please roll it back; *then* we can think of a proper fix and review it properly. -- Comment By: Jim Jewett (jimjjewett) Date: 2006-03-07 18:52 Message: Logged In: YES user_id=764593 I think the spaghetti was already there. The gotos can be removed by just reversing the logic (if ! (...)) The XXX comment complains about four versions, but I count either three (windows without opendir, OS2, everything else) or five (the non-OS2 versions are split for unicode). The code getting skipped is repeated because the logic for skipping "." and ".." is repeated four times. (There would be another goto, if the OS2 case allowed threads.) -- Comment By: Jim Jewett (jimjjewett) Date: 2006-03-07 18:48 Message: Logged In: YES user_id=764593 I think the spaghetti was already there. The gotos can be removed by just reversing the logic (if ! (...)) The XXX comment complains about four versions, but I count either three (windows without opendir, OS2, everything else) or five (the non-OS2 versions are split for unicode). The code getting skipped is repeated because the logic for skipping "." and ".." is repeated four times. (There would be another goto, if the OS2 case allowed threads.) -- Comment By: Jonathan Ellis (ellisj) Date: 2006-03-07 17:36 Message: Logged In: YES user_id=657828 My original use case is on a server back end with fairly busy disks. It's not unusual for listdir to take 100ms. That's a relatively long time to shut down the rest of the system. -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-07 16:09 Message: Logged In: YES user_id=6380 So the patch is broken because there's a continue in the do-while-loop that jumps to the "while (result)" test without setting result. Fixing this by adding a label and a goto (in two places!) creates awful spaghetti code. Before somebody spends more time refactoring such hairy code, I'd like to see a better motivation; the motivation currently provided is a bit thin. Are there use cases where this call takes a long time? -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-07 07:48 Message: Logged In: YES user_id=849994 Committed as rev. 42884. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-03 12:48 Message: Logged In: YES user_id=21627 The patch looks fine. Please apply. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-18 06:13 Message: Logged In: YES user_id=1188172 Attaching a patch. Please check. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
