Linting and Formatting: adding Pylint checks to Ruff

[Laurynas-Jagutis]

This implementation is based on a version of the repository before moving to Ruff, which can be accessed here:
https://github.com/PowerGridModel/power-grid-model/tree/c127b2cf42ff179fe985f91688e10a7cf2671a90

As per the previous implementation, Pylint only ran on src files, thus I tried to mimic the behavior:
https://github.com/PowerGridModel/power-grid-model/blob/c127b2cf42ff179fe985f91688e10a7cf2671a90/.pre-commit-config.yaml

Most of the noqa comments alligned with the pylint version:
https://github.com/PowerGridModel/power-grid-model/blob/c127b2cf42ff179fe985f91688e10a7cf2671a90/src/power_grid_model/validation/_rules.py

Most misalignments happened in src/power_grid_model/_core/power_grid_model.py, where the old pylint version did not have comments but now there was a need for them. A possible explanation could be: pylint-dev/pylint#8667

[figueroa1395]

Maybe a better name would be something explicitly suggesting 2d? and then in line 192, use the same name but with 1d explicit instead of ... else 1? I don't know of an exact name, but reflecting the value in it would be nice.

[Laurynas-Jagutis]

For now I still kept batch_ndim = 2, but I have added singular_ndim = 1.
If you think that for example these would be more clear:
batch_2dim = 2 and singular_1dim = 1 I could edit them

[figueroa1395]

Similar to above, maybe we can have some "globals" indicating the dimension of batch data, regular data, etc. I imagine these magic numbers (1, 2, 3) referring to the possible dimensions are spread in many places.

If in the end batch_dim = 2 is just clear, let's define it that way then and put in somewhere. And then come with something for the other two.

Also, what does the return 1 below mean?

[mgovers]

as you may see in this PR, even giving magic values a localized name does not necessarily make the code nicer. However, it does highlight the underlying design issues, and provides a way out and a first step towards refactoring the code in the future.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[mgovers]

This is both not descriptive enough and also not correct. This is exactly why you should be very careful with magic values. I myself did not understand what it was about until I dug more deeply into this.

1. 3 is NOT a supported amount of dimensions, UNLESS a very specific case. Therefore, supported_dim is not a good name.
2. Only 1-dimensional and 2-dimensional datastructures are supported. There is only 1 exception and that is when we're dealing with asymmetric values in dense batch attribute data, in which case you have 3 dimensions and the last dimension contains exactly 3 values
3. This also means that if statement is incorrect (i.e. we found a bug)

Here's my proposal:

Suggested change

	supported_dim = 3
	if schema.dtype[attribute].shape == (supported_dim,) and data.shape[-1] != supported_dim:
	dense_batch_ndim = 2
	dense_batch_asym_attr_ndim = dense_batch_ndim + 1
	n_asym_values = 3
	shape = schema.dtype[attribute].shape
	if len(shape) > batch_ndim and not (len(shape) == dense_batch_asym_attr_ndim and shape[-1] != n_asym_values):

you can also invert the if statement:

    dense_batch_ndim = 2
    dense_batch_asym_attr_ndim = dense_batch_ndim + 1
    n_asym_values = 3
    shape = schema.dtype[attribute].shape
    if len(shape) <= batch_ndim or (len(shape) == dense_batch_asym_attr_ndim and shape[-1] != n_asym_values):
        return _get_raw_data_view(data, dtype=schema.dtype[attribute].base)
    raise ValueError("Given data has a different schema than supported.")

Please do this fix in a separate PR off main together with a unit test that tries to trigger the issue from the lowest-level public function that calls this function (i.e., get_buffer_view).

I recommend first creating the unit tests (don't forget to commit when if fails correctly) and then applying the fix

[mgovers]

not a fan of the name SINGULAR. Maybe something like SINGLE_DATASET_NDIM (and BATCH_DATASET_NDIM, resp.)?

[mgovers]

creating this on a global level doesn't make sense. In fact, all amount of dimensions above BATCH_NDIM (or below 0, for all that matters) are unsupported and it is very prone to bugs (as is shown in my other comment).

[mgovers]

this seems like a bug to me

Suggested change

	if sym_array.ndim == UNSUPPORTED_NDIM:
	if sym_array.ndim > BATCH_NDIM:

or (but please double-check whether ndim == 0 is supported, or we may just introduce a new bug)

Suggested change

	if sym_array.ndim == UNSUPPORTED_NDIM:
	if sym_array.ndim not in (SINGULAR_NDIM, BATCH_NDIM):