On Nov 5, 2019, at 21:48, Random832 wrote:
>
> As a side note, I have, occasionally, wanted to be able to resume a function
> after handling an exception (the use case was to turn a synchronous outer
> function calling an asynchronous callback into an asynchronous function),
> which -
On Tue, Nov 5, 2019, at 16:22, Greg Ewing wrote:
> Random832 wrote:
> > I have, occasionally, wanted to be able to resume a function
> > after handling an exception ... In a hypothetical
> > implementation that would allow such a thing, having the raise return a
> > value
> > in such a scenario
Random832 wrote:
I have, occasionally, wanted to be able to resume a function
after handling an exception ... In a hypothetical
implementation that would allow such a thing, having the raise return a value
in such a scenario might not be unreasonable.
For that to be of any use, the code that
On Sun, Nov 3, 2019, at 11:01, Andrew Barnert via Python-ideas wrote:
> > counter-argument: foo = raise NIY
>
> What is that a counter-argument to? The fact that it would nearly
> always be completely useless to assign a raise?
>
> I don’t know what NIY means here, but why couldn’t you write
On Nov 4, 2019, at 00:58, Soni L. wrote:
>
> That was meant to be NYI (Not Yet Implemented), sorry. (feel free to treat
> "NIY" as "Not Implemented Yet" :P)
Ah. I use NotImplementedError for that, because there are unit testing
frameworks that know how to count that differently from other
On 2019-11-03 2:01 p.m., Andrew Barnert wrote:
On Nov 3, 2019, at 15:38, Soni L. wrote:
>> > Or, C#'s throw is allowed in certain specific contexts (lambda bodies and conditional expressions) without being a general expression.
>> Just like, e.g., yield_expr is allowed in assignment
On Nov 3, 2019, at 15:38, Soni L. wrote:
>> > Or, C#'s throw is allowed in certain specific contexts (lambda bodies and
>> > conditional expressions) without being a general expression.
>> Just like, e.g., yield_expr is allowed in assignment statements without
>> being a general expression,
On 2019-11-03 12:24 p.m., Andrew Barnert via Python-ideas wrote:
On Nov 2, 2019, at 21:02, Random832 wrote:
>
>> On Sun, Oct 27, 2019, at 19:17, Andrew Barnert via Python-ideas wrote:
>>> On Oct 27, 2019, at 15:07, Ben Rudiak-Gould wrote:
>>>
>>> throw is an expression, not a statement,
On Nov 2, 2019, at 21:02, Random832 wrote:
>
>> On Sun, Oct 27, 2019, at 19:17, Andrew Barnert via Python-ideas wrote:
>>> On Oct 27, 2019, at 15:07, Ben Rudiak-Gould wrote:
>>>
>>> throw is an expression, not a statement, in C++. I see no reason raise
>>> couldn't be an expression in Python.
On Sun, Oct 27, 2019, at 19:17, Andrew Barnert via Python-ideas wrote:
> On Oct 27, 2019, at 15:07, Ben Rudiak-Gould wrote:
> >
> > throw is an expression, not a statement, in C++. I see no reason raise
> > couldn't be an expression in Python. It doesn't even need a special
> > rule in the
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
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
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
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.
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
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
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 Python 4, like
print_function was Python 3.
> def
On Oct 28, 2019, at 14:23, Serhiy Storchaka wrote:
>
> 28.10.19 20:38, Andrew Barnert via Python-ideas пише:
>> Many of them are abusing throw(StopIteration) to fake a “takewhile clause”
>> in comprehensions
>
> Well, so actually you needed the break expression. Or multistatement
>
28.10.19 20:38, Andrew Barnert via Python-ideas пише:
Many of them are abusing throw(StopIteration) to fake a “takewhile clause” in
comprehensions
Well, so actually you needed the break expression. Or multistatement
comprehension.
___
Python-ideas
On Oct 27, 2019, at 17:27, Chris Angelico wrote:
>
> and the fact that
> throw() isn't in everyone's toolkits already suggests that this really
> isn't a major problem to be solved.
Searching on “python raise expression”, the first hit is a StackOverflow
question where the asker is looking for
On Sun, Oct 27, 2019 at 6:58 AM Soni L. wrote:
> foo.setParseAction(lambda a, b, c: raise FuckPython(":(")) is invalid
> syntax, which makes pyparsing useless.
>
Insulting the project that you're trying to get help with is unnecessary to
get your point across.
Consider this a warning that such
On Sun, Oct 27, 2019 at 06:56:16PM -0300, Soni L. wrote:
> that's why I use nested functions.
I'm pretty sure that the memory and time overhead of using nested
functions is far greater than the saving in names.
I'm not even sure what it is that you think you are saving. Why do you
care if a
On Mon, Oct 28, 2019 at 11:17 AM Andrew Barnert wrote:
>
> On Oct 27, 2019, at 16:37, Chris Angelico wrote:
> >
> > But a raise expression doesn't really make sense in that way - it
> > can't possibly have any value. It would be possible to use a raise
> > expression in a lambda function or an
On Oct 27, 2019, at 16:37, Chris Angelico wrote:
>
> But a raise expression doesn't really make sense in that way - it
> can't possibly have any value. It would be possible to use a raise
> expression in a lambda function or an if/else expression, but other
> than that, there wouldn't be much to
On Mon, Oct 28, 2019 at 10:20 AM Andrew Barnert via Python-ideas
wrote:
>
> And meanwhile, if you want to change the language to turn raise into an
> expression, why not just turn it into an expression with the same syntax,
> just like with yield somewhere around 2.4? Then all existing code
On Oct 27, 2019, at 15:07, Ben Rudiak-Gould wrote:
>
> throw is an expression, not a statement, in C++. I see no reason raise
> couldn't be an expression in Python. It doesn't even need a special
> rule in the grammar:
>
>from __future__ import raise_function
>
>
throw is an expression, not a statement, in C++. I see no reason raise
couldn't be an expression in Python. It doesn't even need a special
rule in the grammar:
from __future__ import raise_function
foo.setParseAction(lambda a, b, c: raise(MumbleMumble()))
Looking up and calling the
On 2019-10-27 12:14 p.m., Eric V. Smith wrote:
On 10/27/2019 10:35 AM, Soni L. wrote:
that's a waste of a perfectly good name in the namespace.
Names are cheap. If "wasting" a name is a concern, then perhaps Python
isn't the language for you. It also lacks local scopes inside code
On 10/27/2019 10:35 AM, Soni L. wrote:
that's a waste of a perfectly good name in the namespace.
Names are cheap. If "wasting" a name is a concern, then perhaps Python
isn't the language for you. It also lacks local scopes inside code
blocks, for example, which also "waste" names, as
There's also the workaround:
def raise_(t, *a,*kw):
raise t(*a,**kw)
> On 27 Oct 2019, at 14:57, Soni L. wrote:
>
> foo.setParseAction(lambda a, b, c: raise FuckPython(":(")) is invalid
> syntax, which makes pyparsing useless.
> ___
>
On Sun, Oct 27, 2019, 10:38 AM Soni L. wrote:
> that's a waste of a perfectly good name in the namespace.
>
> On 2019-10-27 11:27 a.m., Anders Hovmöller wrote:
> > Just define a function. And don't be a dick.
> >
> > > On 27 Oct 2019, at 14:57, Soni L. wrote:
> > >
> > >
that's a waste of a perfectly good name in the namespace.
On 2019-10-27 11:27 a.m., Anders Hovmöller wrote:
Just define a function. And don't be a dick.
> On 27 Oct 2019, at 14:57, Soni L. wrote:
>
> foo.setParseAction(lambda a, b, c: raise FuckPython(":(")) is invalid syntax, which makes
Just define a function. And don't be a dick.
> On 27 Oct 2019, at 14:57, Soni L. wrote:
>
> foo.setParseAction(lambda a, b, c: raise FuckPython(":(")) is invalid
> syntax, which makes pyparsing useless.
> ___
> Python-ideas mailing list --
34 matches
Mail list logo
