Meh, speaking as a user of their new python sdk, the end result is underwhelming. I don't blame OpenAPI but the Plaid team for not putting in much effort.
For example, they want all arguments to be typed. So instead of using DoSomething("US"), they want DoSomething(SomePlaidCountry("US")). It gets extremely verbose -- for no good reason either as it just moves the runtime check in another method, it doesn't remove it. What's more, it doesn't even actually use python typings. In fact it's super incompatible with them because a bunch of their types are generated at runtime, lazily imported, using magic etc which confuses typing engines.
What would this look like it it were any good? Native python types and native enums. But i doubt anyone on their python team has worked with either, as they just reinvented the wheel.
I love these :). I remember back in uni I would fill my program with them, but then fail the autograder because they were using an older version of Python 3 (support was only added in 3.5). I also remember back when the system didn't even have support for self-hoisting, so you couldn't make recursive type definitions and would have to do string annotations like `(x: 'LinkedListNode')`. Fun times.
Assuming that strongly typing the library in some way is beneficial (which we believed), let's look into the options we're provided here. Python's current type hint system requires external tools to enforce it and isn't enforced at runtime or "compilation." The system we have in our library creates a ton of objects that end up enforcing runtime constraints on input values. Failing at runtime because of invalid input is good. I've worked on Python stacks that totally do not use type hints (and my Emacs setup probably didn't back then either), and would have been saved tons of time debugging if the library just told me I was doing things wrong. This is at a definite cost of verbosity. There are definitely ways we can cut verbosity in this model (enums was actually a great example). Considering we were working on 5 languages at the same time though, it was difficult to do everything we wanted before shipping.
There's also the final reality that the generator we chose to use defaults to this behavior. We didn't find a better OpenAPI generator out there, and we weren't opposed to this generated output. There wasn't much wheel invention here, but we did attempt to make it spin smoother at times :D.
For example, they want all arguments to be typed. So instead of using DoSomething("US"), they want DoSomething(SomePlaidCountry("US")). It gets extremely verbose -- for no good reason either as it just moves the runtime check in another method, it doesn't remove it. What's more, it doesn't even actually use python typings. In fact it's super incompatible with them because a bunch of their types are generated at runtime, lazily imported, using magic etc which confuses typing engines.
What would this look like it it were any good? Native python types and native enums. But i doubt anyone on their python team has worked with either, as they just reinvented the wheel.
Example issue: https://github.com/plaid/plaid-python/issues/340