Question about Python/C++ API Inconsistency

Is there a reason to have a different name for the TileDB Context in the Python and C++ APIs? In Python it is written as Ctx and in C++ it is simply Context. I think the API would benefit from being consistent here and hopefully as many other places as possible.

[ihnorton]

native asynchronous (async/await) support for reading, writing

Yes, definitely on the roadmap (#64). I think the simplest option will be concurrent.futures, which is thread-safe, but we might be able to support asyncio too. I’ll take a deeper look soon. Python 2 support may not be possible/reliable though (there is https://pypi.org/project/futures/ but I don’t know how well it works) – fortunately the ecosystem seems to quickly be converging on 3 now, ahead of the py2 end-of-life.

[bhgomes]

Thank you for adding documentation on this. The situation is much clearer now.

So far I think multiple contexts are mainly used with the C++ API in a multi-threaded, batched-read situation. It will likely not be an issue in routine use, especially from Python, but we do need to support multiple contexts in the API.

I think eventually either the TileDB team or a third-party will want to add something like native asynchronous (async/await) support for reading, writing, … etc. Having this technology fully integrated into the Python API would be extremely helpful if not necessary for this. Even support for concurrent.futures-like features is something people will want.

I am looking to use TileDB as a central dependency for an upcoming project and I would see a lot of potential/necessity for such features and would love as much access to the underlying machinery as possible from Python.