[GRASS-git] [OSGeo/grass] 063dea: grass.tools: Add NumPy arrays IO to Tools (#5878)

[Vaclav Petras]

  Branch: refs/heads/main
  Home:   https://github.com/OSGeo/grass
  Commit: 063dea1a969aeb36fdd93966614e1b3f4ba7e7bd
      https://github.com/OSGeo/grass/commit/063dea1a969aeb36fdd93966614e1b3f4ba7e7bd
  Author: Vaclav Petras <wenzeslaus at gmail.com>
  Date:   2025-09-05 (Fri, 05 Sep 2025)

  Changed paths:
    M lib/gis/parser_md_python.c
    M python/grass/benchmark/runners.py
    A python/grass/tools/benchmark/benchmark_grass_tools_numpy.py
    M python/grass/tools/session_tools.py
    M python/grass/tools/support.py
    A python/grass/tools/tests/grass_tools_session_tools_numpy_test.py

  Log Message:
  -----------
  grass.tools: Add NumPy arrays IO to Tools (#5878)

This is adding NumPy array as input and output to tools when called through the Tools object.

My focus with this PR was to create a good API which can be used in various contexts and is useful as is. However, the specifics of the implementation, especially low performance comparing to native data, are secondary issues for me in this addition as long as there is no performance hit for the cases when NumPy arrays are not used which is the case. Even with the performance hits, it works great as a replacement of explicit grass.script.array conversions (same code, just in the background) and in tests (replacing custom tests asserts, and data conversions).

While the interface for inputs is clear (the array with data), the interface for outputs was a pick among many choices (type used as a flag over strings, booleans, empty objects, flags). Strict adherence to NumPy universal function was left out as well as control over the actual output array type (a generic array is documented; grass.script.array.array is used now).

The NumPy import dependency is optional so that the imports and Tools objects work without NumPy installed. While the tests would fail, GRASS build should work without NumPy as of now.

This combines well with the dynamic return value with control over consistency implemented in #6278 as the arrays are one of the possible return types, but can be also made as part of a consistent return type. This lends itself to single array, tuple of arrays, or object with named arrays as possible return types.

Overall, this is building on top of Tools class addition in #2923. The big picture is also discussed in #5830.



To unsubscribe from these emails, change your notification settings at https://github.com/OSGeo/grass/settings/notifications