operator.outputs does not create an instance of the specific Outputs class, but the generic Outputs one

[rafacanton]

Before submitting the issue

• I have checked for Compatibility issues
• I have searched among the existing issues
• I am using a Python virtual environment

Description of the bug

Identified during the output pin alias issue with extract_field, when you do:

outputs = dpf.operators.dpf.operators.utility.extract_field()

outputs' class is not an instance of OutputsExtractField, but an instance of Outputs, making it impossible to employ the aliases defined through the __getattr__ method.

For Inputs this works fine.

Steps To Reproduce

Using pydpf-core branch maint/update_code_for_261_rcs_alias_on_main and sever branch *_rcs_alias, try to run test_animator_animate, for example.

Which Operating System causes the issue?

Windows, MacOS, Linux

Which DPF/Ansys version are you using?

Ansys 2026 R1

Which Python version causes the issue?

3.11

Installed packages

The official ones in requirements.

[rafacanton]

@PProfizi FYI

[PProfizi]

Seeing a retro-compatibility issue with fixing this (see here for example):

We now correctly use the InputsXXX and OutputsXXX classes of the Python module for each operator.

However, it turns out that for ellipsis pins, this is not a transparent change, as the previous behavior with the generic Outputs class resulted in output pin names without numbers.
This means the change will break scripts using ellipsis output pins (at least) since they now should mention the "1" or "2" in the name in the operator module.

There is no way to fix this without having a breaking change:

• either by switching to the current names as defined in the operator modules
• or by changing the way ellipsis pins are exposed (which is already a TODO) and thus breaking the use of the pin names as defined in the operator modules, but can probably be made to not break scripts using names based on the generic Outputs class behavior.