Re: [Python-Dev] How far to go with user-friendliness
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 minor design decisions are indeed a slippery slope -- they may be minor individually, but collectively they lead to real ugliness. Every one needs to be considered carefully, and this particular one plays no role in the basic design of mock -- it's hard to see sufficient "practicality" without context. Arguing that "special cases aren't" is not like complaining about the "color of the bikeshed", it's like finding a termite climbing up the wall and calling for the exterminator. 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 certain errors whose risk is greatly increased by mock itself arguably is a *minor* design decision, and none of the defenders of leaving this feature in 3.5 would consider it a precedent for admitting similar "special cases" elsewhere in the stdlib. (Last minute note: I believe this analysis is confirmed by Florian Bruhin's post, which I don't fully understand.) I'm not sure I accept that myself, but it does convince me that the feature's defenders continue to firmly believe that special cases aren't special enough, and that is good enough reason to end the thread. Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
* 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 worries - I'll try to clarify until things are clear :) > >>>Basically it looks to me the purpose of adding "assret" is to add an "alias > >>>check" for "unsafe" methods. It doesn't actually add an "alias". It > >>>allows > >>>a developer to use a valid alias to avoid conflicting with methods starting > >>>with assert that will still work with the mock module. > >>> > >>>The mock module says that when "unsafe" flag is set to True, it will not > >>>raise AssertionError for methods beginning with "assert" and "assret". It > >>>doesn't specify what "unsafe" means, and why you would want to do that. > >>> > >>>So first do this... > >>> > >>> * Document "unsafe" in mock module. > > I still think documenting the purpose of "unsafe", rather than just the > effect it has is important. > > From the confusion in this thread, (including my own), it's clear the > documentation does need some attention. > > > There are only two places where it mentions "unsafe" in the docs... > > The class signature... > > """ > class unittest.mock.Mock(spec=None, side_effect=None, return_value=DEFAULT, > wraps=None, name=None, spec_set=None, unsafe=False, **kwargs) > """ > > > And in the section below that. > > """ > unsafe: By default if any attribute starts with assert or assret will raise > an AttributeError. Passing unsafe=True will allow access to these > attributes. > """ > > But that doesn't explain the purpose or why these are unsafe or why it > should throw an AttributeError. Or what to do with that AttributeError. 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. > >But if you do a typo, the test silently doesn't fail (because it's returning > >a > >new mock instead of checking if it has been called): > > Do you mean silently passes? Yes - it passes without checking the thing the test was intended to check. > > > >>> m.assert_called() > > > > > >With the patch, everything starting with "assert" or "assret" (e.g. my > >example above) raises an AttributeError so these kind of issues can't > >happen. > > I get that part. It's checking for a naming convention for some purpose. > > What purpose? > >"To raise an AttributeError" ... but why? So you notice you have done a typo and your test will not actually verify what you want it to verify. Compare it with the behavior of a normal object - if you call a method which doesn't exist, it raises AttributeError. This isn't possible with Mock objects, as they are designed to support *any* call, and you can check the calls have happened after the fact. With the patch, if you call any method starting with "assert" which does not exist (assert_caled_with, assert_foobar, assert_called, etc.) this is assumed to be a mistake and you get an AttributeError so you notice there was a mistake. If you pass unsafe=True, you can still call mock.assert_foo() methods as usual and they will return a new Mock, just as calling, say, mock.spam() would. > >The thing people are discussing about is whether this should also > >happen if you do "m.assret_called_with()" (i.e. if this is a common > >enough typo to warrant a special exception), or if*only* things > >starting with assert_* are checked. > > > >The merged patch also treats "assret_*" as a typo, and some people > >think this is a wart/unnecessary/harmful and only "assert_*" should > >raise an AttributionError, i.e. the patch should be amended/reverted. > > I think it would be easy enough to revert, It' just a few line in the source > and docs. No big deal there. > > It's not clear why getting an AttributeError for methods beginning with > assert is needed, and how that exception is to be used. (Should it Bubble > up, or should it be caught and handled?) Note the discussion *isn't* about the fact that assert-methods should raise AttributeError! The patch also does the same with "assret". At least if I understand things correctly, the discussion is whether *only* "assert*" should be handled as a typo, or "assret*" too. The exception should bubble up, as the whole point of it is to tell you you did a typo and your test is broken. Florian -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgpMO8rT2PffT.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/m
Re: [Python-Dev] How far to go with user-friendliness
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 certain errors whose risk is > greatly increased by mock itself arguably is a *minor* design > decision, and none of the defenders of leaving this feature in 3.5 > would consider it a precedent for admitting similar "special cases" > elsewhere in the stdlib. Yes, Mock (especially AutoMock) is *already* quite magical from the perspective of most Pythonistas, as it relies heavily on Python's runtime introspection features to emulate other objects based on live introspection of the relevant type objects. It is however a very *practical* piece of code, as it lets you readily mock out a remote service for testing purposes, while later using those same tests against a *real* instance of the target class as functional integration tests, even if you couldn't write such API emulation code yourself. The need for the "typo detection" is then a consequence of two different kinds of methods existing in the same namespace (those from Mock itself, and those from the object being emulated), leading to a particular category of bug in normal usage of this API. Robert Collins suggested a possible migration path to better structural separation of the two kinds of Mock method, but the existing merged API is one a lot of folks actually like. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
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 advance if I don't word my point well enough and cause offence. None is intended. As a new core dev, although one who has been on this list for many years, I can attest to Nick's point that threads like this are a huge barrier to new contributors - I personally am pretty reluctant to commit changes on my own judgement, purely because of the risk that "I might be wrong" (i.e. I might be called to justify my decision in a thread like this). The problem with pointing out that decisions need to be considered carefully is that there is an implication that either the original core dev *didn't* consider the issue carefully. But I doubt that's the case. Extra review may help, certainly, but a thread like this quite frankly doesn't really feel like "extra review". 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 mistake)? Will I be able to justify what I decided? Hmm, maybe I'd better hold off and let someone else make the decision... Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
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 > mistake)? Will I be able to justify what I decided? That seems quite healthy to me. On a collaborative project with effects far beyond oneself, yes, any change *should* be able to be justified when challenged. That isn't a mandate to challenge every change, of course. It does mean that every change should be considered in light of “Can I justify this, if challenged?” So what you describe sounds like a healthy barrier: one which works to keep out unjustifiable changes. What is needed is to have both that *and* the support of the community so it's not a barrier to the *contributors*. The contributors should not feel excluded merely because some of their changes might need to be. > Hmm, maybe I'd better hold off and let someone else make the > decision... What of the (obvious, to me) option to retain the authority to make the decision, but take the doubt as a sign that one should consult with others before making the decision? That is, there's no need to feel that one shouldn't make the decision. But perhaps one shouldn't make it solely on one's own experience or insight. Get others involved, even non-committers, and discuss it, and understand the issue better. With that improved basis, then make the decision. Am I naive to think that's desirable for PYthon core committers? -- \ “Ours is a world where people don't know what they want and are | `\ willing to go through hell to get it.” —Donald Robert Perry | _o__) Marquis | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
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 worse still, I made a >> mistake)? Will I be able to justify what I decided? Let me rephrase. What I was trying to say was that justifying the change *to the level needed for the sort of debate we see here* is too high a barrier. Michael is the original developer of mock, is the primary maintainer of it, and apparently had a specific example of the assret misspelling causing problems. And yet the debate still goes on. At what point does that debate stop being a request to justify a change, and turn into unreasonable browbeating over a decision that others don't like? Even the constructive suggestions of an alternative, less fragile API, were responded to (with "it doesn't match the design principles of mock"). And yet there's a tone of "why didn't you think of this approach" in the thread (and my immediate thought to that is why is "because I'm not perfect" not an acceptable response - and so obvious as to not need stating?) Again, I'm not saying that people shouldn't be aware of the responsibility of being a core dev, and wield the authority carefully. But at some point the mailing list commentary stops being a useful check and turns into a demotivating and paralysing force. It's hard to keep that balance correct, but I think that presently there's a shift towards the negative side, which we should recognise and address. > That seems quite healthy to me. On a collaborative project with effects > far beyond oneself, yes, any change *should* be able to be justified > when challenged. Fair. But equally, on a project supported on a volunteer basis by a relatively small group with severe time pressure problems, any challenge should be able to be justified as worth the drain on resource and energy. A quick "is the special-casing of one possible mis-spelling worth it?" question on the tracker is one thing. A week-long, 100-message mailing list thread is another. Somewhere in the middle (but a lot closer to the former) is probably ideal. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
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 don't quite get it still, but I am trying.
No worries - I'll try to clarify until things are clear :)
Thanks, :-)
> >>>Basically it looks to me the purpose of adding "assret" is to add an "alias
> >>>check" for "unsafe" methods. It doesn't actually add an "alias". It
allows
> >>>a developer to use a valid alias to avoid conflicting with methods starting
> >>>with assert that will still work with the mock module.
> >>>
> >>>The mock module says that when "unsafe" flag is set to True, it will not
> >>>raise AssertionError for methods beginning with "assert" and "assret". It
> >>>doesn't specify what "unsafe" means, and why you would want to do that.
> >>>
> >>>So first do this...
> >>>
> >>> * Document "unsafe" in mock module.
>
>I still think documenting the purpose of "unsafe", rather than just the
>effect it has is important.
>
> From the confusion in this thread, (including my own), it's clear the
>documentation does need some attention.
>
>
>There are only two places where it mentions "unsafe" in the docs...
>
>The class signature...
>
>"""
>class unittest.mock.Mock(spec=None, side_effect=None, return_value=DEFAULT,
>wraps=None, name=None, spec_set=None, unsafe=False, **kwargs)
>"""
>
>
>And in the section below that.
>
>"""
>unsafe: By default if any attribute starts with assert or assret will raise
>an AttributeError. Passing unsafe=True will allow access to these
>attributes.
>"""
>
>But that doesn't explain the purpose or why these are unsafe or why it
>should throw an AttributeError. Or what to do with that AttributeError.
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...
Compare it with the behavior of a normal object - if you call a method
which doesn't exist, it raises AttributeError.
This isn't possible with Mock objects, as they are designed to support
*any* call, and you can check the calls have happened after the fact.
And the docs say...
"""
spec: This can be either a list of strings or an existing object (a class
or instance) that acts as the specification for the mock object. If you
pass in an object then a list of strings is formed by calling dir on the
object (excluding unsupported magic attributes and methods). Accessing any
attribute not in this list will raise an AttributeError.
"""
So calling a method that doesn't exist on a mocked object will raise an
AttributeError if it is given a spec.
But if you don't give it a spec, then a mispelling of *any* method will
pass silently. So it's not a problem limited to "assert" methods.
It seems the obvious and best solution is to always use a spec.
>It's not clear why getting an AttributeError for methods beginning with
>assert is needed, and how that exception is to be used. (Should it Bubble
>up, or should it be caught and handled?)
Note the discussion*isn't* about the fact that assert-methods should
raise AttributeError! The patch also does the same with "assret".
At least if I understand things correctly, the discussion is whether
*only* "assert*" should be handled as a typo, or "assret*" too.
Both of these are new in 3.5. And they are related to each other. So yes,
they do need to be looked at together in order to understand the problem
being discussed.
The exception should bubble up, as the whole point of it is to tell
you you did a typo and your test is broken.
I think this is too simple of an explanation. That could be true for any
method or attribute call.
>>> m = Mock(spec=["assert_me", "call_me"])
>>> m.call_me()
>>> m.all_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 578, in __getattr__
raise AttributeError("Mock object has no attribute %r" % name)
AttributeError: Mock object has no attribute 'all_me'
It does raise AttributeError's on missing methods if a spec is given. So
catching mispelled methods in tests is only a problem if you don't use a
spec. (And not limited to assert methods)
>>> 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: assert_me
Why is AttributeError raised here? Why are methods beginning with assert
special? (or "unsafe")
Cheers,
Ron
___
Python-Dev mailing list
Python-Dev@python.org
Re: [Python-Dev] How far to go with user-friendliness
* 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... > > >Compare it with the behavior of a normal object - if you call a method > >which doesn't exist, it raises AttributeError. > > > >This isn't possible with Mock objects, as they are designed to support > >*any* call, and you can check the calls have happened after the fact. > > > And the docs say... > > """ > spec: This can be either a list of strings or an existing object (a class or > instance) that acts as the specification for the mock object. If you pass in > an object then a list of strings is formed by calling dir on the object > (excluding unsupported magic attributes and methods). Accessing any > attribute not in this list will raise an AttributeError. > """ > > So calling a method that doesn't exist on a mocked object will raise an > AttributeError if it is given a spec. > > But if you don't give it a spec, then a mispelling of *any* method will pass > silently. So it's not a problem limited to "assert" methods. > > It seems the obvious and best solution is to always use a spec. I agree - I always use mocks with autospec/spec, and I recommend doing that - I actually plan to write a plugin for pylint to enforce this. Still mistyping the assert methods seems to be a common issue, since (according to some other mail) a couple of bugs in OpenStack were found this way. But yeah - if your code under test has a typo, and you don't use spec/autospec, you might not notice as well - though in my experience you *usually* do, since the returned mock object doesn't behave in the way you expect it to. But yeah - always using (auto)spec is probably the best solution. > >>> 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: assert_me > > > Why is AttributeError raised here? Why are methods beginning with assert > special? (or "unsafe") Some things I can think of: - It's more likely that you use assert_called() instead of assert_called_with() accidentally than that you do a typo in your code under test. - If you do a typo in your code under test, a linter is more likely to find it than with mocks, because of their nature. - Other tests (even if they're manual ones) should probably discover the typo in your real code. The always-passing assert won't. Florian -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgpxz4InJiQIK.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] A quick word on top posting
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 absolutely no reason we can't keep discussions cordial, friendly, and on-point on this list and prevent this sort of debacle from occurring again. +infinity ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A quick word on top posting
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 wrote: > >> On 19/07/2015 22:06, Brett Cannon wrote: >> > > > > There is absolutely no reason we can't keep discussions cordial, >>> friendly, and on-point on this list and prevent this sort of debacle >>> from occurring again. >>> >>> >> +infinity >> > Empty replies like a fake vote should just not occur in general. That's not usually an issue on this list, but I see many others plagued by such responses and hope we never end up on that path (especially people +1'ing a +1...). Remember that not only do we need to keep emails to the characteristics Brett mentioned for the sake of having a healthy discussion list, we should strive to keep the noise as close to zero as possible as mails sent to this list reach *a lot* of people. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
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 PendingDeprecation > - in 3.6 move the PendingDeprecation to Deprecated > - in 3.7 remove the Mock.assert* functions and the check for method > names beginning with assert entirely. Hi all, I'm just an onlooker, and haven't read every word of this thread. In fact I worry that it's pointless to reply to rather than starting a new thread. I just wanted to make sure that the specific message I'm replying too wasn't lost in the noise because I think Robert's suggestion makes vastly more sense than anything else I've seen here (I came searching through the thread to see if anyone else suggested this before I started a thread to do so). 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 standpoint in the first place. Typically asserting something in a test is not something an object *does*--a method. More often we as a test writers assert something *about* an object. The assertion is an external tool meant to measure and introspect things about the system under observation. In this case, although Mock is itself a testing tool, we're introspecting something about the Mock object as external observers. ***Assertions on Mock objects should be implemented as stand-alone functions (that happen to be used primarily on Mock objects as input).*** Aside from, in my mind, making more sense philosophically, using specialized assert functions for this has absolutely none of the spelling ambiguities or other problems of the magic methods. I'm -0 on removing the assret_ methods unless no one is using them yet. I don't care if they're there as long as they're deprecated along with the other magic methods of Mock. Best, Erik ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
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: assert_me > > >Why is AttributeError raised here? Why are methods beginning with assert >special? (or "unsafe") Some things I can think of: - It's more likely that you use assert_called() instead of assert_called_with() accidentally than that you do a typo in your code under test. - If you do a typo in your code under test, a linter is more likely to find it than with mocks, because of their nature. - Other tests (even if they're manual ones) should probably discover the typo in your real code. The always-passing assert won't. But it doesn't always pass in the above. It would fail if there is a typo. You would need to make the same typo in the test and the mock the test uses. With this, the only way to use methods beginning with assert is to set unsafe=True. Then none of this applies. And after a few times, it's likely a developer will get into the habit of doing that. I wonder if it's going to do what the intent was? Another reason mentioned by Nick, is to avoid shadowing mocks own methods. But I would think a different exception could be used with an explicit error message regarding the exact reason would be better, by actually detecting the attribute shadows specific mock methods when the mock object is created rather than raising an AttributeError when it's called. I'm thinking that would have been enough to find most of the errors including the use of "assret*" in the motivating case. Which would of been a matter of just correcting the spelling. "assret*" would have raised an Attribute error if it was spelled that way in the test, or "assert*" would have raised an Attribute error if it was spelled "assret*" in the object used in the test. Do these seem accurate to you? The problems seem to only occur be when no spec is given. Blocking use of "assert*" when a spec is given is more than needed, but detecting shadowing of needed mock methods is needed. That can be done sooner with better a better error message I think. Using "assret*" in the objects being tested will never shadow a mock method. So it seems it's a case of catching a mispelling in a test calling a non-existing method. (But anyother spelling would not be caught.) I think I'm starting to get it now, Ron ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
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 starting with 'assret'!) and upsetting active, potential and former ( :( ) contributors. Just stop replying. *Especially* if you don't understand the issue and/or are not offering to fix it yourself (and if you do/are, take it to the tracker). Thanks, Python-dev ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
