Feature request: asyncio support

[stephenmuss]

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?

[brandur-stripe]

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]

Any news on this ?

[ob-stripe]

@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.

[glyph]

Just food for thought: one way to make asyncio-compatible code with python 2 support is to support Twisted :).

[nathanielcompton]

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.

[perpetual-hydrofoil]

https://pypi.org/project/asyncio_stripe/

[adeadman]

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?

[ob-stripe]

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.

[adeadman]

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?

[ob-stripe]

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.

[rubik]

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.

[ob-stripe]

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.

[arlyon]

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!

[remi-stripe]

@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!