Jake Vanderplas

There's a third option not mentioned here: use `__array__` as the standard convert-to-array function, and give libraries where this is not the apropriate behavior here some way to opt-out. Adding...

Couldn’t you accomplish option 2 without the performance impact by looking to see if certain modules are already in `sys.modules`?

Yeah, probably something like that. I might even avoid the imports, and wrap with a `try`/`except` just in case there's something strange (like `torch.py` in the namespace, which either doesn't...

I didn't mean to suggest any complicated abstraction; I was thinking something simple like this: ```python ARRAYLIKE_OBJECTS = [('jax', 'Array'), ('torch', 'Tensor')] def maybe_convert_to_array(x): for mod, name in ARRAYLIKE_OBJECTS: try:...

I don't know

Thanks for following up!

Hi - we're seeing a couple test failures here that have been fixed on the main branch. Can you rebase against the most recent main branch commit so we can...

Hi @rajasekharporeddy – thanks for the followup, but `jnp.promote_types` is not the correct point of comparison here. An updated version of my code from 2020 (which used private utilities then,...

JAX's current `top_k` functions are in the `jax.lax` namespace, while the array API implementations will be in the `jax.numpy` namespace. So there is no issue with having different API conventions...

For what it's worth, `x += x[i]` does work in JAX, and is compatible with JIT. JAX arrays don't override `__iadd__`, so Python falls back to essentially `x = x...