Repository navigation
Async context manager #535
Description
Usecase:
c = Counter("errors_count")
@c.count_exceptions()
def foo(): # counter = 1
raise Exception()
@c.count_exceptions()
async def foo_async(): # counter still 1
await sleep(1)
raise Exception()
Quick search in project did nothing to me.
It would be cool if counter (and other objects) would handle this right out of the box, especially if we're talking about metrics for web world.
Activity
brian-brazil commentedon Apr 10, 2020
How would that work, keeping in mind that we support all the way back to 2.6?
denisSurkov commentedon Apr 11, 2020
Well, I didn't think about it. Sorry.
LittleLampLight commentedon Apr 21, 2020
@brian-brazil, what do you think about Python version check inside decorator to exclude support for non-async syntax. Seems like it's not gonna affect backwards support. And will come really handy
brian-brazil commentedon Apr 21, 2020
I'm not sure how that'd work given that it's a syntax thing, and thus 2.6 would choke on it.
LittleLampLight commentedon Apr 21, 2020
Yup, actually i was thinking about depending on version import of async compatible syntax. But it looks too complex and such case may be implemented easier with context manager as well.
actually if someone really need the decorator then he can implement it by himself with a few lines of code
MSeal commentedon Feb 10, 2021
The silent failure is surprising here.
I believe it's possible to do version checks inside the
__call__, then do a dynamic import for async to do the async check against the function passed in to avoid making code calls that aren't present in 2.6.e.g. https://stackoverflow.com/questions/51344906/in-python-how-to-use-decorator-compatible-with-normal-function-and-coroutine-fun
Sure, but it's unexpected and causes metrics to be easily missed in a Python 3 world where 2.x is past EOL.
nikicat commentedon Feb 23, 2021
Why don't just drop support for not-maintained-for-7-years Python 2.6? I vote for native asyncio support instead of ancient py2.x.
csmarchbanks commentedon Feb 23, 2021
I pulled some data for downloads over the last 6 months by python version:
I am hesitant to remove support for anything used by more than a couple percent of users, which means I think support for 2.6 could be removed but not yet 2.7.
csmarchbanks commentedon Feb 23, 2021
Also, note that 2.6 support has actually already been removed in master, but not yet in a release (#592 for reference).
MSeal commentedon Feb 23, 2021
Be aware a lot of download traffic is bot driven. So downloads may not be reflective of actual user percentages as there's a fair bit of old tooling churning away at 2.7 builds that aren't used anymore. There was a similar level of traffic for 2.7 on other projects I maintain but actual users keyed on library updates for that version ended up being much smaller than initially perceived by downloads, if that helps with decision making.
RonRothman commentedon Mar 4, 2021
Many other popular libraries have ended support for Python 2, regardless of how many 2.x downloads were reported. (
gunicorncomes to mind.) We are a hard +1 for supporting Python 3 only, going forward.csmarchbanks commentedon Nov 1, 2021
I opened #717 for removing python 2 support, and enabling this feature.