Async storage buckets

[anand2312]

This PR adds async support to the storage buckets API by switching to httpx. All sync methods can now also be called with async/await syntax, by passing is_async=True to the StorageBucketAPI constructor (this value defaults to False).

Other smaller changes:

• Removed version pin from pre-commit-config (would error out if you did not have a local install of Python 3.7)
• Added name, public arguments to StorageBucketAPI.create_bucket method
• Better error propagation by raising a StorageException, instead of excepting all errors and printing them out.
• Type-hinted the storage_bucket_api.py file (I might've gone a little overboard with that, sorry)

[leynier]

Personally, I don't think sync/async support should be done on the same class depending on a parameter in initialization.

The reason is that a method is made Awaitable or not, through a Union, and that causes that to apply the await or not to the method, it is necessary to use the cast by the type annotation.

I think that the path that the HTTPX itself follows is a good one, that of using two different classes.

[anand2312]

I agree, it's not the neatest solution out there, I'm open to suggestions. I was mainly trying to reduce the amount of code duplication that would occur with two separate classes.
I can split it into two classes if more people are leaning towards that direction

[leynier]

I have been investigating and I think this way is very good. I will test it with gotrue-py to see the result.

The idea is to use unasync and httpx, unasync generates the synchronous client, so implementing the asynchronous client with some special features unasync when building the package that is uploaded to pypi will generate the synchronous client.

https://sethmlarson.dev/blog/2020-06-27/designing-libraries-for-async-and-sync-io
https://github.com/sethmlarson/pycon-async-sync-poster
https://github.com/python-trio/unasync
https://github.com/encode/httpx

[J0]

A few nits but otherwise looks good to me. I think it's quite well put together so kudos on that. Thanks much!

Ping me(J0) on discord if you haven't received any swag yet.

[J0]

@leynier I think you raise some great points about splitting the code into separate async/sync clients. The links provided are really helpful so thank you for pointing this out!

We can poll the community and see what they'd prefer and switch if necessary but for now I hope to accept this PR. What do both of you think?

[leynier]

@leynier I think you raise some great points about splitting the code into separate async/sync clients. The links provided are really helpful so thank you for pointing this out!

We can poll the community and see what they'd prefer and switch if necessary but for now I hope to accept this PR. What do both of you think?

All good for me 👌🏼

[dreinon]

Hey @J0 @leynier @anand2312!
I also think @leynier made a good point on using unasync, and since gotrue will use it too, it would add consistency to the libraries.

Nevertheless, this PR is such a good job, so I'm thinking in 2 options:

1. We could go forth accepting this PR and then maybe @leynier can open another one.
2. Maybe @leynier could open another PR from his own branch to @anand2312's branch, and if they accept it, then the changes would appear in this PR and we could accept the "final" version.

What do you all think?

[leynier]

I'm willing to help in whatever is needed, so, I adjust to what @J0 and @anand2312 decide.

[anand2312]

@dreinon @J0 I think I'd rather merge this and move it to unasync when @leynier is able to, as this PR also (accidentally) includes the fix for #65 ; I wanna move onto adding async support to more of the library, so I'll make sure to implement unasync next time

[dreinon]

Lgtm

[J0]

Sounds good to me! Going to merge this in.

[J0]

Thanks everyone for your inputs 😄