Re: [Python-Dev] dict containment annoyance
Jean-Paul Calderone wrote: > def blacklisted(o): > try: > # Is the object contained in the blacklist set? > return o in _blacklistset > except TypeError: > # If it *cannot* be contained in the blacklist set, > # then it probably isn't. > return False I feel confident that the parent could've wrote this snippet himself. His point was to discuss the semantic logic of "x in y" throwing and exception when x can't be in y (because of the TypeError you are catching in your snippet). FWIW, I think the logic of swallowing the TypeError is completely reasonable. It is surprising in a way that you are presented with an exception. However, I can't say I have ever ran into this. For my money, it would make the most sense to have your own blacklistset type. class BlacklistSet(dict): def __contains__(self, x): try: hash(x) except TypeError: return False return super(BlacklistSet, self).__contains__(x) It's however unfortunate that you cannot use the handy curly-braces anymore. -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test_socketserver failure on cygwin
I'm not sure if this is a race condition in the test, the test using SocketServer inappropriately, or if the failure is exposing a problem in SocketServer. The issue is that when the second (UDP) server is setup, there is still a child process from the first (TCP) server. So when the UDP server calls collect_children(), it gets back the pid from the TCP server, which is not in the UDP server's list and an exception is raised. In general, this is a problem, if program is using a ForkingServer and spawns it's own children, this problem can occur. This is because os.waitpid() is called with a pid of 0, rather than the individual pids in the list. I suppose that would fix the problem. Is this worth fixing? (It's a pain to handle properly because there is also use of a blocking wait.) http://www.python.org/dev/buildbot/all/x86%20cygwin%20trunk/builds/1107/step-test/0 Add this patch corrects the problem (see below for more details): Index: Lib/test/test_socketserver.py === --- Lib/test/test_socketserver.py (revision 51260) +++ Lib/test/test_socketserver.py (working copy) @@ -183,7 +183,11 @@ def testall(): testloop(socket.AF_INET, tcpservers, MyStreamHandler, teststream) +time.sleep(.1) +reap_children() testloop(socket.AF_INET, udpservers, MyDatagramHandler, testdgram) +time.sleep(.1) +reap_children() if hasattr(socket, 'AF_UNIX'): testloop(socket.AF_UNIX, streamservers, MyStreamHandler, teststream) # Alas, on Linux (at least) recvfrom() doesn't return a meaningful So modifying SocketServer like this: -bash-3.1$ svn diff Lib/SocketServer.py Lib/test/test_socketserver.py Index: Lib/SocketServer.py === --- Lib/SocketServer.py (revision 51260) +++ Lib/SocketServer.py (working copy) @@ -420,6 +420,7 @@ except os.error: pid = None if not pid: break +print >> sys.__stdout__, 'pid', pid, 'active', self.active_children self.active_children.remove(pid) def process_request(self, request, client_address): @@ -428,6 +429,7 @@ pid = os.fork() if pid: # Parent process +print >> sys.__stdout__, 'in parent, adding', pid, self.active_children if self.active_children is None: self.active_children = [] self.active_children.append(pid) We see this on error (prior to the test patch above): test_socketserver in parent, adding 3084 None pid 3084 active [3084] in parent, adding 2408 [] pid 2408 active [2408] in parent, adding 3908 [] in parent, adding 532 None pid 3908 active [532] Exception in thread Thread-12: Traceback (most recent call last): ... File "/home/neal/build/python/trunk/Lib/SocketServer.py", line 424, in collect_children self.active_children.remove(pid) ValueError: list.remove(x): x not in list ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dict containment annoyance
On 8/13/06, Scott Dial <[EMAIL PROTECTED]> wrote: > FWIW, I think the logic of swallowing the TypeError is completely > reasonable. Then you haven't debugged enough Python programs. Swallowing an exception of *any* kind is always a trap waiting to shut when you least expect it, because you have no control over what other operations might cause an exception. E.g. when you write try: hash(x) except TypeError: # apparently x is not hashable then you're also swallowing any type errors in the computation of a legitimate hash function. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] NotHashableError? (Re: dict containment annoyance)
Guido van Rossum wrote: > try: > hash(x) > except TypeError: > # apparently x is not hashable > > then you're also swallowing any type errors in the computation of a > legitimate hash function. Maybe it would help if there were a specific exception, such as NotHashableError, that hash functions were expected to raise in this situation instead of a generic TypeError. For backwards compatibility it could be a subclass of TypeError. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] NotHashableError? (Re: dict containment annoyance)
Greg Ewing wrote: > Guido van Rossum wrote: >> try: >> hash(x) >> except TypeError: >> # apparently x is not hashable >> >> then you're also swallowing any type errors in the computation of a >> legitimate hash function. > > Maybe it would help if there were a specific exception, > such as NotHashableError, that hash functions were > expected to raise in this situation instead of a > generic TypeError. I was going to suggest this, but then I realized that what is really desirable is a check for hashability. But since hashability is a deep property, it is difficult to check for.. seems like an very specific exception type would be a simple solution. FYI, I appreciate that swallowing all TypeErrors is bad form, so it would be nice if it was possible to differentiate ;-) Some brief googling on the subject yield a discussion on py3k about this very subject. http://mail.python.org/pipermail/python-3000/2006-July/002697.html Guido wrote: > Personally, I'm not sure this problem needs solving; I don't recall > ever needing to know whether something is hashable. So perhaps it's of > purely theoretical importance? That would suit me fine given the above > dilemma... > > --Guido -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
