Dear Python-dev
Nobody who cares is reading this thread any more - I'm guessing Guido silenced
it within the first 10 emails and so has almost everyone else. All you're doing
is exposing your own inabilities to understand the issue (there are not now,
have never been, and never will be, methods
On 07/20/2015 01:35 PM, Florian Bruhin wrote:
> >>>m.assert_me()
>Traceback (most recent call last):
> File "", line 1, in
> File
"/media/hda2/home/ra/Dev/python-dev/python3.5/cpython-master/Lib/unittest/mock.py",
>line 583, in __getattr__
> raise AttributeError(name)
>AttributeError
On Tue, Jul 14, 2015 at 6:22 PM, Robert Collins
wrote:
> For clarity, I think we should:
> - remove the assret check, it is I think spurious.
> - add a set of functions to the mock module that should be used in
> preference to Mock.assert*
> - mark the Mock.assert* functions as PendingDeprecati
On Monday, July 20, 2015, Emile van Sebille wrote:
> Your +infinity could have easily been top posted -- particularly when
> there's no in-line comments that require context.
>
> just-because-I'm-on-what-feels-like-a-300-baud-connection-ly yr's,
>
> Emile
>
>
> On 7/19/2015 2:16 PM, Mark Lawrence
Your +infinity could have easily been top posted -- particularly when
there's no in-line comments that require context.
just-because-I'm-on-what-feels-like-a-300-baud-connection-ly yr's,
Emile
On 7/19/2015 2:16 PM, Mark Lawrence wrote:
On 19/07/2015 22:06, Brett Cannon wrote:
There is a
* Ron Adam [2015-07-20 12:57:08 -0400]:
> >It's "unsafe" because tests which:
> >
> >1) are using the assert_* methods of a mock, and
> >2) where the programmer did a typo (assert_called() instead of
> >assert_called_with() for example)
> >
> >do silently pass.
>
> And further down, you say..
On 07/20/2015 03:32 AM, Florian Bruhin wrote:
* Ron Adam [2015-07-19 18:06:22 -0400]:
>
>
>On 07/19/2015 02:33 PM, Florian Bruhin wrote:
> >* Ron Adam [2015-07-19 11:17:10 -0400]:
> >>>I had to look at the source to figure out what this thread was really all
> >>>about.
>
>And it seems I
On 20 July 2015 at 13:34, Ben Finney wrote:
>> Again, I'm sorry to pick on one sentence out of context, but it cut
>> straight to my biggest fear when doing a commit (on any project) -
>> what if, after all the worrying and consideration I put into doing
>> this commit, people disagree with me (or
Paul Moore writes:
> Again, I'm sorry to pick on one sentence out of context, but it cut
> straight to my biggest fear when doing a commit (on any project) -
> what if, after all the worrying and consideration I put into doing
> this commit, people disagree with me (or worse still, I made a
> mis
On 20 July 2015 at 08:15, Stephen J. Turnbull wrote:
> Every one needs to be considered carefully,
It's very hard to pick out snippets like this out of context,
particularly in a thread that has already caused a lot of turmoil, but
I think this point is worth addressing. And my apologies in advan
On 20 July 2015 at 17:15, Stephen J. Turnbull wrote:
> ISTM that the missing rationale is that the real special case is mock
> itself. Michael referred to this context, but didn't make it
> explicit. Mock effectively "monkeypatches the world". In that
> context, the decision to protect against
* Ron Adam [2015-07-19 18:06:22 -0400]:
>
>
> On 07/19/2015 02:33 PM, Florian Bruhin wrote:
> >* Ron Adam [2015-07-19 11:17:10 -0400]:
> >>>I had to look at the source to figure out what this thread was really all
> >>>about.
>
> And it seems I don't quite get it still, but I am trying.
No wo
Terry Reedy writes:
> Good (or certainly much better): this blank>
I think so too, but IMO Nick and Antoine made a serious mistake by
deprecating this as a "minor design decision" without further
rationale. That's no excuse at all! The point of the Zen about
"special cases" is that these mino
13 matches
Mail list logo
