[issue7897] Support parametrized tests in unittest
Andrew Bennetts added the comment: You may be interested an existing, unittest-compatible library that provides this: http://pypi.python.org/pypi/testscenarios -- nosy: +spiv ___ Python tracker <http://bugs.python.org/issue7897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9729] Unconnected SSLSocket.{send, recv} raises TypeError: 'member_descriptor' object is not callable
New submission from Andrew Bennetts :
ython 2.6.6 (r266:84292, Aug 24 2010, 21:47:18)
[GCC 4.4.5 20100816 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket, ssl
>>> s = socket.socket()
>>> wrapped = ssl.wrap_socket(s)
>>> wrapped.recv(1)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.6/ssl.py", line 217, in recv
return socket.recv(self, buflen, flags)
TypeError: 'member_descriptor' object is not callable
What I expected was a more helpful error, like the unwrapped socket gives:
>> s.recv(1)
Traceback (most recent call last):
File "", line 1, in
socket.error: [Errno 107] Transport endpoint is not connected
The full list of affected methods are all the _delegate_methods from socket.py:
_delegate_methods = ("recv", "recvfrom", "recv_into", "recvfrom_into",
"send", "sendto")
The cause is that the SSLSocket subclass is trying to upcall to the
_socketobject base class, but the base does not have methods for those, just
__slots__ for the instance to fill in with bound methods.
--
messages: 115286
nosy: spiv
priority: normal
severity: normal
status: open
title: Unconnected SSLSocket.{send,recv} raises TypeError: 'member_descriptor'
object is not callable
versions: Python 2.6, Python 2.7
___
Python tracker
<http://bugs.python.org/issue9729>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9729] Unconnected SSLSocket.{send, recv} raises TypeError: 'member_descriptor' object is not callable
Changes by Andrew Bennetts : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue9729> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9729] Unconnected SSLSocket.{send, recv} raises TypeError: 'member_descriptor' object is not callable
Andrew Bennetts added the comment: Here's a conservative fix for Python 2.7. It replaces the attempts to call baseclass.method with direct calls to the decorated object (i.e. replace socket.meth(self, ...) with self._sock.meth(...)). It also corrects a bunch of incorrect arguments being passed to _sock... it's pretty clear this code was not tested. I've added a test that exercises each SSLSocket method that corresponds to a socket._delegate_method. A nicer solution is to simply make socket.socket actually be a simple subclass of _socket.socket rather than the weird decorator it is now. This has already happened on the py3k branch, which is why it doesn't have this bug. -- keywords: +patch Added file: http://bugs.python.org/file18878/issue9729.patch ___ Python tracker <http://bugs.python.org/issue9729> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9729] Unconnected SSLSocket.{send, recv} raises TypeError: 'member_descriptor' object is not callable
Andrew Bennetts added the comment: > Yes, but such a rearchitecting to the socket module is out of question > for 2.x, which is in bugfix mode. Yes of course, which is why I made the conservative fix instead :) -- ___ Python tracker <http://bugs.python.org/issue9729> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3867] What's New in 2.6 doesn't mention stricter object.__init__
New submission from Andrew Bennetts <[EMAIL PROTECTED]>: http://bugs.python.org/issue1683368 changed object.__init__ so that rejects args/kwargs. This change should be mentioned in the "What's New in Python 2.6" document, probably under the "Porting to Python 2.6" heading. (I noticed this because the stricter object.__init__ has made Python 2.6rc1 (and probably earlier) incompatible with Bazaar, which in one or two places happened to depend on the pre-2.6 behaviour.) -- assignee: georg.brandl components: Documentation messages: 73215 nosy: georg.brandl, spiv severity: normal status: open title: What's New in 2.6 doesn't mention stricter object.__init__ versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3867> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8354] siginterrupt with flag=False is reset when signal received
New submission from Andrew Bennetts : The effect of signal.siginterrupt(somesig, False) is reset the first time a that signal is received. This is not the documented behaviour, and I do not think this is a desireable behaviour. It renders siginterrupt effectively useless at providing the robustness against EINTR it is intended to provide. Attached is a fairly simple program to show this using SIGWINCH: run it in a resizeable terminal, and resize it twice. Notice that on the second terminal resize (i.e. the second SIGWINCH signal) the program crashes with an EINTR from the os.read. A partial workaround for the problem is to call signal.siginterrupt(somesig, False) again inside your signal handler, but it's very fragile. It depends on Python getting a chance to run the Python function registered by the signal.signal call, but this is not guaranteed. If there's frequent IO, that workaround might suffice. For the sig-test.py example attached to this bug, it doesn't (try it). The cause seems to be that signal_handler in signalmodule.c unconditionally does PyOS_setsig(sig_num, signal_handler) [except for SIGCHLD], which unconditionally invokes siginterrupt(sig, 1). A possible fix would be to add a 'int siginterrupt_flag;' to the Handlers array, and arrange for that value to be passed instead of the hard-coded 1. Another might be to not call PyOS_setsig from signal_handler at all -- I'm not sure why it is trying to reinstall itself, but perhaps there's some issue there I'm not aware of. -- components: Library (Lib) files: sig-test.py messages: 102688 nosy: spiv severity: normal status: open title: siginterrupt with flag=False is reset when signal received type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file16837/sig-test.py ___ Python tracker <http://bugs.python.org/issue8354> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7978] SocketServer doesn't handle syscall interruption
Andrew Bennetts added the comment: Note that a trivial untilConcludes isn't correct for select if a timeout was passed. If a select(..., 60) was interrupted after 59 seconds, you probably want to restart it with a timeout of 1 second, not 60. The SocketServer_eintr.diff patch has this flaw. -- nosy: +spiv ___ Python tracker <http://bugs.python.org/issue7978> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8354] siginterrupt with flag=False is reset when signal received
Andrew Bennetts added the comment: Your patches look good to me. (They don't fix platforms without sigaction, but as you say they probably don't have siginterrupt, and even if they do they will still have an unfixable race.) What's the next step? I can't see an button to add this issue to the "Show Needing Review" queue. -- ___ Python tracker <http://bugs.python.org/issue8354> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8354] siginterrupt with flag=False is reset when signal received
Andrew Bennetts added the comment: Are there any platforms that define HAVE_SIGINTERRUPT but that do not define HAVE_SIGACTION? If there are, then yes I expect they would fail that test. It would be a shame to delay this fix just because it doesn't fix all platforms... is it possible to mark that test as a known failure on a platform with siginterrupt but without sigaction? My initial comment outlined a change that would work for all platforms, but would be more complex. (I think the signal_noreinstall.diff change would be good to make even with the more complex approach, though.) -- ___ Python tracker <http://bugs.python.org/issue8354> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8354] siginterrupt with flag=False is reset when signal received
Andrew Bennetts added the comment: FWIW, comparing the "change history" sections of <http://www.opengroup.org/onlinepubs/95399/functions/siginterrupt.html> and <http://www.opengroup.org/onlinepubs/95399/functions/sigaction.html> suggests that sigaction predates siginterrupt, but it's a wild and varied world out there. -- ___ Python tracker <http://bugs.python.org/issue8354> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
Changes by Andrew Bennetts : -- nosy: +spiv ___ Python tracker <http://bugs.python.org/issue8407> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8354] siginterrupt with flag=False is reset when signal received
Andrew Bennetts added the comment: > I'm not exactly sure how we will know if it is expected to fail, > though. I don't think `HAVE_SIGACTION` is exposed nicely to Python > right now. It might be useful to have the contents of pyconfig.h exposed as a dict somehow. Maybe call it sys._pyconfig_h? A less ambitious change would be to expose just HAVE_SIGACTION as e.g. signal._have_sigaction. I agree with r.david.murray that we probably don't need to bother unless a buildbot or someone reports that this test fails. -- ___ Python tracker <http://bugs.python.org/issue8354> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8685] set(range(100000)).difference(set()) is slow
New submission from Andrew Bennetts : set.difference(s), when s is also a set, basically does:: res = set() for elem in self: if elem not in other: res.add(elem) This is wasteful when len(self) is much greater than len(other): $ python -m timeit -s "s = set(range(10)); sd = s.difference; empty = set()" "sd(empty)" 100 loops, best of 3: 12.8 msec per loop $ python -m timeit -s "s = set(range(10)); sd = s.difference; empty = set()" "sd(empty)" 100 loops, best of 3: 1.18 usec per loop Here's a patch that compares the lengths of self and other before that loop, and if len(self) is greater, swaps them. The new timeit results are: $ python -m timeit -s "s = set(range(10)); sd = s.difference; empty = set()" "sd(empty)" 100 loops, best of 3: 0.289 usec per loop $ python -m timeit -s "s = set(range(10)); sd = s.difference; empty = set()" "sd(empty)" 100 loops, best of 3: 0.294 usec per loop -- components: Interpreter Core files: set-difference-speedup.diff keywords: patch messages: 105489 nosy: spiv priority: normal severity: normal status: open title: set(range(10)).difference(set()) is slow type: performance versions: Python 2.7 Added file: http://bugs.python.org/file17292/set-difference-speedup.diff ___ Python tracker <http://bugs.python.org/issue8685> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8685] set(range(100000)).difference(set()) is slow
Andrew Bennetts added the comment:
Oops, obvious bug in this patch. set('abc') - set('bcd') != set('bcd') -
set('abc'). I'll see if I can make a more sensible improvement.
See also <http://bugs.python.org/issue8425>. Thanks dickinsm on #python-dev.
--
___
Python tracker
<http://bugs.python.org/issue8685>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8685] set(range(100000)).difference(set()) is slow
Andrew Bennetts added the comment: Ok, this time test_set* passes :) Currently if you have large set and small set the code will do len(large) lookups in the small set. When large is >> than small, it is cheaper to copy large and do len(small) lookups in large. On my laptop a size difference of 4 times is a clear winner for copy+difference_update over the status quo, even for sets of millions of entries. For more similarly sized sets (even only factor of 2 size difference) the cost of allocating a large set that is likely to be shrunk significantly is greater than the benefit. So my patch only switches behaviour for len(x)/4 > len(y). This patch is complementary to the patch in issue8425, I think. -- Added file: http://bugs.python.org/file17293/set-difference-speedup-2.diff ___ Python tracker <http://bugs.python.org/issue8685> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8685] set(range(100000)).difference(set()) is slow
Changes by Andrew Bennetts : Added file: http://bugs.python.org/file17306/set-mem.py ___ Python tracker <http://bugs.python.org/issue8685> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8685] set(range(100000)).difference(set()) is slow
Andrew Bennetts added the comment: Regarding memory, good question... but this patch turns out to be an improvement there too. This optimisation only applies when len(x) > len(y) * 4. So the minimum size of the result is a set with 3/4 of the elems of x (and possibly would be a full copy of x anyway). So if you like this optimisation is simply taking advantage of the fact we're going to be copying almost all of these elements anyway. We could make it less aggressive, but large sets are tuned to be between 1/2 and 1/3 empty internally anyway, so 1/4 overhead seems reasonable. Also, because this code immediately makes the result set be about the right size, rather than growing it one element at a time, the memory consumption is actually *better*. I'll attach a script that demonstrates this; for me it shows that large_set.difference(small_set) [where large_set has 4M elems, small_set has 100] peaks at 50MB memory consumption without my patch, but only 18MB with. (after discounting the memory required for large_set itself, etc.) -- ___ Python tracker <http://bugs.python.org/issue8685> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4753] Faster opcode dispatch on gcc
Changes by Andrew Bennetts : -- nosy: +spiv ___ Python tracker <http://bugs.python.org/issue4753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16997] subtests
Andrew Bennetts added the comment: googletest (an xUnit style C++ test framework) has an interesting feature: in addition to assertions like ASSERT_EQ(x, y) that stop the test, it has EXPECT_EQ(x, y) etc that will cause the test to fail without causing it to stop. I think this decoupling of “test failed” and “test execution stopped” is very useful. (Note this also implies a single test can have multiple failures, or if you prefer that a single test can have multiple messages attached to explain why its state is 'FAILED'.) I wouldn't like to see a duplication of all assert* methods as expect* methods, but there are alternatives. A single self.expectThat method that takes a value and a matcher, for instance. Or you could have a context manager: with self.continueOnFailure(): self.assertEqual(x, y) In fact, I suppose that's more-or-less what the subtests patch offers? Except the subtests feature seems to want to get involved in knowing about parameters and the like too, which feels weird to me. Basically, I really don't like the “subtests” name, but if instead it's named something that directly says its only effect is that failures don't abort the test, then I'd be happy. -- ___ Python tracker <http://bugs.python.org/issue16997> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5660] Cannot deepcopy unittest.TestCase instances
New submission from Andrew Bennetts :
Here's a demonstration of the bug:
>>> from unittest import TestCase
>>> class MyTest(TestCase):
... def test_foo(self): pass
...
>>> tc = MyTest('test_foo')
>>> import copy
>>> copy.deepcopy(tc)
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/stow/py2.7/lib/python2.7/copy.py", line 189, in deepcopy
y = _reconstruct(x, rv, 1, memo)
File "/usr/local/stow/py2.7/lib/python2.7/copy.py", line 338, in
_reconstruct
state = deepcopy(state, memo)
File "/usr/local/stow/py2.7/lib/python2.7/copy.py", line 162, in deepcopy
y = copier(x, memo)
File "/usr/local/stow/py2.7/lib/python2.7/copy.py", line 255, in
_deepcopy_dict
y[deepcopy(key, memo)] = deepcopy(value, memo)
File "/usr/local/stow/py2.7/lib/python2.7/copy.py", line 162, in deepcopy
y = copier(x, memo)
File "/usr/local/stow/py2.7/lib/python2.7/copy.py", line 255, in
_deepcopy_dict
y[deepcopy(key, memo)] = deepcopy(value, memo)
File "/usr/local/stow/py2.7/lib/python2.7/copy.py", line 189, in deepcopy
y = _reconstruct(x, rv, 1, memo)
File "/usr/local/stow/py2.7/lib/python2.7/copy.py", line 323, in
_reconstruct
y = callable(*args)
File "/usr/local/bin/../stow/py2.7/lib/python2.7/copy_reg.py", line
93, in __newobj__
return cls.__new__(cls, *args)
TypeError: instancemethod expected at least 2 arguments, got 0
This regression breaks bzr's test suite, which copies test objects to
run the same test against multiple scenarios (e.g. to run all the same
tests against all the implementations of bzrlib.transport.Transport,
such as HTTPTransport and SFTPTransport.)
<https://launchpad.net/testtools> also implements test parameterisation
in this way, and it is extremely useful.
I suspect the __test_equality_funcs on TestCase is the problem:
>>> tc.__dict__
{'_testMethodDoc': None, '_TestCase__type_equality_funcs': {: >, : >, : >, : >, : >}, '_testMethodName': 'test_foo'}
copy.deepcopy can't deepcopy bound methods, reasonably enough.
--
components: Library (Lib)
messages: 85123
nosy: spiv
severity: normal
status: open
title: Cannot deepcopy unittest.TestCase instances
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue5660>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8685] set(range(100000)).difference(set()) is slow
Andrew Bennetts added the comment: Antoine: Thanks for the updated benchmark results! I should have done that myself earlier. -- ___ Python tracker <http://bugs.python.org/issue8685> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9543] 2.6.6 rc1 socket.py flush() calls del on unbound 'view' variable
Andrew Bennetts added the comment:
I have a reproduction script on the Ubuntu bug report I just filed for this
issue: <https://bugs.launchpad.net/ubuntu/+source/python2.6/+bug/615240>
Pasting here for convenience:
"""
import socket
import threading
sock_a, sock_b = socket.socketpair()
sock_a = socket.socket(_sock=sock_a)
def read_byte_then_close(s):
data = s.recv(1)
s.close()
t = threading.Thread(target=read_byte_then_close, args=(sock_b,))
t.start()
file_a = sock_a.makefile('w')
file_a.writelines(['a'*8192]*1000)
file_a.flush()
t.join()
"""
It's not quite good enough to add to the test suite yet IMO, but it's a
starting point.
--
nosy: +spiv
___
Python tracker
<http://bugs.python.org/issue9543>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8685] set(range(100000)).difference(set()) is slow
Andrew Bennetts added the comment: On 2010-05-17 rhettinger wrote: > Will look at this when I get back to the U.S. Ping! This patch (set-difference-speedup-2.diff) has been sitting around for a fair few weeks now. It's a small patch, so it should be relatively easy to review. It makes a significant improvement to speed and memory in one case (which we have encountered and worked around in bzr), and has no significant downside to any other cases. Thanks :) -- ___ Python tracker <http://bugs.python.org/issue8685> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9543] 2.6.6 rc1 socket.py flush() calls del on unbound 'view' variable
Andrew Bennetts added the comment:
Chatting with Taggnostr on IRC I've trimmed that reproduction down to something
much cleaner (no magic numbers or threads involved):
import socket
sock_a, sock_b = socket.socketpair()
sock_a = socket.socket(_sock=sock_a)
sock_b.close()
file_a = sock_a.makefile('w')
file_a.write('x')
file_a.flush()
--
___
Python tracker
<http://bugs.python.org/issue9543>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8685] set(range(100000)).difference(set()) is slow
Andrew Bennetts added the comment: Alexander: yes, they are complementary. My patch improves set.difference, which always creates a new set. issue8425 on the other hand improves in-place difference (via the -= operator or set.difference_update). Looking at the two patches, my patch will not improve in-place difference, and issue8425's patch will not improve set.difference. So they are complementary. -- ___ Python tracker <http://bugs.python.org/issue8685> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
