[ python-Bugs-1761028 ] pickle - cannot unpickle circular deps with custom __hash__
Bugs item #1761028, was opened at 2007-07-26 14:36 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=1761028&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: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Süßkraut (edonmyder) Assigned to: Nobody/Anonymous (nobody) Summary: pickle - cannot unpickle circular deps with custom __hash__ Initial Comment: unpickle a object with a custom __hash__ fails. Example (full code is attached): class Node(object): def __init__(self, i): self.i = i def __cmp__(self, other): return cmp(self.i, other.i) def __hash__(self): return hash(self.i) n = Node(12) n.next_nodes = set((n,)) unpickling n give the following error message: Traceback (most recent call last): File "circle.py", line 23, in n1 = pickle.load(f1) File "/usr/lib/python2.5/pickle.py", line 1370, in load return Unpickler(file).load() File "/usr/lib/python2.5/pickle.py", line 858, in load dispatch[key](self) File "/usr/lib/python2.5/pickle.py", line 1133, in load_reduce value = func(*args) File "circle.py", line 15, in __hash__ return hash(self.i) AttributeError: 'Node' object has no attribute 'i' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1761028&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1068268 ] subprocess is not EINTR-safe
Bugs item #1068268, was opened at 2004-11-17 13:07 Message generated for change (Comment added) made by timjr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068268&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: Python 2.4 Status: Open Resolution: None Priority: 3 Private: No Submitted By: Peter Åstrand (astrand) Assigned to: Peter Åstrand (astrand) Summary: subprocess is not EINTR-safe Initial Comment: The subprocess module is not safe for use with signals, because it doesn't retry the system calls upon EINTR. However, as far as I understand it, this is true for most other Python modules as well, so it isn't obvious that the subprocess needs to be fixed. The problem was first noticed by John P Speno. -- Comment By: Tim Daly, Jr. (timjr) Date: 2007-07-26 21:14 Message: Logged In: YES user_id=1854532 Originator: NO I hit this in Python 2.5.1 on an Intel Mac in a PyQt application. mpitt's patch at http://librarian.launchpad.net/6820347/subprocess-eintr-safety.patch fixed it for me. -- Comment By: Martin Pitt (mpitt) Date: 2007-03-15 01:57 Message: Logged In: YES user_id=80975 Originator: NO Updated patch: http://librarian.launchpad.net/6820347/subprocess-eintr-safety.patch I removed the _read_all() function, since that broke the 1 MB exception limit and does not seem to be necessary in the first place. -- Comment By: Martin Pitt (mpitt) Date: 2007-03-14 15:36 Message: Logged In: YES user_id=80975 Originator: NO I updated Peter's original patch to 2.5+svn fixes and added proper tests to test_subprocess.py. It works great now. What do you think about this approach? Fixing it only in submodule feels a bit strange, but then again, this is meant to be an easy to use abstraction, and most of the people that were hit by this (according to Google) encountered the problem in subprocess. I don't see how to attach something here, so I attached the updated patch to the Ubuntu bug (https://launchpad.net/bugs/87292): http://librarian.launchpad.net/6807594/subprocess-eintr-safety.patch Thanks, Martin -- Comment By: Martin Pitt (mpitt) Date: 2007-02-26 04:15 Message: Logged In: YES user_id=80975 Originator: NO I just got two different Ubuntu bug reports about this problem as well, and I'm unsure how to circumvent this at the application level. http://librarian.launchpad.net/6514580/Traceback.txt http://librarian.launchpad.net/6527195/Traceback.txt (from https://launchpad.net/bugs/87292 and its duplicate) -- Comment By: Matt Johnston (mattjohnston) Date: 2004-12-21 23:07 Message: Logged In: YES user_id=785805 I've hit this on a Solaris 9 box without explicitly using signals. Using the DCOracle module, a seperate Oracle process is executed. When this terminates, a SIGCHLD is sent to the calling python process, which may be in the middle of a select() in the communicate() call, causing EINTR. From the output of truss (like strace), a sigchld handler doesn't appear to be getting explicitly installed by the Oracle module. SunOS 5.9 Generic_112233-01 sun4u sparc SUNW,Sun-Fire-280R -- Comment By: Peter Åstrand (astrand) Date: 2004-11-17 13:15 Message: Logged In: YES user_id=344921 One way of testing subprocess for signal-safeness is to insert these lines just after _cleanup(): import signal signal.signal(signal.SIGALRM, lambda x,y: 1) signal.alarm(1) import time time.sleep(0.99) Then run test_subprocess.py. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068268&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1753732 ] xmlrpclib.Binary doesn't say which base64 spec it implements
Bugs item #1753732, was opened at 2007-07-13 14:36 Message generated for change (Comment added) made by slinkp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753732&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: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Winkler (slinkp) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib.Binary doesn't say which base64 spec it implements Initial Comment: xmlrpclib.Binary.encode() does base64 encoding. But there are actually two conflicting specs: RFC 2045 says add newlines every 76 characters, RFC 3548 says do NOT add newlines. The xmlrpc spec characteristically doesn't mention an RFC, so it's not clear which spec they mean by "base64". By looking at the dates on the various specs, it can be inferred that they must mean MIME-style with newlines, as per RFC 2045. That's xmlrpclib does. But for those of us implementing stuff in the trenches and struggling with interoperability issues, it would be nice if the python docs were more informative so we don't have to go spiraling off into reading multiple specs and figuring out which came first :) So I'd suggest changing the Binary.encode docstring to something like: """Write the XML-RPC base 64 encoding of this binary item to the out stream object. Note that the encoded data will have newlines every 76 characters as per RFC 2045, which was the de facto standard base64 specification when the xmlrpc spec was written.""" Arguably, the behavior could be changed instead - due to the xmlrpc spec's silence on the subject, not all clients may tolerate newlines (Redstone doesn't)... but that's a separate argument :) -- >Comment By: Paul Winkler (slinkp) Date: 2007-07-27 00:12 Message: Logged In: YES user_id=38329 Originator: YES Sure. Patch against Doc/lib trunk attached. File Added: libxmlrpclib.patch -- Comment By: Martin v. Löwis (loewis) Date: 2007-07-16 17:08 Message: Logged In: YES user_id=21627 Originator: NO More documentation is always a good idea. Can you provide a patch (as a context or unified patch) against the sources of the documentation? -- Comment By: Paul Winkler (slinkp) Date: 2007-07-16 11:36 Message: Logged In: YES user_id=38329 Originator: YES Thanks Loewis, but I am well aware of the xmlrpc spec. As I said in my original bug report: The spec alone is too vague to tell us which base64 specification xmlrpclib should conform *to*, and thus we can't say whether xmlrpclib does or does not conform. Your yes/no question is thus unanswerable. In my opinion this means the spec is broken, but there's apparently no chance of an official update. I brought this up on the xmlrpc yahoo list. http://tech.groups.yahoo.com/group/xml-rpc/message/6650 Some excerpts from relevant responses: "The fact is, the spec has been frozen - "cast in stone" in the words of the author - since 1999, and there is absolutely 0% chance of an official update." - http://tech.groups.yahoo.com/group/xml-rpc/message/6651 "It would be nice to have a document that describes what "everyone does," but ... http://effbot.org/zone/xmlrpc-errata.htm does a good job too. Note that the latter clearly says you can split base64 lines if you want. ... I believe that essentially all XML-RPC implementations use MIME-style (RFC 2045) base64 encoding -- i.e. with line breaks." - http://tech.groups.yahoo.com/group/xml-rpc/message/6653 Finally, about the Redstone problem that led me to post this report: "I have just looked at the Redstone Bas64 decoder and it's obviously broken. The code correctly ignores whitespace characters but then complains that the data is too short." I have filed a bug report against Redstone: http://sourceforge.net/tracker/index.php?func=detail&aid=1753822&group_id=25164&atid=383547 From the responses so far, I don't think a change to Python's behavior is warranted. I *do* still think it would be useful to clarify the xmlrpclib documentation as I've suggested in this bug report, so users know what to expect. Is there any good reason NOT to do this? A link to the official spec at http://www.xmlrpc.com/spec should also be added to the "See also" links, possibly along with a link to Fred's unofficial errata at http://effbot.org/zone/xmlrpc-errata.htm -- Comment By: Martin v. Löwis (loewis) Date: 2007-07-14 08:51 Message: Logged In: YES user_id=21627 Originator: NO Note that RFC 3548 is informational, so it is not a specification (at least not of an internet protocol). Also notice that Python'
