[ python-Bugs-1166378 ] No os.spawn*p* on Windows
Bugs item #1166378, was opened at 2005-03-19 05:41 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166378&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Chris Palmer (chris_palmer) Assigned to: Nobody/Anonymous (nobody) Summary: No os.spawn*p* on Windows Initial Comment: You have the other spawn* functions, and exec*p*, but no spawn*p*. It exists on Linux. These functions should either exist everywhere or nowhere. -- Comment By: Christos Georgiou (tzot) Date: 2005-03-20 12:02 Message: Logged In: YES user_id=539787 This is documented (see http://docs.python.org/lib/os-process.html). Python lib has many places where underlying platform controls availability of functionality. Suggest closing of this bug or converting it to wishlist item. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166378&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1163244 ] Syntax error on large file with MBCS encoding
Bugs item #1163244, was opened at 2005-03-14 22:20 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tim N. van der Leeuw (tnleeuw) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error on large file with MBCS encoding Initial Comment: Large files generated by make-py.py from the win32all extensions cannot be compiled by Python2.4.1rc1 - they give a syntax error. This is a regression from 2.3.5 (With Python2.4, the interpreter crashes. That is fixed now.) Removing the mbcs encoding line from the top of the file, compilation succeeds. File should be attached, as zip-file. Probably requires win32all extensions to be installed to be compiled / imported (generated using build 203 of the win32all extensions). -- Comment By: Christos Georgiou (tzot) Date: 2005-03-20 12:28 Message: Logged In: YES user_id=539787 Useful pointers: in Python-dev, this has been characterised as related to pywin32 bug 1085454. Also related to www.python.org/sf/1101726 and www.python.org/sf/1089395. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1162477 ] Parsing failures in parsedate_tz
Bugs item #1162477, was opened at 2005-03-13 18:11
Message generated for change (Comment added) made by tzot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162477&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: TH (therve)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parsing failures in parsedate_tz
Initial Comment:
Some email clients send bad-formed datetimes, not
parsed by parsedate_tz (both rfc822.py and
email._parseaddr.py).
The format not recognized is "HH.MM.SS".
I don't know if it's worth taking in account but in
doubt I give a small patch for email._parseaddr :
@@ -90,6 +100,14 @@ def parsedate_tz(data):
tss = '0'
elif len(tm) == 3:
[thh, tmm, tss] = tm
+elif len(tm) == 1:
+# Small hack to get HH.MM.ss
+tm = tm[0].split(".")
+if len(tm) == 2:
+[thh, tmm] = tm
+tss = '0'
+elif len(tm) == 3:
+[thh, tmm, tss] = tm
else:
return None
--
Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 12:36
Message:
Logged In: YES
user_id=539787
It would be helpful if you could provide some of these
malformed Date headers, so that test cases can be generated.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162477&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1157255 ] PEP 328 and Python 2.4 error
Bugs item #1157255, was opened at 2005-03-05 15:23 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157255&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 328 and Python 2.4 error Initial Comment: PEP 328 says that from __future__ import absolute_import will be part of Python 2.4, but it is not: D:\Projects\CB>python Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from __future__ import absolute_import File "", line 1 SyntaxError: future feature absolute_import is not defined The PEP should be updated to reflect this. -- Comment By: Christos Georgiou (tzot) Date: 2005-03-20 13:00 Message: Logged In: YES user_id=539787 This is still not implemented at least in HEAD (http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/future.c?rev=2.15&view=auto and http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/__future__.py?rev=1.13&view=auto ). I believe new functionality is avoided in micro (x.y.N) releases, so the PEP probably will have to specify 2.5 instead of 2.4 as version of application. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157255&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-874900 ] threading module can deadlock after fork
Bugs item #874900, was opened at 2004-01-11 16:28 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874900&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael McCandless (mikemccand) Assigned to: Nobody/Anonymous (nobody) Summary: threading module can deadlock after fork Initial Comment: We have a Python HTTP server that, in the parent process, uses os.fork to spawn new children, but at the same time the parent could be spawning new threads (in threads other than the main thread -- only the main thread does forking). Anwyay, it very rarely causes deadlock in a spawned child when that child tries to start a new thread. I believe I've tracked this down to the _active_limbo_lock in the threading module. Specifically, if this lock is held by parent (because another thread is spawning a thread), just as os.fork happens, the child inherits the held lock and will then block trying to do any threading.* operations. Just like the global interp. lock is overwritten in the child after fork, I think something similar should happen to threading._active_limbo_lock? (And more generally the user needs to be aware of locks passing through fork; but I think at least threading.py should "do the right thing"). This thread looks quite relevant: groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=38E6F2BA.E66CAC90%40ensim.com&rnum=5&prev=/groups%3Fq%3Dpython%2Bfork%2Bthreading%2Bmodule%2B%2Block%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26sa%3DN%26scoring%3Dd -- Comment By: Christos Georgiou (tzot) Date: 2005-03-20 14:05 Message: Logged In: YES user_id=539787 See some more typical info about mixing forks and threads: http://mail.python.org/pipermail/python-list/2001-September/066048.html This seems not to be Python-related, but platform-related. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874900&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-874900 ] threading module can deadlock after fork
Bugs item #874900, was opened at 2004-01-11 09:28 Message generated for change (Comment added) made by mikemccand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874900&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael McCandless (mikemccand) Assigned to: Nobody/Anonymous (nobody) Summary: threading module can deadlock after fork Initial Comment: We have a Python HTTP server that, in the parent process, uses os.fork to spawn new children, but at the same time the parent could be spawning new threads (in threads other than the main thread -- only the main thread does forking). Anwyay, it very rarely causes deadlock in a spawned child when that child tries to start a new thread. I believe I've tracked this down to the _active_limbo_lock in the threading module. Specifically, if this lock is held by parent (because another thread is spawning a thread), just as os.fork happens, the child inherits the held lock and will then block trying to do any threading.* operations. Just like the global interp. lock is overwritten in the child after fork, I think something similar should happen to threading._active_limbo_lock? (And more generally the user needs to be aware of locks passing through fork; but I think at least threading.py should "do the right thing"). This thread looks quite relevant: groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=38E6F2BA.E66CAC90%40ensim.com&rnum=5&prev=/groups%3Fq%3Dpython%2Bfork%2Bthreading%2Bmodule%2B%2Block%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26sa%3DN%26scoring%3Dd -- >Comment By: Michael McCandless (mikemccand) Date: 2005-03-20 07:12 Message: Logged In: YES user_id=323786 True -- there are many platform specific issues on the interaction of forking and threading. However the _active_limbo_lock is entirely a Python issue (I think it can deadlock on any platform, unless the platform releases locks in child process after fork). After forking, python already resets the GIL, and it should also reset any other locks that have global impact like _active_limbo_lock. -- Comment By: Christos Georgiou (tzot) Date: 2005-03-20 07:05 Message: Logged In: YES user_id=539787 See some more typical info about mixing forks and threads: http://mail.python.org/pipermail/python-list/2001-September/066048.html This seems not to be Python-related, but platform-related. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874900&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1155362 ] Bugs in parsedate_tz
Bugs item #1155362, was opened at 2005-03-02 23:03
Message generated for change (Comment added) made by tzot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155362&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: TH (therve)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Bugs in parsedate_tz
Initial Comment:
The parsing in emails is incomplete in both rfc822.py
and _parseaddr.py.
For example, "Wed, 02 Mar 2005 09:26:53+0800" is parsed
but "Wed, 02 Mar 2005 09:26:53-0800" is not.
The problem is clear by watching the code : only "+"
timezones are corrected.
Following a patch :
Index : _parseaddr.py
@@ -60,7 +66,11 @@ def parsedate_tz(data):
if i > 0:
data[3:] = [s[:i], s[i+1:]]
else:
-data.append('') # Dummy tz
+ i = s.find('-')
+ if i > 0:
+ data[3:] = [s[:i], s[i:]]
+ else:
+ data.append('') # Dummy tz
if len(data) < 5:
return None
data = data[:5]
--
Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 13:48
Message:
Logged In: YES
user_id=539787
Note that parsedate_tz as of current parses correctly "Wed,
02 Mar 2005 09:26:53 -0800" (space before '-'), because
data.split() in line 43 produces five parts: [dow, date,
month, year, time, timezone] (reduced to four by removing
initial dow). The function includes a special check for
"+" in the time part, and this patch adds the "-" check.
I didn't find any date header in my whole email and
newsgroup archive (12095 messages) missing the space before
[-+]. However, if mail clients or servers exist that
produce such date headers, patch should be applied and bug
closed.
Notes:
Some test should be added too. I updated
test_parsedate_no_dayofweek (line 2076 of
lib/email/test/test_email.py) adding same test dropping the
space before '-', and test fails before patch, succeeds
after patch. Perhaps a separate test case should be included.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155362&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1162477 ] Parsing failures in parsedate_tz
Bugs item #1162477, was opened at 2005-03-13 16:11
Message generated for change (Comment added) made by therve
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162477&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: TH (therve)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parsing failures in parsedate_tz
Initial Comment:
Some email clients send bad-formed datetimes, not
parsed by parsedate_tz (both rfc822.py and
email._parseaddr.py).
The format not recognized is "HH.MM.SS".
I don't know if it's worth taking in account but in
doubt I give a small patch for email._parseaddr :
@@ -90,6 +100,14 @@ def parsedate_tz(data):
tss = '0'
elif len(tm) == 3:
[thh, tmm, tss] = tm
+elif len(tm) == 1:
+# Small hack to get HH.MM.ss
+tm = tm[0].split(".")
+if len(tm) == 2:
+[thh, tmm] = tm
+tss = '0'
+elif len(tm) == 3:
+[thh, tmm, tss] = tm
else:
return None
--
>Comment By: TH (therve)
Date: 2005-03-20 12:29
Message:
Logged In: YES
user_id=1038797
Of course, here's and example of malformed Date header :
"Wed, 02 Mar 2005 09.26.53 +0800".
--
Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 10:36
Message:
Logged In: YES
user_id=539787
It would be helpful if you could provide some of these
malformed Date headers, so that test cases can be generated.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162477&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1155362 ] Bugs in parsedate_tz
Bugs item #1155362, was opened at 2005-03-02 21:03
Message generated for change (Comment added) made by therve
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155362&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: TH (therve)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Bugs in parsedate_tz
Initial Comment:
The parsing in emails is incomplete in both rfc822.py
and _parseaddr.py.
For example, "Wed, 02 Mar 2005 09:26:53+0800" is parsed
but "Wed, 02 Mar 2005 09:26:53-0800" is not.
The problem is clear by watching the code : only "+"
timezones are corrected.
Following a patch :
Index : _parseaddr.py
@@ -60,7 +66,11 @@ def parsedate_tz(data):
if i > 0:
data[3:] = [s[:i], s[i+1:]]
else:
-data.append('') # Dummy tz
+ i = s.find('-')
+ if i > 0:
+ data[3:] = [s[:i], s[i:]]
+ else:
+ data.append('') # Dummy tz
if len(data) < 5:
return None
data = data[:5]
--
>Comment By: TH (therve)
Date: 2005-03-20 12:35
Message:
Logged In: YES
user_id=1038797
In fact, the mails I've seen with this problem are likely to
be spam.
I just thought it would be more logical to test both "+" and
"-" as "+" was already well parsed.
--
Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 11:48
Message:
Logged In: YES
user_id=539787
Note that parsedate_tz as of current parses correctly "Wed,
02 Mar 2005 09:26:53 -0800" (space before '-'), because
data.split() in line 43 produces five parts: [dow, date,
month, year, time, timezone] (reduced to four by removing
initial dow). The function includes a special check for
"+" in the time part, and this patch adds the "-" check.
I didn't find any date header in my whole email and
newsgroup archive (12095 messages) missing the space before
[-+]. However, if mail clients or servers exist that
produce such date headers, patch should be applied and bug
closed.
Notes:
Some test should be added too. I updated
test_parsedate_no_dayofweek (line 2076 of
lib/email/test/test_email.py) adding same test dropping the
space before '-', and test fails before patch, succeeds
after patch. Perhaps a separate test case should be included.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155362&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1166704 ] [ast branch] fatal error when compiling test_bool.py
Bugs item #1166704, was opened at 2005-03-19 15:34 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166704&group_id=5470 Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: [ast branch] fatal error when compiling test_bool.py Initial Comment: When using the ast-branch compiler, python exits with a fatal error when compiling test_bool.py or the symplified test case that I'll attach. The immediate problem is that when the compiler is in make_closure after compiling the lambda, self is found to be a LOCAL reference type and make_closure assumes it's a FREE reference if it's not a CELL reference in the enclosing scope. I don't know if self is supposed to be a LOCAL reference or if make_closure should handle LOCAL references. -- >Comment By: Brett Cannon (bcannon) Date: 2005-03-20 07:02 Message: Logged In: YES user_id=357491 dup of #1166714 . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166704&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-993580 ] inspect.findsource does not call linecache.checkcache
Bugs item #993580, was opened at 2004-07-19 00:45 Message generated for change (Comment added) made by jlcherry You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993580&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jason Mobarak (jmobarak) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.findsource does not call linecache.checkcache Initial Comment: inspect.findsource does not call linecache.checkcache thus always returns orignal source of an object regardless of wether it has changed. -- Comment By: Josh Cherry (jlcherry) Date: 2005-03-20 10:20 Message: Logged In: YES user_id=957678 Note that if you tack on execfile(somefile) print inspect.findsource(foo) at the end of the example, so that the object does change, you still see the old source. -- Comment By: Jason Mobarak (jmobarak) Date: 2004-07-19 01:01 Message: Logged In: YES user_id=1041478 Not to mention there's intermediate steps where an object's source could change several times, and be reloaded at one of those intermediate steps... seems like there's no way for findsource itself to return the correct source for an object if it's reloaded. Maybe this should be documented... -- Comment By: Jason Mobarak (jmobarak) Date: 2004-07-19 00:53 Message: Logged In: YES user_id=1041478 Actually, I'm not sure if this is really a bug, seems to make sense that inspect shouldn't return the new source of the object unless the object has changed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993580&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1166714 ] [ast branch] fatal error when compiling test_bool.py
Bugs item #1166714, was opened at 2005-03-19 16:14 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470 Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) >Assigned to: Brett Cannon (bcannon) Summary: [ast branch] fatal error when compiling test_bool.py Initial Comment: When using the ast-branch compiler, python exits with a fatal error when compiling test_bool.py or the symplified test case that I'll attach. The immediate problem is that when the compiler is in make_closure after compiling the lambda, self is found to be a LOCAL reference type and make_closure assumes it's a FREE reference if it's not a CELL reference in the enclosing scope. I don't know if self is supposed to be a LOCAL reference or if make_closure should handle LOCAL references. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1166714 ] [ast branch] fatal error when compiling test_bool.py
Bugs item #1166714, was opened at 2005-03-19 19:14 Message generated for change (Settings changed) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470 Category: Parser/Compiler >Group: AST Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Brett Cannon (bcannon) Summary: [ast branch] fatal error when compiling test_bool.py Initial Comment: When using the ast-branch compiler, python exits with a fatal error when compiling test_bool.py or the symplified test case that I'll attach. The immediate problem is that when the compiler is in make_closure after compiling the lambda, self is found to be a LOCAL reference type and make_closure assumes it's a FREE reference if it's not a CELL reference in the enclosing scope. I don't know if self is supposed to be a LOCAL reference or if make_closure should handle LOCAL references. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1166378 ] No os.spawn*p* on Windows
Bugs item #1166378, was opened at 2005-03-19 03:41 Message generated for change (Comment added) made by chris_palmer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166378&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Chris Palmer (chris_palmer) Assigned to: Nobody/Anonymous (nobody) Summary: No os.spawn*p* on Windows Initial Comment: You have the other spawn* functions, and exec*p*, but no spawn*p*. It exists on Linux. These functions should either exist everywhere or nowhere. -- >Comment By: Chris Palmer (chris_palmer) Date: 2005-03-20 20:43 Message: Logged In: YES user_id=1242303 Okay, I read the page you point to. It provides no explanation, just a statement of the fact I had already discovered. An explanation would be nice. Don't you think it's strange that these three conditions should hold: 1. os.exec*p* are supported on Windows; 2. Windows systems have a PATH environment variable with the same meaning and use as UNIX; and yet 3. os.spawn*p* are not supported on Windows? If there's some difference to how the environment is treated or used between exec* and spawn* on Windows, wouldn't it be easy to emulate the PATH-searching feature? My options are to emulate the PATH-searching feature myself and ignore os.spawn*p* on all platforms, or to use it when it's present and only emulate it on Windows. The first option is ridiculous, the second is ridiculous and ugly. If you won't emulate the spawn*p* behavior -- it's three lines of Python! -- it would help if you could at least explain why, technically. Thanks. -- Comment By: Christos Georgiou (tzot) Date: 2005-03-20 10:02 Message: Logged In: YES user_id=539787 This is documented (see http://docs.python.org/lib/os-process.html). Python lib has many places where underlying platform controls availability of functionality. Suggest closing of this bug or converting it to wishlist item. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166378&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1167262 ] Fails assertion in winsig.c under VC 8.0
Bugs item #1167262, was opened at 2005-03-21 03:25 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=1167262&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Timothy Fitz (timothyfitz) Assigned to: Nobody/Anonymous (nobody) Summary: Fails assertion in winsig.c under VC 8.0 Initial Comment: In 2.4 and current cvs initsignal in signalmodule.c calls PyOS_getsig which calls signal with an invalid signal number. Under VC 7.1 (and 7.0, and probably before) this would return SIG_ERR however under VC 8.0 (beta) this causes an assertion failure. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-853411 ] After fork in subthread, signals are blocked
Bugs item #853411, was opened at 2003-12-03 16:55 Message generated for change (Comment added) made by moculus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853411&group_id=5470 Category: Threads Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Göran Uddeborg (goeran) Assigned to: Nobody/Anonymous (nobody) Summary: After fork in subthread, signals are blocked Initial Comment: When a Python program starts a new thread, and this new thread forks, the forked process ingores signals. It will not terminate, or dump core if that would be applicable, when it receives a signal. I attach a test case which illustrates the behaviour. In this example, the child process is sent a SEGV signal from the subthread of the parent process. This should cause the child process to die and produce a core. But execution of the parent program threads finishes, there is still a python process around, continuing to sleep. Apparently, Python subthreads blocks signals. On Linux, /proc/*/status for subthreads includes the line SigBlk: 7ffbfeff The Python documentation says one should only install signal handlers in the main thread, and only the main thread will recieve signals. So this makes sense. But when the subthread forks, the new process inherits this signal mask, which seems to be incorrect behaviour. I would assume, if Python sets this signal mask for threads, it should also reset it again after a fork. I've seen this on these two platforms: Python 2.2.3 on Red Hat Linux RHEL 3WS (IA32) Python 2.2.1 on Sun Solaris 8 (Sparc) -- Comment By: Erik Osheim (moculus) Date: 2005-03-21 05:07 Message: Logged In: YES user_id=542811 I can confirm that on my install of 2.4, I no longer get this problem. -- Comment By: Michael Hudson (mwh) Date: 2005-03-18 08:59 Message: Logged In: YES user_id=6656 I think this should be fixed in Python 2.4. -- Comment By: Erik Osheim (moculus) Date: 2005-03-18 03:45 Message: Logged In: YES user_id=542811 This bug is still around. I have been experiencing it firsthand: if I write a simple program with one parent and one child thread and run rsync in the parent thread (via os.system), all is well. In the child thread it hangs indefinitely. After putting a bunch of debugging into rsync, I discovered that a USR2 signal was getting sent but never received, and rsyncs parent thread was waiting for the child to exit, and that the child was sleeping (having not gotten the signal). Is there any clue as to why this happens? This has been widely observed on Linux 2.6.* (this particular case affects Gentoo). -- Comment By: gmanipon (pymonger) Date: 2004-12-06 21:24 Message: Logged In: YES user_id=1173063 Sorry for the bother. Was there any resolution to this bug report? -- Comment By: Jack Jansen (jackjansen) Date: 2004-01-26 10:02 Message: Logged In: YES user_id=45365 I have absolutely no idea where the bug could be, someone better versed in the threading ideosyncracies of the various platforms needs to look at this, but I do want to point at hairy_flange's comment that fink-python 2.2.3 on OSX does *not* exhibit the bug (while on other platforms it does). It may be worthwhile to download a fink-python in source form, and see whether they do any configure magic. -- Comment By: Steve Muir (hairy_flange) Date: 2004-01-26 04:04 Message: Logged In: YES user_id=960132 I just submitted a bug report that is a duplicate of this bug (apologies!), I observed the same behaviour with the Python shipped with Mac OS X (Python 2.3), and Python 2.2.2 on RedHat/x86, but Fink Python 2.2.3 for OS X does not have this bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853411&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1167300 ] Error "exec"ing python code
Bugs item #1167300, was opened at 2005-03-21 00:35
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=1167300&group_id=5470
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Seefeld (stefan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error "exec"ing python code
Initial Comment:
I'm trying to 'exec'ing the following code:
class Foo: pass
class Bar:
f = Foo
The error appears when using 'exec f in {}, {}':
>>> f = ''.join(open('/home/stefan/t.py').readlines())
>>> exec f in {}, {}
Traceback (most recent call last):
File "", line 1, in ?
File "", line 2, in ?
File "", line 3, in Bar
NameError: name 'Foo' is not defined
I tested on python 2.3 and python 2.4, both show the same
behavior.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167300&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1167329 ] xmlrpclib invalid url
Bugs item #1167329, was opened at 2005-03-21 14:31 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=1167329&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Doukidis (doukm) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib invalid url Initial Comment: Within section: 11.22 xmlrpclib -- XML-RPC client access URL http://ontosys.com/xml-rpc/extensions.html is invalid. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167329&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
