- While annoying, this is the only way to get C++ exception handling out of the happy path for normal iteration.
- Implements sq_length and sq_item for the sequence protocol (used for iteration, including list() construction).
- Implements mp_subscript for general use (i.e. foo[1] and foo[1:1]).
- For constructing a list(op.results), this reduces the time from ~4-5us to ~1.5us on my machine (give or take measurement overhead) and eliminates C++ exceptions, which is a worthy goal in itself.
- Compared to a baseline of similar construction of a three-integer list, which takes 450ns (might just be measuring function call overhead).
- See issue discussed on the pybind side: https://github.com/pybind/pybind11/issues/2842
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Bindings/Python/PybindUtils.h | ||
---|---|---|
237 | Don't we want a non-empty error message here? | |
255 | Ditto. | |
302 | I suppose this cast can never throw (self is always an instance of Derived * if CRTP is used properly), but it may warrant a comment. | |
325–327 | Can't we just do if(PySlice_Check(rawSubscript)) instead of casting and catching an exception? |
Thanks! I have little to add beyond @ftynse 's comments.
mlir/lib/Bindings/Python/PybindUtils.h | ||
---|---|---|
290–293 | You might consider linking to https://github.com/pybind/pybind11/issues/2842 and you might also consider commenting on that issue linking to your solution, since I'm sure others may have the same need. |
mlir/lib/Bindings/Python/PybindUtils.h | ||
---|---|---|
237 | The kind of error set is an index error, OOC is there any other index error than OOB? |
mlir/lib/Bindings/Python/PybindUtils.h | ||
---|---|---|
237 | It still has a message: >>> a = [1,2,3] >>> a[5] Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: list index out of range |
FYI - the benchmark script: https://gist.github.com/stellaraccident/ba86946ff70ff3084af62b476a05c7c9
Still LGTM. Some test coverage that we actually raise the errors we expect wouldn't hurt.
Don't we want a non-empty error message here?