Michael Foord added the comment:
I like assertPermutation (with or without the Is, slight preference for
without).
--
___
Python tracker
<https://bugs.python.org/issue27
Michael Foord added the comment:
I'm particularly concerned that we have call_count "sane" for AsyncMock and
avoid adding "await_count" if possible. I think we've decided on that.
I'm more agnostic on the assert_await* methods. I agree they're a nice API. I
don't mind
Michael Foord added the comment:
The previous behaviour was unspecified and clearly due to missing
functionality, so the advantages of fixing it outweigh any potential
compatibility issues. But I'd see it as a feature enhancement for 3.9
Michael Foord added the comment:
As discussed with Karthik, I think this is a nice feature enhancement for the
wraps functionality and worth fixing. It has the great advantage that the fix
is nice and isolated and simple.
--
___
Python tracker
Michael Foord added the comment:
(The code that generated functions was originally borrowed from the decorator
module by Michele Simionato. When I first started in Python, around 2002, I was
impressed by the Python community as it had two very prominent women amongst
the part
Michael Foord added the comment:
The code around whether or not to swallow self is hairy. Even if the original
spec object is a class we may still be mocking an instance of the class (we
don't want users to have to create an instance just to be able to use it as a
spec). So we have to carry
Michael Foord added the comment:
That may change though, right?
In general I dislike the proliferation of keyword arguments if it's at all
possible to avoid. I added way too many of them originally and the mock API is
really big.
--
___
Python
Michael Foord added the comment:
This will affect spec and spec_set.
--
___
Python tracker
<https://bugs.python.org/issue30587>
___
___
Python-bugs-list mailin
Michael Foord added the comment:
I'd like spec to have signature validation. I don't think the use case for
"attribute validation only" (current spec behaviour) is very strong and I'd
rather not add new keywords. The mock API is already too complex.
I'll take the existing PR
Change by Michael Foord :
--
assignee: -> michael.foord
components: +Extension Modules -Library (Lib), Tests
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python
Michael Foord added the comment:
I'm in favour of a default and "Unconditionally skipped" is fine with me.
Although "Skipped" would also be fine.
Making @skip work with no arguments is fine. Having to pass in arguments
message arguments you don't want is a pain and ther
Michael Foord added the comment:
"I don't know why run() returns None for skipIf cases instead of returning a
TestResult with non-empty skipped, as it does for skipTest, or if the None is a
separate bug."
That does sound
Change by Michael Foord :
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue37668>
___
___
Michael Foord added the comment:
Can you suggest an API for doing this?
--
___
Python tracker
<https://bugs.python.org/issue37669>
___
___
Python-bugs-list m
Michael Foord added the comment:
Or even making the assert methods into custom descriptors.
--
___
Python tracker
<https://bugs.python.org/issue19645>
___
___
Michael Foord added the comment:
Hmm, it could be done by __init_subclass__ potentially.
--
___
Python tracker
<https://bugs.python.org/issue19645>
___
___
Pytho
Michael Foord added the comment:
Suppose failureException is set to TypeError on that TestCase class, how would
your assertEquals signal failure to the test runner?
--
___
Python tracker
<https://bugs.python.org/issue19
Michael Foord added the comment:
Has anyone seen any real world use cases for failureException? It's a real
hindrance to a whole bunch of changes sounds decoupling.
On the other hand something like assertThat could catch a custom exception from
the matchers (subclass of AssertionError
Michael Foord added the comment:
Spec objects are currently dumb. It would be a new feature to add signature
validation to them.
I think it would be a useful feature though as currently autospec sort of
obsoletes spec objects whilst being more heavyweight and harder to use.
I think
Michael Foord added the comment:
Tests codify knowledge about the system under test, so it doesn't matter that
the test suite has to know how to clear caches. It's specifically a good thing
that the test writer knows which caches exist and need clearing, and how to do
it. The harder thing
Michael Foord added the comment:
> On 30 Mar 2019, at 23:48, Michael Foord wrote:
>
>
> Michael Foord added the comment:
>
> An auto-magic cache clearing mechanism is really tempting. I tend to agree
> with Raymond though, if code needs and progress a cac
Michael Foord added the comment:
An auto-magic cache clearing mechanism is really tempting. I tend to agree with
Raymond though, if code needs and progress a cache clearing mechanism it should
be treated and accessible.
They're are probably some problematic caches still within unittest
Michael Foord added the comment:
It's almost certainly an oversight rather than a design decision. I'd be happy
with the change you suggest Karthikeyan.
--
___
Python tracker
<https://bugs.python.org/issue36
Michael Foord added the comment:
Parents comparing upwards sounds like the right (and simple) fix. Not breaking
the tuple tests would be good. I'm happy for Chris to produce the patch.
--
___
Python tracker
<https://bugs.python.org/issue35
Michael Foord added the comment:
This isn't a bug. This is the intended behaviour, otherwise MagicMock objects
would error out on iteration.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracke
Change by Michael Foord :
--
resolution: -> rejected
___
Python tracker
<https://bugs.python.org/issue14266>
___
___
Python-bugs-list mailing list
Unsubscrib
Michael Foord <mich...@voidspace.org.uk> added the comment:
This seems like a reasonable feature request.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Michael Foord <mich...@voidspace.org.uk> added the comment:
There are several disadvantages to doing deepcopy:
* identity checks now fail
* deep copying is slow
* deep copying doesn't work on arbitrary objects
So deep copying by default isn't a good idea. This particular case is men
Michael Foord added the comment:
Generally the called with asserts can only be used to match the *actual call*,
and they don't determine "equivalence".
To do it cleanly would be tricky, and adding complex code is a maintenance
burden. I'm not convinced there's a massive use case -
Michael Foord added the comment:
Note that you can use an object as the parameter to the spec argument rather
than just a list of attributes.
Hmmm... I'm not totally opposed to the addition of a "seal_mock" method
(optionally with a recurse boolean for child mocks) being added to
Michael Foord added the comment:
I don't see what this buys over spec and autospec. I'd be inclined to close it
without a compelling use case beyond what is already supported.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Michael Foord added the comment:
I agree it's not *very* useful, but I don't see any benefit in getting rid of
it either.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Michael Foord added the comment:
I like the documentation improvement, thank you.
(The purpose of the method is to combine an assert about the arguments the
method was called with and an assertion that it was only called once. To change
the semantics would be both undesirable and backwards
Michael Foord added the comment:
Yep, looks like an improvement to me!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29274>
___
__
Michael Foord added the comment:
LGTM Serhiy - thank you for your work. Appreciated.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Michael Foord added the comment:
It's a new feature.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20804>
___
___
Python-bugs-
Michael Foord added the comment:
I think option 3 is the correct semantic behaviour for sentinels, and if there
are already examples of this in the standard library then it *doesn't* violate
expected behaviour of pickling and copying (sentinel and singleton objects can
be permitted to retain
Michael Foord added the comment:
So my thinking has evolved slightly on it. If it's *possible* for sentinels to
be copied and pickled and preserve identity then I'm happy for it. I think the
right semantics for copying a sentinel is that you get the original object
back. If you pickle
Michael Foord added the comment:
Yep, LGTM as well. Nicely spotted!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28961>
___
___
Michael Foord added the comment:
Yep, looks good to me to.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28919>
___
___
Pyth
Michael Foord added the comment:
open shouldn't always be patched in builtins, it's much better to patch it in
the specific namespace it's being called from. So the doc patch here shouldn't
be applied as is.
--
___
Python tracker <
Michael Foord added the comment:
Oh, I see what you mean - an attribute that doesn't exist on the original. With
autospec that should throw an exception (AttributeError) I think, yes.
--
___
Python tracker <rep...@bugs.python.org>
Michael Foord added the comment:
It should be perfectly valid to use attach_mock with an attribute that doesn't
already exist. Part of it's purpose is to create new attributes.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Michael Foord added the comment:
Sure, go ahead Syed. Feel free to ask any questions you may have.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Michael Foord added the comment:
attach_mock should use function.mock when it is passed a function created by
autospec. It should also *probably* fail if given a non-mock object (although
that would prevent people duck-typing and attaching a mock-like object so I'm
open to discussion
Michael Foord added the comment:
I like the idea and would be happy for it to be added to mock.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Michael Foord added the comment:
This is a deliberate design decision of mock. Storing references works better
for the more general case, with the trade-off being that it doesn't work so
well for mutable arguments.
See the note in the docs with a workaround:
https://docs.python.org/3/library
Michael Foord added the comment:
Before you spend any more time on this, my current thinking is that this is a
bit too specialised to belong in the standard library. I'll wait and see if a
preponderance of core devs and other users disagree with me before I close this
though
Michael Foord added the comment:
It's not a use case I've specifically had but I can see its use. I'm uncertain
of whether that means it belongs in the module or not. Let me see if I can get
some more eyes on this bug.
--
___
Python tracker <
Michael Foord added the comment:
Is this for mocking out runtime dependencies that aren't available at test
time? It seems like a good way of masking bugs! I'd be happier with a (or at
least an option) to specify the imports that should be mocked. The use case
should be mentioned in the docs
Changes by Michael Foord <mich...@voidspace.org.uk>:
--
assignee: -> michael.foord
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Michael Foord added the comment:
I agree with David, I don't like the name but it is at least accurate (if you
already understand what it does). assertItemsEqual was better but misleading.
In the absence of a *dramatically* better name leave it alone
Michael Foord added the comment:
Yes, this can go in.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26323>
___
___
Python-bugs-
Michael Foord added the comment:
There have been persistent calls for an "assert_called" method over the
lifetime of mock. In the past I've rejected them because you can easily get it
by asserting the call count is non-zero and I want to avoid the proliferation
of a thousand asse
Michael Foord added the comment:
TestProgram is an abomination, but it has been publicly exposed in unittest
since forever.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Michael Foord added the comment:
create_autospec and Mock(spec=spec) are very different. Mock(spec=spec) creates
a mock object with the same *attributes* as the original. It does not create
functions like create_autospec can.
--
resolution: -> not a bug
stage: -> resolved
Changes by Michael Foord <mich...@voidspace.org.uk>:
--
nosy: -gvanrossum
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26140>
___
Michael Foord added the comment:
To find and run tests recursively from a test package you want test discovery
rather than (necessarily) load_tests.
For a bug report, please describe the behaviour you expect and the behaviour
you're seeing instead
Michael Foord added the comment:
In inspect checking that __code__ is a code object, or that co_flags is an int,
would be better than special casing mock.
However, the patch to mock looks reasonable to me. It copies the whole code
object from the original function to the mock object
Michael Foord added the comment:
Suggested behaviour sounds good, patch looks sensible. Is it possible to add a
test too?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Michael Foord added the comment:
Sean's patch looks good to me.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22138>
___
___
Michael Foord added the comment:
assertEqual *does* do type checking and it's strict that it will only resort to
the "type specific" assert checks if both types are of the same type. In the
general case it's impossible to know whether comparing a subclass with the type
spec
Michael Foord added the comment:
I'm happy to blacklist __wrapped__ in call. I don't see how call can detect
that kind of introspection in the general case though. Limiting call depth
would be one option, but any limit is going to be arbitrary and I don't "like"
that as
Michael Foord added the comment:
Patch looks good to me.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24928>
___
___
Pyth
Michael Foord added the comment:
Have you read the docs for call? :-)
call.foo("foo") generates a call object representing a method call to the
method foo. So you can do.
m = Mock()
m.foo("foo")
self.assertEqual(m.mock_calls, call.foo("foo"))
(etc
Michael Foord added the comment:
Preventing the use of "__" attributes would limit the usefulness of call with
MagicMock and the use of magic methods. That might be an acceptable trade-off,
but would break existing tests for people. (i.e. it's a backwards incompatib
Michael Foord added the comment:
For mock I think your proposed fix is fine. call is particularly magic as
merely importing it into modules can cause introspection problems like this
(venusian is a third party library that has a similar issue), so working around
these problems as they arise
Michael Foord added the comment:
This is actually the specified and documented behaviour of mock when it is
passed mutable arguments. Deep copying arguments on calls is rife with
potential problems (not everything can be copied and it breaks comparison by
identity). The documentation suggests
Michael Foord added the comment:
Using the runner as a "context" passed to test cases (and accessible from
tests) for this kind of configuration seems like a good approach to me.
--
___
Python tracker <rep...@bugs.python.org>
<htt
Changes by Michael Foord <mich...@voidspace.org.uk>:
--
nosy: -michael.foord
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pytho
Michael Foord added the comment:
assertLogs is on a Python test suite helper, not TestCase itself.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24193
Michael Foord added the comment:
call_args is not user settable! It is set for you by the mock when it is
called. Arguably it could be a property instead.
--
resolution: - not a bug
status: open - closed
___
Python tracker rep...@bugs.python.org
Michael Foord added the comment:
Oops, I misunderstood the bug report - however, call_args is a tuple, so you
can't compare it directly to a string like that. Please refer to the docs on
using call_args.
--
___
Python tracker rep...@bugs.python.org
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
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
Michael Foord added the comment:
So the problem with the testing-cabal issue 280 is *really* a problem with
decorators - the decorator is applied at method creation time and mock_open is
only called once rather than once *per call*.
Better would be to use mock.patch as a context manager
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
Michael Foord added the comment:
-1
The whole thread is absurd. I'm travelling for europython and only have
internet access on my phone until tomorrow at the earliest.
On Saturday, 18 July 2015, Berker Peksag rep...@bugs.python.org wrote:
Changes by Berker Peksag berker.pek...@gmail.com
Michael Foord added the comment:
The change to unittest is fine. I'd prefer the tests tweaking as Ezio suggested.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15836
Michael Foord added the comment:
I like the first variant suggested by Ezio as more concise. I'll try and look
at the substance of the patch today.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15836
Michael Foord added the comment:
What is the advantage to deleting the Wing IDE project files, other than making
it harder to use Wing to work on Python?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23469
Michael Foord added the comment:
Patch looks good, thanks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20487
___
___
Python-bugs-list mailing
Michael Foord added the comment:
Using patch.dict manipulates the contents of sys.modules, it doesn't replace
sys.modules.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21600
Michael Foord added the comment:
why not?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21600
___
___
Python-bugs-list mailing list
Unsubscribe
Michael Foord added the comment:
Patch looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22823
___
___
Python-bugs-list mailing
Michael Foord added the comment:
Looks good, thanks for the quick response.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22894
___
___
Python
Changes by Michael Foord mich...@voidspace.org.uk:
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22894
___
___
Python-bugs-list
Changes by Michael Foord mich...@voidspace.org.uk:
--
nosy: -michael.foord
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22827
___
___
Python
Michael Foord added the comment:
One way would be to have an _main.py and have main.py import * (or
equivalent) from it. We can't get rid of unittest.main being an alias for
TestProgram - that's been around forever.
--
___
Python tracker rep
Michael Foord added the comment:
TestProgram is an abomination.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22860
___
___
Python-bugs-list
Michael Foord added the comment:
The point is that it is easy to have unintentional dependencies between tests.
Test a sets up some state that test b relies on. This means that test b passes,
so long as test a has already run. This is bad, tests should be isolated - it
also means you can
Michael Foord added the comment:
mock in the Python standard library is licensed under the PSF license.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22827
Michael Foord added the comment:
I agree with Robert that the text output of the default runner should not be
considered a part of the api that we make backwards compatible guarantees
about. People who want to customise that should be customising the text
runner/result. (Unfortunately
Michael Foord added the comment:
Allowing sys.exit() to end the test run was particularly a problem for testing
command line tools, where improper patching / unexpected code paths would
trigger a sys.exit.
If a test framework author wants a way to end the test run I'm happy to provide
Michael Foord added the comment:
I agree.
--
title: unittest discovery is fragile - Blacklist FunctionTestCase from test
discovery
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22680
Michael Foord added the comment:
With one minor doc change (break up the really long sentence), this looks good
to go to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22457
Michael Foord added the comment:
Ah. Test discovery is discovering FunctionTestCase and attempting to
instantiate it as a test. And failing.
Maybe discovery should special case that class and not treat it as a normal
TestCase.
--
___
Python
Michael Foord added the comment:
Assertions are not uncommon in setUp. setUp is for setting up common state
shared between tests and I regularly want to assert that state creation /
preconditions are correct.
I've never been bitten by this issue (I rarely use expectedFailure), but it's
Michael Foord added the comment:
Maybe if the expectedFailure is applied to the whole class and it's the setUp
that is unable to work. I've never seen it used that way of course (mostly
because it doesn't work that way) - but I *can* imagine
Michael Foord added the comment:
I assume you mean you get the error *with* 3.5 (not without). Does this
happen *every time* (i.e. is it trivially reproducible) - or can you provide a
repro?
This is regression that I would *assume* (a totally lazy assumption) introduced
by the new error
1 - 100 of 1074 matches
Mail list logo
