stripe
Feature request: asyncio support
Hi folks,
I was wondering what it would take to get this library to support asyncio. This would mean it would be possible to use Python 3.5+ async/await coroutines with a number of async frameworks.
Looking at the code it would be possible to create a new Http Client with say aiohttp, but it looks like the code would need to be modified in other places in order to support it.
Has the Stripe team considered async support?
Hi Stephen,
I really like this idea!
The bad news is that I don't know if we're going to be able to do it in the immediate future :/ The library is currently primarily targets Python 2, and we use "2to3" for compatibility across both major versions. I just ran some analytics against the Stripe platform, and requests from Python 2 outnumber requests from Python 3 by a full 10 to 1, so for the time being, this setup still makes sense for the project.
It might be possible to invert the primary major version by using something like "3to2" instead, but I suspect that it might not support really fancy Python 3+ constructs like async/await. Also, for now, the asyncio docs seem to suggest avoiding the package if wide version support is necessary:
The async def type of coroutine was added in Python 3.5, and is recommended if there is no need to support older Python versions.
Given that Python's 2 to 3 chasm seems to be a problem that might never be solved, I suspect that a more plausible way to get this in would be start maintaining a separate Python 3 fork that can leverage the richer features of 3+. Unfortunately, I can't promise this anytime soon because we'd really need to ramp up out internal language teams to make it happen.
Even so, I'm going to leave this open and tag it as "future", and hopefully it'll become tractable given a little more time.
@FranzPoize @brandur-stripe's comment above is still largely valid. While we no longer use 2to3, we still need to support Python 2 for the foreseeable future (more than half of Stripe's Python users are on 2.7), and we currently don't have the bandwidth to start a new Py3-only library.
Just food for thought: one way to make asyncio-compatible code with python 2 support is to support Twisted :).
Leaving a +1 on this issue to further raise awareness.
Now that we are within 18 months of Python 2's end of lifecycle support, I imagine there will be an ever-increasing trend of production-ready stripe-python implementations switching from Python 2 to 3.
Hi all, given Python 2's end of life in January 2020, is there any intention to add official support for async Python and await coroutines to the Stripe library in the near future?
Hi @adeadman. We will likely keep supporting Python 2 for some time after the EOL deadline, depending on how quickly our userbase migrates to Python 3.
That said, we're considering shipping a separate Python module stripe-async that would only support Python 3. We've recently started generating parts of our client libraries code directly from the OpenAPI specification file for Stripe's API, so we could realistically maintain two different libraries for Python. We haven't reached a decision yet, but I'll make sure to post an update here when we do.
That's great to hear, an officially maintained library would be preferable to us than contributing to an unofficial one.
How do you collect statistics on the python version your userbase are running? I know we've been python 3 for the last 2 years. The risk is that people who are still running py2 may not even be aware of the end of life - would a deprecation notice be displayed either in their application logs or in the Stripe dashboard?
How do you collect statistics on the python version your userbase are running?
Requests sent from our official client libraries include a X-Stripe-Client-User-Agent HTTP header containing some information about the environment such as the names and versions for the OS and runtime, etc. We use this for both aggregate statistics and individual support.
At the moment, ~35% of stripe-python users are still running Python 2. It's slowly declining, and I'm hoping there will be a sharper decrease once we reach the EOL deadline 🤞
The risk is that people who are still running py2 may not even be aware of the end of life - would a deprecation notice be displayed either in their application logs or in the Stripe dashboard?
Yes! This is also something we've been talking about. There should be some form of notice in the dashboard to inform users and encourage them to upgrade sooner rather than later.
Any updates on this issue? For us being able to send requests asynchronously is quite critical. Without support from the library one is forced to use ugly workarounds like running the stripe calls in a separate executor.
Hi @rubik. As I mentioned in a previous message, we're leaning towards shipping a separate library (both because we'll probably need to support Python 2.7 for some time past the EOL, and because Python's async model does not make it easy to ship sync and async code side by side).
No ETA yet, but I'll see if this is something we can prioritize this half.
I understand the need to support people running legacy versions from a business perspective but it is disappointing that EOL software is preventing progress (this is not a criticism of stripe directly, more a general commentary on the 2-vs-3 situation). Running in its own thread executor is enough for my simple use case for now... thanks for the lib!
@arlyon Thanks a lot for the feedback and we agree it'd be great to support this. The change is a pretty big paradigm change though and so doing a separate library makes more sense I think as we can also plan adding support for types and pinning to a specific API version. We're looking into this internally to see whether this is work we could prioritize this year!
Any new updates since 5 months ago? I'm tempted to make my own more modern async and sync wrapper if not.
@WardPearce No progress just yet unfortunately. We focused on doing code generation for stripe-dotnet which is now complete. We're now improving stripe-java, with hope to add the new client/service infrastructure to it first. While adding async support to stripe-python is something we want to do, it'll likely take a while before we get to it unfortunately.
I'm starting development over @ https://github.com/WardPearce/stripe3
Feel free to open some PRs or submit requests via issues. Pretty early stages development, development will start to speed up after the 13th.
@WardPearce can I request that you keep #689 in mind if you're developing something from scratch? :)
hmmm, i seem to have gotten most of this current lib working using the loop.run_in_executor(None, functools.partial(func, args)) but i seem to not be able to verify webhook requests, any idea why? i dont mind sending info as its still in the testmode part of stripe.
@part1cleth1ef I'd recommend talking to our support team for help instead: https://support.stripe.com/contact/email
Hi, if anyone's interested, I've created an async wrapper for stripe: https://github.com/bhch/async-stripe.
@remi-stripe nvm, i fixed it, it turned out that because i was using aiohttp.web instead of flask, i used the wrong method, i fed it json instead of a string which it apparently wanted. fixed the issue now lmao
I've been busy working on like 3 other projects, I will eventually get my wrapper done. It will be completely different to the current design stripe uses. Aiming to be more developer friendly.
Will be similar to my b2 wrapper https://github.com/WardPearce/backblaze
between stripe, square, et. al, it seems this is going to take years for adoption - one of the primary difficulties in async for large cos. whom consume stripe et. al is the chicken in the egg problem: a handful of third party libraries support async, and you need all libraries to support async in order to have a seamless transition.
thank you for the wrappers above - think this will be best and a separate github repo likely needed
one place to start could also be to create an official rust api client w/ async & auto generate python wrappers
If python 2 support could be removed from stripe-python, porting to async would basically just mean porting the http client to something like HTTPX (ofc thats a lot easier said then done).
Personally I'd take the project on myself, but I've been busy recently & stripe is a massive API
I would recommend just wrapping all your calls with loop.run_in_executor.
I would recommend just wrapping all your calls with loop.run_in_executor.
Can you quote an example? @part1cleth1ef
@part1cleth1ef @abdullahmujahidali run_in_executor will use threading (not ideal for networking). I've created a pure async wrapper: https://github.com/bhch/async-stripe which will give you better performance.