AJ Friend

I think it makes sense to keep the API agnostic as to the ordering of the cells, but the internal representation should always have them in the "canonical ordering". Does...

I'm working on the v4 interface here: https://github.com/uber/h3-py/pull/301 The major change is that we'll have functions like `h3.geo_to_cells(geo, res)` that can take in any object that implements a `__geo_interface__`, which...

We tried previously having an "unstable" API to experiment with things like vector functions: https://github.com/uber/h3-py/pull/147 I'd be interested in bringing that back in the 4.0 branch, probably still as an...

> 1. It seems that `h3-py` was designed to be "self-contained" without `numpy`. But I was thinking to have a set of APIs that accept numpy arrays. This may require...

> * There are a few backends: `basic_str`, `basic_int`, etc that shares the same API. Only a subset of them will be relevant for a "vectorized" version. I am thinking...

> 3. Do you have a sense of how much faster a vectorized version would be? For now, if I move the for-loop from python to C I get around...

For what I'm thinking, the average user would not need to know anything about Cython. If we produced a separate package (called whatever, maybe `h3vectorized` for example), users would be...

Also, feel free to flag the discussion in Slack, but I'd like to keep the main discussion on Github since Slack history gets lost relatively quickly.

I threw together an example that still needs some work, but this would be the idea: https://github.com/ajfriend/h3_example_package

> You might want to mention in the respective doc strings that the ordering is not guaranteed from these functions. Done