Maintaining and updating a Python library necessary to interact with Substrate definitely falls within this scope, provided a case can be made that it is essential to the ecosystem and not already covered by an existing financed project like subxt-python.
There is also a maintenance grant, which focuses on fixing bugs, updating outdated features, and providing cost reports at the end of each month, that could be considered.
This can be a great way to free up some time for an individual or a small team to provide a more robust library for client development.
This project has potential! Right now, it seems unknown from the community, since I am the first one starring it on GH, and there are no issue nor PR. philoniaire did set up the first bricks against remunerations, but, not community took over this project. If the project ever gets or is unmaintained, problems could begins.
I had an issue with a Python library using Rust which still does not support Python 3.13. Currently subxtpy does not support Python 3.13. That’s not the case with a full-Python library, which usually support next minor Python version out-of-the-box, except required minor code changes regarding deprecations. On the other hand, Python library based on Rust code, requires more efforts to support next Python minor version.
The project also has to create a new release to publish wheels with built code on PyPI, to support new Python versions. That’s one disadvantage for using compiled languages in Python libraries. The advantage is of course speed. In the end, these criteria falls into maintenance topics.
These are my fears. But yeah, that’s good to have a second choice! Two Python libraries
@vit one aspects you might not like about subxtpy is that it requires asynchronism property usage.
Subxt requires an async runtime. The only way would be to wrap the async parts into blocking functions. This could be done in Rust as well as in Python.
The runtime used here is single-threaded tokio, so I guess you can use it with blocking and handle the multithreading yourself.
My point was not to switch to subxtpy, but to show that if anyone has the time or can allocate time through a grant, the Web3 Foundation can help. The idea is simply to present the limitations/disadvantages of subxtpy to the Web3 committee so that substrate-interface can be financed alongside it.