Roundup Robot added the comment:
New changeset 83ea55a1204a by Berker Peksag in branch '3.4':
Issue #24857: Comparing call_args to a long sequence now correctly returns a
https://hg.python.org/cpython/rev/83ea55a1204a
New changeset df91c1879e56 by Berker Peksag in branch '3.5':
Issue #24857:
Berker Peksag added the comment:
Thanks!
For the record, the __ne__ issue created by A Kaptur is issue 24997.
--
nosy: +berker.peksag
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
A Kaptur added the comment:
It looks like there's a related bug in call_args around __ne__:
>>> m = Mock()
>>> m(1,2)
>>> m.call_args
call(1, 2)
>>> m.call_args == call(1,2)
True
>>> m.call_args != call(1,2)
True
Any reason not to define __ne__ as not __eq__? Otherwise it looks like you fall
A Kaptur added the comment:
Here's a simple patch + test for the original bug. I'll file the __ne__
question separately.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file40348/issue24857.patch
___
Python
Changes by Wilfred Hughes yowilf...@gmail.com:
--
title: Crash on comparing call_args with long strings - mock: Crash on
comparing call_args with long strings
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24857
Wilfred Hughes added the comment:
This caught me by surprise and I spent a while debugging due to this issue.
Isn't it reasonable that I can compare two values in Python without exceptions
being raised?
(1, 2) == foob
False
I'm happy to write a patch.
--
Wilfred Hughes added the comment:
This bug is particularly subtle because it only applies to *long* strings.
m.call_args == f
False
m.call_args == fo
False
m.call_args == foo
False
m.call_args == foob
Traceback (most recent call last):
File stdin, line 1, in module
File
Michael Foord added the comment:
Ok, fair enough.
--
resolution: not a bug -
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24857
___
R. David Murray added the comment:
Yeah, if it isn't comparable it should return either False or NotImplemented,
not raise an exception. False would be better here, I think.
--
keywords: +easy
nosy: +r.david.murray
___
Python tracker