Skip to content

Conversation

cmastalli
Copy link
Member

The current __getitem__ only accepts integers, which means Eigenpy does not yet support Python slicing. So a slice object (xs[1:]) hits the "Invalid index type" path, as triggered in today's Crocoddyl pre-commit PR (see https://github.com/loco-3d/crocoddyl/actions/runs/17928428896/job/50980225223?pr=1433).

This PR introduces a slice-aware __getitem__. The basic strategy is to add an overload that accepts boost::python::slice and returns a Python list (with element references if you need mutability, mirroring our single-index path).

I also included a copyright update, but I'm happy to remove it if you guys feel it's not justified.

@ManifoldFR
Copy link
Member

Hi Carlos,
Thanks a lot for this! I'd added slice support for a type in one of my packages some time ago and I never realised we never had this in eigenpy.

I'll take care of reviewing this PR @jcarpent @nim65s.

@cmastalli can you add a test for this feature?

@cmastalli
Copy link
Member Author

@ManifoldFR -- please note that apart from handling your comments, I included a Cmake command to enable us to run the Python tests individually.

@ManifoldFR ManifoldFR changed the title Supported Python slicing in std::vector Add support for Python slice objects for std::vector Sep 23, 2025
Comment on lines 178 to 179
static bp::object elem_ref(Container& c, index_type i) {
typename bp::to_python_indirect<value_type&,
bp::detail::make_reference_holder> conv;
return bp::object(bp::handle<>(conv(c[i])));
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this work with most types we bind? @jorisv

@cmastalli
Copy link
Member Author

cmastalli commented Sep 24, 2025

Hey @ManifoldFR and @jorisv! I have addressed your comments; however, I am unable to make changes to my commits as I am using a MacBook (i.e., the default filesystem is case-insensitive).

In a nutshell, Git can’t represent the accelerate.hpp vs Accelerate.hpp files at once and gets "confused." This means that I cannot perform git rebase -i as it thinks the files are unstaged. I suggest (1) merging these two files to be compliant with macOS developers in another PR, and (2) squashing my commits when merging.

@jorisv
Copy link
Contributor

jorisv commented Sep 24, 2025

Hello @cmastalli,

You're right about accelerate. We keep the old accelerate.hpp header for back compatibility but didn't notice this is an issue for non case sensitive OS.

@ManifoldFR I see three options:

  • We move Accelerate.hpp to accelerate.hpp. This preserve EigenPy API <= 3.11 API.
  • We rename Accelerate.hpp into AccelerateSomething.hpp
  • We remove accelerate.hpp. This break the API but since I don't think many people are using it, it's maybe not an issue…

@ManifoldFR
Copy link
Member

I say we go with the third option @jorisv. Accelerate isn't even something someone running a packaged version of an eigenpy release would be using - because the package would depend on Eigen 3.4 at most, which doesn't have Accelerate support! So breaking the include is a-ok in my book.

@ManifoldFR
Copy link
Member

Carlos can you fix the NPY002 error the ruff linter reports?

@jorisv
Copy link
Contributor

jorisv commented Sep 25, 2025

@ManifoldFR @cmastalli Accelerate.h has been fixed and I have rebase this PR on devel

@cmastalli
Copy link
Member Author

Carlos can you fix the NPY002 error the ruff linter reports?

Done!

@cmastalli
Copy link
Member Author

@jorisv and @ManifoldFR -- I have squashed a few commits and fixed the NPY002 error. It could be good to merge now!

@ManifoldFR
Copy link
Member

Ruff and clang-format are still complaining in the pre-commit run. Did you have pre-commit installed in your checked-out repo?

@ManifoldFR
Copy link
Member

Otherwise it will be good to merge

@cmastalli
Copy link
Member Author

Otherwise it will be good to merge

Awesome! I didn't know that Eigenpy is using pre-commit. I just pushed a commit that runs pre-commit linting.

@ManifoldFR ManifoldFR merged commit b22efa8 into stack-of-tasks:devel Sep 25, 2025
34 checks passed
@cmastalli cmastalli deleted the topic/slide-vector branch September 26, 2025 03:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants