slack-ruby-client VS stripe-python

Ah, I'm surprised Slack doesn't support Ruby, but to be fair they are pretty tight on official support with only Python, Node and Java.

Fortunately there's https://github.com/slack-ruby/slack-ruby-client, but it's not official. Although it seems to be a good example of a community driven library coming together. I haven't used it personally (I never interfaced with Slack in a Ruby app) but at a glance it looks like it has really good docs, a decent amount of contributors, well maintained, etc.. If I were building some Rails app that used Slack I'd likely reach for this and not feel bad about it.

Kind of a bummer on the other 2 tho. Thankfully I wouldn't be building too many apps using those tools, but I get the point you're saying. In the grand scheme of things I think this also shows at how much more popular Python is than Ruby.

Slack's Ruby client works well and is well organized: https://github.com/slack-ruby/slack-ruby-client

Make async requests in the beta release of stripe-python: The stripe-python beta channel now has built-in support for async control flow, backed by the httpx or aiohttp http libraries.

Instantiate StripeClient in the Python SDK: Stripe-python v8.0.0 introduced StripeClient, upgrading from a single global configuration to enable multiple thread-safe instances.

Let's start by installing the Python library for Stripe, which is available on Github.

Use types with the Python SDK: Strengthen Python integrations with type annotations using the stripe-python library starting in v6.8.0b3 through the beta channel.

You should use the python package that stripe provides: https://github.com/stripe/stripe-python

The api_key is being passed down to every object. You can see it being fed to the constructor for Customer because it is a child of StripeObject.

I've been maintaining async-stripe for over a year. It is the only async client for Python. It fixes a long standing feature request (issue #327).

New API version released: Version 2022-08-01 of the Stripe API has been released along with major version upgrades to all official client libraries, namely Dotnet, Go, Java, PHP, Node, Python, and Ruby. Read more about breaking changes in the API upgrades section and how to upgrade.

> Every time a new language comes out we have to recreate millions of baseline libraries and it just sucks. As a dev I want to be able to make use of great libraries oblivious to what they are created with.

Technically this tool mostly does exist already with the OpenAPI specification if we're talking about REST APIs. If you put in the leg work to create a very detailed specification which is a YAML file, you can generate programming language specific SDKs out of it.

Stripe has publicly mentioned[0] they mostly use this spec to generate their SDKs (even as of a few years ago), even so auto-generated code still requires developer time and there's a level of "hey we're dedicated to internally supporting this". It's a huge deal having a provider internally support your language's SDK.

[0]: https://github.com/stripe/stripe-python/issues/694#issuecomm...

The stripe package is actually maintained by Stripe.