clever exit of nested loops
Hi
Today I've added a couple of lines in my source code, and I'm very ashamed of
it.
it "runs", and I know what it does (for now), but it's "too clever".
I have "abused" the "else" clause of the loops to makes a break "broke" more
loops
for i in range(10):
print(f'i: {i}')
for j in range(10):
print(f'\tj: {j}')
for k in range(10):
print(f'\t\tk: {k}')
if condition(i, j, k):
break
else:# if there weren't breaks in the inner loop,
continue # then make anoter outer loop,
break# else break also the outer one
else:
continue
break
the "magic" is in that repeated block... it's so convoluted to read... still
it's very useful to omit "signals" variables or the need to refactor it in a
function with an explicit return or other solutions.
is there any chance to extends the python grammar to allow something like
for i in range(10) and not break:
print(f'i: {i}')
for j in range(10) and not break:
print(f'\tj: {j}')
for k in range(10):
print(f'\t\tk: {k}')
if condition(i, j, k):
break
with the semantics of break a loop if an inner loop "broke"?
--
https://mail.python.org/mailman/listinfo/python-list
Re: transform a "normal" decorator in one for async functions
Il giorno martedì 18 settembre 2018 17:36:16 UTC+2, vito.d...@gmail.com ha scritto: > > > is there a way to "convert" a "normal" decorator in one that can handle > > > async functions? > > In general? No. > Ouch. > > I'm new to the "async" world, but so this mean that all of the (appliable) > decorators present in the various libraries have to be "paired" with async > versions? I was also thinking: there are some decorator functions (and decorator functions factories) also in the stdlib (functools.wrap, property, classmethod ... you name it) so this means that also we need to check each of them if is applyable to async functions? -- https://mail.python.org/mailman/listinfo/python-list
Re: transform a "normal" decorator in one for async functions
Il giorno martedì 18 settembre 2018 17:15:22 UTC+2, Thomas Jollans ha scritto: > > but I cannot rewrite this library. > > Perhaps not, but surely you can write your own decorator that does > whatever this library's decorator does for async functions? Presumably > you have the code... well, maybe? While I could have access to the sources, I don't want to "maintain" (part of) this library. Worst even if I need to maintain it in my project, and not upstream. > > is there a way to "convert" a "normal" decorator in one that can handle > > async functions? > In general? No. Ouch. I'm new to the "async" world, but so this mean that all of the (appliable) decorators present in the various libraries have to be "paired" with async versions? -- https://mail.python.org/mailman/listinfo/python-list
transform a "normal" decorator in one for async functions
Hi.
Let's say I have this library that expose a decorator; it's meant to be used
with normal functions.
but I have to "apply" the decorator to an async function.
>From what I understand I cannot "really" wait for this decorated async
>function, as it's not really "async", and, from a simple test I made, I see
>that the order of execution is not really "straight" (I have simplifield the
>example to the bone)
import asyncio
def deco(fun): # the "classic" decorator
def wrap(*args, **kwargs):
print('wrap begin')
try:
return fun(*args, **kwargs)
finally:
print('wrap end')
return wrap
@deco
async def decorated_async():
print('a')
await asyncio.sleep(1)
print('b')
loop = asyncio.get_event_loop()
loop.run_until_complete(decorated_async())
loop.close()
the output of this script is
wrap begin
wrap end
a
b
while an "async-aware" decorator (with an "async" wrap that "await"s the fun
call) would print the "wrap end" line at the end.
I can easily rewrite my dumb decorator to handle async functions (I can just
make an "async def wrap" and "return await fun"), but I cannot rewrite this
library.
is there a way to "convert" a "normal" decorator in one that can handle async
functions?
Thanks
--
https://mail.python.org/mailman/listinfo/python-list
