Inconsistent `get_all_names` API between SubsetService and ViewService

[onefloid]

📖 Description

Currently, there is an inconsistency between SubsetService.get_all_names and ViewService.get_all_names:

• SubsetService.get_all_names returns a single list, controlled via the Boolean flag private=True/False.
• ViewService.get_all_names returns a tuple of two lists (private and public views), without a Boolean flag.

This difference in return types makes the API less consistent and can be confusing for developers using both services.

---

💡 Proposed Solution

• Introduce a new parameter scope to control visibility.
• scope can accept either a string ("private", "public", "both") or an Enum (Scope.PRIVATE, Scope.PUBLIC, Scope.BOTH).
• Keep the old private=True/False parameter for backward compatibility.
• Return values:
  • "private" or "public" → list of names
  • "both" → tuple (private_list, public_list)

Benefit: consistent API for subsets and views, clear visibility control, flexible and extensible.

---

📝 Example Usage

# Subsets
subsets.get_all_names("Account", scope="private")   # list
subsets.get_all_names("Account", scope="both")      # tuple

# Views
views.get_all_names("SalesCube", scope="public")    # list
views.get_all_names("SalesCube", scope="both")      # tuple

I look forward to your feedback.

[MariusWirtz]

Totally agree we should harmonize that.

However, in TM1py we have avoided changing the return types of a function depending on the arguments, so far.
Type hints can get messy with conditional return types, and it would introduce some cognitive load.

The ViewService.get_all_names is the outlier. All other get_all_names functions return 1 list.
Over the years, we just keep it this waay for backwards compatability.
Perhaps we can decorate it with a deprecation warning and harmonize it with the next major release in 3.0?

[onefloid]

I thought about this, but I haven't come up with a good solution yet. Ideally, we would deprecate the old tuple return and provide the new option at the same time, so developers can migrate instantly or whenever they are ready to avoid annoying deprecation warnings while still being prepared for the next major release.