[issue15323] Provide target name in output message when Mock.assert_called_once_with fails
New submission from Brian Jones bkjo...@gmail.com:
In Python 3.3.0b1, if the number of calls to a mock is, say, zero, and you call
assert_called_once_with() on that mock, it will throw an exception which says
Expected to be called once. Called 0 times.
This is nice, but it would be nicer if the output message actually told the end
user *what* it expected to be called once. I've supplied a patch and
documentation update that makes this change by adding _mock_name to the output
message using the variable interpolation method already being used in that
message to output the call count.
The result looks like this (for the case in the documentation):
Python 3.3.0b1 (default:2ecdda96f970+, Jul 10 2012, 22:45:18)
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
Type help, copyright, credits or license for more information.
from unittest.mock import Mock
[103576 refs]
mock = Mock(return_value=None)
[103641 refs]
mock('foo', bar='baz')
[103679 refs]
mock.assert_called_once_with('foo', bar='baz')
[103680 refs]
mock('foo', bar='baz')
[103703 refs]
mock.assert_called_once_with('foo', bar='baz')
Traceback (most recent call last):
File stdin, line 1, in module
File /Users/brianj/Dropbox/Source/Python/cpython/Lib/unittest/mock.py, line
736, in assert_called_once_with
raise AssertionError(msg)
AssertionError: Expected 'mock' to be called once. Called 2 times.
[103758 refs]
In the above case, the mock was never given a name, and wasn't instantiated
with any particular target. Here's an example using a patch on 'time.time' to
show the effect:
Python 3.3.0b1 (default:2ecdda96f970+, Jul 10 2012, 22:45:18)
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
Type help, copyright, credits or license for more information.
from unittest.mock import patch
[106009 refs]
with patch('time.time') as foo:
... foo.assert_called_once_with()
...
Traceback (most recent call last):
File stdin, line 2, in module
File /Users/brianj/Dropbox/Source/Python/cpython/Lib/unittest/mock.py, line
736, in assert_called_once_with
raise AssertionError(msg)
AssertionError: Expected 'time' to be called once. Called 0 times.
[106621 refs]
--
components: Library (Lib)
files: mock_assert_called_once_with_output_update.patch
keywords: patch
messages: 165223
nosy: Brian.Jones
priority: normal
severity: normal
status: open
title: Provide target name in output message when Mock.assert_called_once_with
fails
type: enhancement
versions: Python 3.3
Added file:
http://bugs.python.org/file26348/mock_assert_called_once_with_output_update.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15323
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14819] Add `assertIsSubclass` and `assertNotIsSubclass` to `unittest.TestCase`
Brian Jones bkjo...@gmail.com added the comment: I can't find a previous discussion of this topic. If you know the list it happened on, or the bug#, let me know as I'd be curious to see the discussion. While I could concede that checking type is arguably a more common case than checking ancestry, I think that checks like assertIsSubclass have a lot of value. First, if you view your collection of unit tests as pools of change detectors, this type of check is very valuable in order to detect changes in ancestry that result from a refactoring. Second, if you use a test-driven style of development, this is a very convenient method to have as your tests and code evolve, because the amount of code you have to write to create a failing test becomes a one-liner. As an aside, I *would* like to see the submitted patch provide more detail upon failure. Namely, if X is not a subclass of Y, it would be nice to know what it *is* a subclass of in the resulting output. -- nosy: +Brian.Jones status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14278] email.utils.localtime throws exception if time.daylight is False
Changes by Brian Jones bkjo...@gmail.com: -- nosy: +Brian.Jones ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14278 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14278] email.utils.localtime throws exception if time.daylight is False
Changes by Brian Jones bkjo...@gmail.com: -- nosy: +r.david.murray -Brian.Jones ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14278 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14293] Message methods delegated via __getattr__ inaccessible using super().method
New submission from Brian Jones bkjo...@gmail.com: In email6, the message.Message class tries to delegate calls to methods not defined in Message to message._HeaderList. However, delegating in this way makes the methods inaccessible when accessing them through a call to super(). This comes into play in the http.HTTPMessage class, which attempts to call the _HeaderList 'get' method as 'super().get()'. An AttributeError is raised in this case, because super is only examining the class, and not the instance, and isn't executing __getattr__ to get at methods defined in _HeaderList methods. I've attached a patch that only patches the appropriate test module to add a test to prove the failure. The fix involves a bit more complexity, and I've had some trouble getting my brain to not reject the kind of conflation of concepts and overlapping of responsibility that needs to take place to implement the ideas I was able to come up with. I'm happy to help implement a sane solution if anyone has other ideas. A couple of ideas that came up (at the PyCon sprints) were: 1. Make _HeaderList *not* extend 'list', and then have Message inherit from _HeaderList. However, that means basically reimplementing all of the methods in the 'list' interface inside of _HeaderList, and by extension, Message becomes something of a 'list' object for the purpose of header manipulation, but not for anything else (like, say, payload). 2. Just get rid of _HeaderList and put it all inside of Message. See item 1 for issues with this idea. 3. Expose a public 'headers' attribute, which opens a lot of doors in terms of design flexibility, elegance, and cleanliness, but changes the API. 4. Create a base class that defines the non-list-specific interface for _HeaderList. _HeaderList would then inherit from this class, adding the list-specific methods on top, and Message would inherit it and only override non-list-specific methods. This could have some benefits in terms of testing, but arguably it muddies the waters for those maintaining/extending the _HeaderList or Message code. Other ideas? Also let me know if I've done something silly in writing the test to trigger the problem. -- components: Library (Lib) files: msg_api_subclass_bug_test.patch keywords: patch messages: 155679 nosy: Brian.Jones, r.david.murray priority: normal severity: normal status: open title: Message methods delegated via __getattr__ inaccessible using super().method versions: Python 3.3 Added file: http://bugs.python.org/file24829/msg_api_subclass_bug_test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14293 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14278] email.utils.localtime throws exception if time.daylight is False
New submission from Brian Jones bkjo...@gmail.com: In email.utils.localtime, there's a variable 'offset' that will only exist if time.daylight evaluates to True. If time.daylight evaluates to False, you'll get an UnboundLocalError, because 'offset' is being referenced without being assigned. The attached patch fixes that issue, adds several tests, and also refactors an existing test containing 4-5 assertions into a test for each assertion. -- components: Library (Lib) files: localtime_fix.patch keywords: patch messages: 155535 nosy: Brian.Jones priority: normal severity: normal status: open title: email.utils.localtime throws exception if time.daylight is False versions: Python 3.3 Added file: http://bugs.python.org/file24808/localtime_fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14278 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12527] assertRaisesRegex doc'd with 'msg' arg, but it's not implemented?
Brian Jones bkjo...@gmail.com added the comment: I've just done a fresh hg pull and new build, and I can no longer reproduce the problem. Yay! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12527] assertRaisesRegex doc'd with 'msg' arg, but it's not implemented?
New submission from Brian Jones bkjo...@gmail.com:
The documentation here:
http://docs.python.org/dev/library/unittest.html#unittest.TestCase.assertRaisesRegex
Indicates that, when used as a context manager, assertRaisesRegex should accept
a keyword argument 'msg'. However, that doesn't appear to actually be
implemented. I've just now done an hg pull, and in Lib/unittest/case.py, the
source is here:
def assertRaisesRegex(self, expected_exception, expected_regex,
callable_obj=None, *args, **kwargs):
Asserts that the message in a raised exception matches a regex.
Args:
expected_exception: Exception class expected to be raised.
expected_regex: Regex (re pattern object or string) expected
to be found in error message.
callable_obj: Function to be called.
msg: Optional message used in case of failure. Can only be used
when assertRaisesRegex is used as a context manager.
args: Extra args.
kwargs: Extra kwargs.
context = _AssertRaisesContext(expected_exception, self, callable_obj,
expected_regex)
return context.handle('assertRaisesRegex', callable_obj, args, kwargs)
I noticed this after attempting some simple example uses of assertRaisesRegex.
Perhaps I'm just missing something that will be made obvious to others by
seeing them. These are just various attempts to get my msg shown somewhere in
the output:
#!/usr/bin/env python3.3
import unittest
class TestInt(unittest.TestCase):
def test_intfail(self):
# this test should *not* fail, and doesn't
with self.assertRaisesRegex(ValueError, 'literal'):
int('XYZ')
def test_intfail2(self):
# should not fail, and doesn't
with self.assertRaisesRegex(ValueError, 'lambda', msg='Foo!'):
int('ABC')
def test_intfail3(self):
# should fail, and does, but no msg to be found.
with self.assertRaisesRegex(ValueError, 'literal', msg='Foo!'):
int(1)
def test_intfail4(self):
# should fail, and does, but no msg to be found.
with self.assertRaisesRegex(TypeError, 'literal', msg='Foo!'):
int('ABC')
if __name__ == '__main__':
unittest.main()
--
components: Library (Lib)
messages: 140084
nosy: Brian.Jones
priority: normal
severity: normal
status: open
title: assertRaisesRegex doc'd with 'msg' arg, but it's not implemented?
type: behavior
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12527
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12527] assertRaisesRegex doc'd with 'msg' arg, but it's not implemented?
Brian Jones bkjo...@gmail.com added the comment:
No, I'm not. I'm sorry for not including this output initially. Here's what I
get (and I've added a sys.version_info line just to be double sure the right
executable is being invoked at runtime):
sys.version_info(major=3, minor=3, micro=0, releaselevel='alpha', serial=0)
.FFE
==
ERROR: test_intfail4 (__main__.TestInt)
--
Traceback (most recent call last):
File ./test_int.py, line 21, in test_intfail4
int('ABC')
ValueError: invalid literal for int() with base 10: 'ABC'
==
FAIL: test_intfail2 (__main__.TestInt)
--
ValueError: invalid literal for int() with base 10: 'ABC'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File ./test_int.py, line 13, in test_intfail2
int('ABC')
AssertionError: lambda does not match invalid literal for int() with base
10: 'ABC'
==
FAIL: test_intfail3 (__main__.TestInt)
--
Traceback (most recent call last):
File ./test_int.py, line 17, in test_intfail3
int(1)
AssertionError: ValueError not raised
--
Ran 4 tests in 0.001s
FAILED (failures=2, errors=1)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12527
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12527] assertRaisesRegex doc'd with 'msg' arg, but it's not implemented?
Brian Jones bkjo...@gmail.com added the comment: If there's some reason, based on the source snippet I posted from case.py, that my msg should be making it to the output, can someone explain why/how it should get there? I don't see any reason, from looking at the source, that 'msg' should even be expected to make it to the output. Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11113] html.entities mapping dicts need updating?
New submission from Brian Jones bkjo...@gmail.com: In Python 3.2b2, html.entities.codepoint2name and name2codepoint only support the 252 HTML entity names defined in the HTML 4 spec from 1997. I'm wondering if there's a reason not to support W3C Recommendation 'XML Entity Definitions for Characters' http://www.w3.org/TR/xml-entity-names/ This standard contains significantly more characters, and it is noted in that spec that the HTML 5 drafts use that spec's entities. You can see the current HTML 5 'Named character references' here: http://www.w3.org/TR/html5/named-character-references.html#named-character-references If this is just a matter of somebody going in to do the grunt work, let me know. If startup costs associated with importing a huge dictionary are a concern, perhaps a more efficient type that enables the same lookup interface can be defined. If other reasons exist to not move in this direction, please do let me know! -- components: Library (Lib), Unicode, XML messages: 127865 nosy: Brian.Jones priority: normal severity: normal status: open title: html.entities mapping dicts need updating? type: feature request versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10510] distutils upload/register should use CRLF in HTTP requests
Brian Jones bkjo...@gmail.com added the comment: Sure. I'll create a patch in the next few days and submit it. Thanks for the link to the guidelines. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10510] distutils upload/register should use CRLF in HTTP requests
Brian Jones bkjo...@gmail.com added the comment: So... have I missed a memo, or is it currently impossible to test the current svn version of distutils in the current svn version of Python? The tests for (at least) register and upload are written using Python 2.x syntax and modules. How are new features and fixes for distutils being tested? Is it valid to use a 2.x version of Python to test the trunk version of distutils? Sorry if these questions have really obvious answers. First time patcher :? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10510] distutils upload/register should use CRLF in HTTP requests
Brian Jones bkjo...@gmail.com added the comment: If it's not a bug in distutils1, I imagine it will not be a bug in distutils2, since that will also presumably work with PyPI, and PyPI will be the single solitary supported implementation of the service? I also don't see distutils2 in this list http://svn.python.org/projects/ which means either distutils2 isn't part of the standard library, or it doesn't follow the documented patch submission process, or perhaps both? Insight welcome here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10510] distutils.command.upload/register HTTP message headers: bad line termination
Brian Jones bkjo...@gmail.com added the comment: In truth, I don't personally know if the other PyPI server implementations also have to work around this issue. Other comments on that are welcome. As for my own implementation, I've implemented a workaround to this, but I'm working around and reimplementing what is otherwise a feature built into the server (and every other one). I believe the suggested change makes the world a better place, and having administered several different web servers, I can't imagine ill effects from making the change. Web servers support *at least* the standard. Any ill effects we might imagine are, at least for my part, pure speculation. I, on the other hand, have found a real-life problem now :) I guess in the end I think that servers are more likely to err on the side of strict HTTP than make allowances for every SHOULD in the protocol spec, and leaving things as-is relies on a SHOULD, which I submit is incorrect behavior, and therefore a bug. It's not like a fix is going to magically improve my life, as I'll have to support older buggy versions anyway, but making the change now can help grease the wheels for future implementations who won't have to hit this hurdle. My $.02. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10510] distutils.command.upload/register HTTP message headers: bad line termination
New submission from Brian Jones bkjo...@gmail.com: In trying to write a PyPI service, I of course need to support the registration and upload features of setup.py, which uses distutils for those actions. One thing making this a bit more difficult than need be is the fact that distutils.command.register and distutils.command.upload both use bare line feeds as a line terminator in the HTTP message headers. While there are probably tolerant servers out there, I think this behavior should be considered a bug in light of the HTTP spec, which reads: The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR. The second sentence can be interpreted in multiple ways that either agree with or contradict the first sentence, but the first sentence is at least perfectly clear, and I'd like to see \r\n added to the beginning of (specifically in this case) the Content-Disposition headers assembled by distutils.command.upload and distutils.command.register. The change involves taking identical lines in each file that currently look like this: title = '\nContent-Disposition: form-data; name=%s' % key ...and making them look like this: title = '\r\nContent-Disposition: form-data; name=%s' % key The result is that servers which do not support a lax adherence to the protocol will still be able to support users of distutils in Python 2.6, 2.7, and 3.1 (and maybe others). -- messages: 122192 nosy: Brian.Jones priority: normal severity: normal status: open title: distutils.command.upload/register HTTP message headers: bad line termination type: behavior versions: Python 2.6, Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
