Add AdjacencyList python wrapper
#3509
Conversation
schnellerhase
force-pushed
the
adjlist_wrapper
branch
10 times, most recently
from
bf1b8a1 to
3466313
Compare
schnellerhase
force-pushed
the
adjlist_wrapper
branch
from
3466313 to
468f8a2
Compare
| is_32bit = data.dtype == np.int32 | ||
| cpp_t = _cpp.graph.AdjacencyList_int32 if is_32bit else _cpp.graph.AdjacencyList_int64 | ||
| cpp_object = cpp_t(data, offsets) if offsets is not None else cpp_t(data) | ||
| return AdjacencyList(cpp_object) |
There was a problem hiding this comment.
So we need a guard for invalid input style (ie np.floating), or do we think the general nanobind error is sufficient? Usually the nanobind type arrays aren’t very expressive when it comes to dtype.
There was a problem hiding this comment.
Defending against such calls would require quite a bit of additional logic. It doesn't end there if we did that, then we would need for example also checks of the shapes of the arrays.
Given that it can not cause a false positive, i.e. if we call with a float array it will not result in a working code path that produces bad results, and type hints being present, that should flag this in a modern IDE or with mypy, I think we should stick to the simplicity of not dealing with it.
Co-authored-by: Jørgen Schartum Dokken <[email protected]>
* Add adjacency list python wrapper * Fix type hint * Add docstrings * Apply suggestions from code review Co-authored-by: Jørgen Schartum Dokken <[email protected]> * Ruff * Add TODO: * Fix default is int64 behavior * Apply suggested docstring --------- Co-authored-by: Jørgen Schartum Dokken <[email protected]>
Introduces a python wrapper for the multi-type exported
AdjacencyList.Addresses (partially) #3483