On 29/10/2019 22:47, Guido van Rossum wrote:
On Tue, Oct 29, 2019 at 3:37 PM Todd wrote:
I think you might be mixing up two different things.
First is the text of the Pytjon-2.0 license. I don't want to change that,
or the text of any other license.
Second is the LICENSE file. That file in
The point is not that the proposed behaviour is *necessarily* bad in
this scenario, but that it is a change in behaviour.
Guess it would be a long debate to find out the pros and cons of that.
Any variant might in some case be more or be less desireable. What holds
still anyways is that module na
On Oct 31, 2019, at 16:24, Steven D'Aprano wrote:
>
>> On Thu, Oct 31, 2019 at 02:47:35PM +0100, Andrew Barnert wrote:
>>> On Oct 31, 2019, at 13:56, Steven D'Aprano wrote:
>>>
>>> I disagree. I think it's a pretty small breaking change,
>>
>> From my test earlier on the thread, using a functi
On Thu, Oct 31, 2019 at 02:47:35PM +0100, Andrew Barnert wrote:
> On Oct 31, 2019, at 13:56, Steven D'Aprano wrote:
> >
> > I disagree. I think it's a pretty small breaking change,
>
> From my test earlier on the thread, using a function to raise makes a
> function that does nothing but raise a
On Fri, Nov 1, 2019 at 12:52 AM Andrew Barnert via Python-ideas
wrote:
> Also, there are many places in the Python data model where you have to raise
> an exception, such as StopIteration; there are no places where you need to
> print. And if you need output and print is too slow, you can always
On Oct 31, 2019, at 13:56, Steven D'Aprano wrote:
>
> I disagree. I think it's a pretty small breaking change,
From my test earlier on the thread, using a function to raise makes a function
that does nothing but raise and handle an exception take more than twice as
long. Which implies that the
On Wed, Oct 30, 2019 at 11:29:55PM -0700, Ben Rudiak-Gould wrote:
> On Sun, Oct 27, 2019 at 4:17 PM Andrew Barnert wrote:
> > On Oct 27, 2019, at 15:07, Ben Rudiak-Gould wrote:
> > >from __future__ import raise_function
> > That’s a pretty big breaking change.
>
> I agree, it's a bad idea. I
Ok, just after I posted this I checked if side_effect would take an
exception as value and handle raising it itself and it does, which sort of
invalidates that specific use case, but at the same time we just deported
that feature into python code of mock.
___
I think setting a patch mock's side_effect to raise an exception is a valid
use case.
In this example, we're simulating a blockchain error in an API that we're
coding, and testing that instead of a 500 Internal Server Error, our API
returns a 400 with a nice error message:
with mock.patch('yourap
On Oct 31, 2019, at 07:29, Ben Rudiak-Gould wrote:
>
>> On Sun, Oct 27, 2019 at 4:17 PM Andrew Barnert wrote:
>>> On Oct 27, 2019, at 15:07, Ben Rudiak-Gould wrote:
>>> from __future__ import raise_function
>> That’s a pretty big breaking change.
>
> I agree, it's a bad idea. It'd have to be
10 matches
Mail list logo
