Split resource.py

[ob-stripe]

Splits resource.py into separate files. At 1200+ lines long, it was becoming hard to maintain.

This PR:

• moves StripeObject into stripe.stripe_object

• moves the abstract API classes (APIResource, CreateableAPIResource, UpdateableAPIResource, DeletableAPIResource, ListableAPIResource and VerifyMixin) into stripe.api_resources.abstract

• moves all concrete API resource classes into stripe.api_resources

• moves a bunch of utility methods (including convert_to_stripe_object) into stripe.util

• aliases everything into stripe.resource to maintain backwards compatibility

Additionally, all concrete API classes now have an OBJECT_NAME class constant containing the name of the API resource. This is used by convert_to_stripe_object to map JSON to class instances. This brings the implementation much closer to what's done in stripe-ruby.

Tagging as WIP because there are still a few things I want to polish, but opening the PR now for feedback.

[brandur-stripe]

Incredible @ob-stripe!

It always really annoyed me that all the classes were in one file despite the tests being broken out separately! So you'd load up a test, try to find the equivalent file for it, but then realize you had to look in the giant resource.py.

Strongly in favor of the change in general. The only thing I noticed is that some of these import paths are getting a little long/unwieldy:

from stripe.api_resources.abstract.api_resource import APIResource

That's pretty subjective though, and in practice I don't think it'll matter very much.

[brandur-stripe]

IMO, this might be a little more abstraction than is necessary in that it saves some LOCs, but also makes the code more indirect and harder to follow. In practice the implementation ~never changes, so having it updatable in one place doesn't buy you all that much.

That said, given that it's already here, I think it'd be okay to leave it.

[ob-stripe]

The only thing I noticed is that some of these import paths are getting a little long/unwieldy:

Yeah, I feel the same actually -- I'm torn between clear namespace separation and name brevity / clarity! It's one of the things I want to polish, I'll sleep on it and see if I can come up with something better tomorrow. If you have any suggestions, please do share.

[brandur-stripe]

Yeah, I feel the same actually -- I'm torn between clear namespace separation and name brevity / clarity! It's one of the things I want to polish, I'll sleep on it and see if I can come up with something better tomorrow. If you have any suggestions, please do share.

I'm afraid that I haven't really thought of anything any better :)

I think the part that bothers me most is just that Python's module conventions unfortunately introduce some redundancy in cases like these in that really .api_resource and APIResource are the same thing, but you still need to address both of them.

I don't think it's going to be much of a problem in practice, so just let me know when I should bring this in.

[stripe-ci]

Gerald Rule: tell fred about apple pay changes

cc @fred-stripe

[ob-stripe]

I pushed another commit to update all existing stripe.resource imports to use the new modules instead.

stripe.resource still exists and should still contain all the same references as before, so users who for some reason import directly from stripe.resource will not be affected by this change. We should get rid of stripe.resource in the next major version bump though.

[brandur-stripe]

stripe.resource still exists and should still contain all the same references as before, so users who for some reason import directly from stripe.resource will not be affected by this change. We should get rid of stripe.resource in the next major version bump though.

Nice!

Alright, let's do this.

[ob-stripe]

\o/

[brandur-stripe]

Released as part of 1.69.0!