Question about Python/C++ API Inconsistency
See original GitHub issueIs 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.
Issue Analytics
- State:
- Created 4 years ago
- Comments:7 (4 by maintainers)
Top Results From Across the Web
Inconsistent arguments CPLEX error Python API
I got a CPLEX error: Inconsistent arguments. I am suspecting that the ub is giving me this problem as when I removed it...
Read more >Inconsistent inference time between C Python API ...
Describe the bug The Python API appears to both be faster and consume more GPU memory than the C API. When looking at...
Read more >python variable type inconsistency
It seems that when creating variables via `xpress.var` or `xpress.vars`, the `vartype` argument is integer. But in `problem.chgcoltype()`, ...
Read more >Issue 14850: The inconsistency of codecs.charmap_decode
c ) uses different algorithms for exact strings and for other. We need to fix it? If yes, what should return `codecs.charmap_decode(b'\x00', ' ......
Read more >Infeasibility and inconsistency
Note that both statuses infeasible and inconsistent can also be encountered on problems ... In the APIs, the principle is the same. Python;...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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.Thank you for adding documentation on this. The situation is much clearer now.
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 forconcurrent.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.