[issue24651] Mock.assert* API is in user namespace

2020-11-05 Thread Gregory P. Smith
Change by Gregory P. Smith : -- versions: +Python 3.10 -Python 3.6 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue24651] Mock.assert* API is in user namespace

2020-11-05 Thread Gregory P. Smith
Change by Gregory P. Smith : -- nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24651] Mock.assert* API is in user namespace

2020-10-13 Thread Václav Brožek
Václav Brožek added the comment: As for the assert misspellings raising AttributeError -- that's not true of all of them, only those starting with "assret" or "assert" [1]. In my company, we recently cleaned up a bunch of other assert-misspellings, including cases where a real bug was masked

[issue24651] Mock.assert* API is in user namespace

2020-05-29 Thread Brett Cannon
Change by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24651] Mock.assert* API is in user namespace

2015-07-28 Thread Michael Foord
Michael Foord added the comment: I had a chance to talk to Guido about this at EuroPython. His feeling was that a separate set of functions *is* a better API - or at least would have been if mock had been designed this way from the start. However, the most serious problem with the current

[issue24651] Mock.assert* API is in user namespace

2015-07-28 Thread Erik Bray
Erik Bray added the comment: Would it be possible to add the functions and *not* deprecate assert_ methods? The existing solution is still acknowledged to be an incomplete solution. It is still possible to make other typos that result in unintentional non-assertions (it's also not entirely

[issue24651] Mock.assert* API is in user namespace

2015-07-28 Thread Kevin Benton
Kevin Benton added the comment: I like the idea of having the new module functions without deprecating the old ones. Then projects can encourage use of the API on their own terms. Maybe there could even be a global that projects could set that would disable the object methods... --

[issue24651] Mock.assert* API is in user namespace

2015-07-28 Thread Robert Collins
Robert Collins added the comment: I don't mind if this is open or closed: we've now got a clear set of requirements *should* someone want to work on it:: - it would feel as convenient to use as the current API does - it would be possible to be both forward and backwards compatible with the

[issue24651] Mock.assert* API is in user namespace

2015-07-27 Thread Erik Bray
Erik Bray added the comment: As I wrote (late) in the thread that shall not be named, I don't think it makes any sense to have magic assert_ methods on the Mock object. Not only does the magic clearly lead to too many ambiguities and other problems--I think they make less sense from an API

[issue24651] Mock.assert* API is in user namespace

2015-07-25 Thread Robert Collins
Robert Collins added the comment: Some great points raised here. Yes, we'd need .calls and .returnvalue and so on all made accessible via another route, and that would be a less direct spelling. e.g. a_mock.returnvalue = 3 - # function set_returnvalue(a_mock, 3) or # separate object to get

[issue24651] Mock.assert* API is in user namespace

2015-07-25 Thread Robert Collins
Changes by Robert Collins robe...@robertcollins.net: -- priority: normal - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24651 ___ ___

[issue24651] Mock.assert* API is in user namespace

2015-07-23 Thread Erik Bray
Changes by Erik Bray erik.m.b...@gmail.com: -- nosy: +erik.bray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24651 ___ ___ Python-bugs-list

[issue24651] Mock.assert* API is in user namespace

2015-07-22 Thread Carl Meyer
Carl Meyer added the comment: FWIW, my assumption was that the typical usage pattern would be `import mock` rather than separate imports of all the assertions, so I don't think there'd really be an increase in what users need to know about or import. (They already need to know about the

[issue24651] Mock.assert* API is in user namespace

2015-07-22 Thread Michael Foord
Michael Foord added the comment: I'm not wild about this idea. The problem with the assert methods has *essentially* been solved now, so I'm not convinced of the need for this change (unless users really *need* to have their own mocked attributes like assert_called_with which I think is

[issue24651] Mock.assert* API is in user namespace

2015-07-21 Thread Carl Meyer
Carl Meyer added the comment: Er, I meant `AttributeError`, of course... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24651 ___ ___

[issue24651] Mock.assert* API is in user namespace

2015-07-21 Thread Carl Meyer
Carl Meyer added the comment: As a frequent and long-time user of mock, the `assert_*` methods being on the mock object itself has always struck me as an unfortunate wart on an otherwise great library. The change to raise `AssertionError` on `assert_*` and `assret_*` feels like piling an ugly

[issue24651] Mock.assert* API is in user namespace

2015-07-21 Thread Kevin Benton
Kevin Benton added the comment: What about other methods/properties like called, call_count, and reset_mock? It seems that they should be removed as well to be consistent with the reason for this change. -- nosy: +kevinbenton ___ Python tracker

[issue24651] Mock.assert* API is in user namespace

2015-07-21 Thread Felipe
Felipe added the comment: Not sure it's my place to comment here, but here are my 2 cents: I think Robert's proposal to have module functions is the only way to have a user-friendly and robust API, and it solves more than just the assert typo problem. (And yes, it would require moving the

[issue24651] Mock.assert* API is in user namespace

2015-07-21 Thread Patrick Westerhoff
Changes by Patrick Westerhoff patrickwesterh...@gmail.com: -- nosy: +poke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24651 ___ ___

[issue24651] Mock.assert* API is in user namespace

2015-07-21 Thread Antti Haapala
Changes by Antti Haapala an...@haapala.name: -- nosy: +ztane ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24651 ___ ___ Python-bugs-list mailing

[issue24651] Mock.assert* API is in user namespace

2015-07-21 Thread Ben Finney
Changes by Ben Finney ben+pyt...@benfinney.id.au: -- nosy: +bignose ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24651 ___ ___ Python-bugs-list

[issue24651] Mock.assert* API is in user namespace

2015-07-17 Thread Robert Collins
New submission from Robert Collins: We had a discussion on the list sparked by the assret checking, and in it I proposed that the API would be cleaner if the asserts were module functions. e.g. rather than:: a_mock.assert_called_with(Foo) assert_called_with(a_mock, Foo) Michael has

[issue24651] Mock.assert* API is in user namespace

2015-07-17 Thread Robert Collins
Changes by Robert Collins robe...@robertcollins.net: -- nosy: +berker.peksag, kushal.das, michael.foord ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24651 ___

[issue24651] Mock.assert* API is in user namespace

2015-07-17 Thread Brett Cannon
Changes by Brett Cannon br...@python.org: -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24651 ___ ___ Python-bugs-list