Open theeldermillenial opened 1 year ago
Hi!
We don't really have the capacity or knowledge regarding what you propose but it sounds pretty good, especially type hints/annotations. I think you can go ahead and add this. Any form of documentation contributions are always welcome as well.
Regarding OpenAPI schemas, the generators often try to generate whole API library which doesn't yield very nice results for our spec. The spec is pretty huge so this is a much bigger task to incorporate into existing library like this. Such addition would be welcome as well.
Ideally the additions would be backwards compatible (or optional), similar to how the API currently allows three different result types - i.e. you could add 4th or simply replace the default one if it seems more appropriate (you decide! :smiley:).
Do not worry about breaking changes, we have a releases and versions to handle that so even if there are major breaking changes, users can simply set an upper bound and migrate later (iff it requires code changes on their side).
That was a very delayed response hahaha.
I saw the PR, and I'm excited to try this out now with the new wrapped functions. The IDEs I use make extensive use of code introspection, so this will make developing a lot smoother because I will be able to read docs and inputs/outputs while I code rather than looking up the docs.
When I asked this question, I had a ton of time. And now, I have significantly less. I do have plans for doing some work with this, because I think I've made a few tools that will help the development experience. Some of it is pydantic classes, others are things like rate watchers/limiters that nicely monitor and limit call rates on the client side.
If I know that you are open to PRs, I would much rather try putting them here rather than making a utility package. Everything I add would be optional and backwards compatible. I'll submit them piecemeal so that it's not an all or nothing thing, and I will not be upset if any of them are rejected :)
That was a very delayed response hahaha.
:upside_down_face: Sorry for that! I've set watch all activity here so I don't miss any more issues nad PRs.
If I know that you are open to PRs, I would much rather try putting them here rather than making a utility package. Everything I add would be optional and backwards compatible. I'll submit them piecemeal so that it's not an all or nothing thing, and I will not be upset if any of them are rejected :)
Sounds good, looking forward to it!
I am working on an open source project called
minswap-py
that usesblockfrost-python
to submit requests. I think the package is great, but could be greatly improved with a nominal amount of effort.First, it would be helpful for type hints, annotations, docstrings, etc, if the decorators used the
update_wrapper
function. This should be a few lines of code spread out across a few functions, so this would be a really easy thing to implement. The purpose of this would be to help with coding experience withblockfrost-python
, and would also help with code introspection.https://docs.python.org/3.9/library/functools.html#functools.update_wrapper
Second, the responses are handled in a very generic, robust way that works well. However, it would greatly benefit from some of the openapi model generators that exist. I'm particular partial to the
datamodel-code-generator
, which reads an OpenAPI spec and autogenerates a bunch of classes that both validate responses and provide helpful typehints while coding. Based on what I see in the code, it looks like the code is probably autogenerated from the OpenAPI spec anyway (or someone is really really meticulous), so regenerating the code to autocast json response to autogenerated pydantic models should not be overly burdensome.https://github.com/koxudaxi/datamodel-code-generator/
I have experience with this stuff and would be more than happy to contribute these components because it would help my projects. I would rather contribute this directly to this module so everyone could benefit from it, rather than doing a special implementation for myself. However, I understand that this code is now adopted by thousands of users a month so suggesting some of these changes like adding in pydantic models should be approached with care. If this is something you would like to tread lightly on, would you mind sharing any API generation code you used so I could implement this in a separate repository? I will be doing this for my projects to help improve and speed up the process of development regardless.
I think the first proposal for properly wrapping functions in decorators should be an easy and painless implementation. The pydantic implementation could be potentially problematic.