[FEATURE] Power Grid Meta Data attributes enum

[furqan463]

Fixes #949

Changes proposed in this PR include:

Created AttributeType Enum containing attributes of all PGM components through code_generation. Implemented use of new Enum with backward compatibility.

Checks

• Make sure there's no breaking change.
• Review and Update docs

[mgovers]

Very nice improvement. However, I foresee some breaking changes in the current implementation. Either we need some type deduction overloads or we need to keep some names similar. It's unfortunate but it's the way it is.

[figueroa1395]

Hello @furqan463,

We had some additional discussion, and since this is a very involving PR that touches API, we thought that I'd be good if we had a call with you to smooth the process and help where needed more easily. That is of course if you would like to as well. I have contacted you via email to privately discuss this.

In addition, we have an additional remark: the handling of dtype for the attributes; something that wasn't relevant before for the dataset and component types. We didn't dig into it yet, but given that you are very ahead in this PR, could you take a look at it? If it get's too complicated, we can scope it out, but mypy should be happy about it nevertheless.

[furqan463]

@mgovers @nitbharambe I removed the changes in tests,
However, I'm made a few changes in tests to fix typing errors assuming validation rules and validation errors are for internal use and not an interface.
If otherwise, please let me know.

[furqan463]

Updated examples being affected by changes.

[nitbharambe]

Since @figueroa1395 has dived deeper into this before, let him have a final look too. (Also a 2nd look since its an API change). Added do-not-merge for that reason.

[figueroa1395]

Hello @furqan463,

I just finished the review and left mostly minor remarks. Here are some additional ones:

1. Can you also migrate to AttributeType in all the examples and then re-run the notebooks? That should be the "final" step of the migration.
2. I see that in the docs, there are other places where str" valued attributes can be migrated to AttributeType, such as in native-data-interface.md, data-validator.md`, etc. Can you migrate those as well?
3. Some docstrings, for example in data_types.py have not been updated to AttributeType. Can you double check and update them?
4. Some instances of attributes, for example in data_types.py (quick search for use of "id" shows it) are still using 'str' version in-code. Can you replace them.

For 1. and 2. I would recommend to do on a follow up documentation PR to prevent this one for growing even more as it becomes very hard to review.

For 3. and 4. are needed to complete the PR, but if we accidentally miss some instances that's fine (we can catch them later)... thinking about it, maybe this can also be done in a follow up, since this PR contains all the logic changes, any opinion on this @furqan463?

@nitbharambe @mgovers What do you think about the above suggestions? It'd make it easier but I'm also hesitant because this PR touches API and such.

[furqan463]

For 1. and 2. I would recommend to do on a follow up documentation PR to prevent this one for growing even more as it becomes very hard to review.

I saved the branch with all examples and tests using AttributeType instead of strings for a followup PR.

[furqan463]

For 3. and 4. are needed to complete the PR, but if we accidentally miss some instances that's fine

Updated data_types.py.

[mgovers]

Hello @furqan463,

I just finished the review and left mostly minor remarks. Here are some additional ones:

1. Can you also migrate to `AttributeType` in all the examples and then re-run the notebooks? That should be the "final" step of the migration.

2. I see that in the docs, there are other places where `str" valued attributes can be migrated to `AttributeType`, such as in `native-data-interface.md`, `data-validator.md`, etc. Can you migrate those as well?

3. Some docstrings, for example in `data_types.py` have not been updated to `AttributeType`. Can you double check and update them?

4. Some instances of attributes, for example in `data_types.py` (quick search for use of "id" shows it) are still using 'str' version in-code. Can you replace them.

For 1. and 2. I would recommend to do on a follow up documentation PR to prevent this one for growing even more as it becomes very hard to review.

For 3. and 4. are needed to complete the PR, but if we accidentally miss some instances that's fine (we can catch them later)... thinking about it, maybe this can also be done in a follow up, since this PR contains all the logic changes, any opinion on this @furqan463?

@nitbharambe @mgovers What do you think about the above suggestions? It'd make it easier but I'm also hesitant because this PR touches API and such.

i agree with all you said

[mgovers]

LGTM

[figueroa1395]

@furqan463 Great job once again!

[figueroa1395]

the branch with all examples and tests using AttributeType instead of strings for a followup PR.

One additional remark: @furqan463 this is a reminder for the follow up. Also, since there is some work left to do, let's not close issue #949 yet.

[mgovers]

the branch with all examples and tests using AttributeType instead of strings for a followup PR.

One additional remark: @furqan463 this is a reminder for the follow up. Also, since there is some work left to do, let's not close issue #949 yet.

@figueroa1395 can you please add those to #949 and/or comment on it?

[furqan463]

the branch with all examples and tests using AttributeType instead of strings for a followup PR.

One additional remark: @furqan463 this is a reminder for the follow up. Also, since there is some work left to do, let's not close issue #949 yet.

Yes I'll create a follow up PR. Should I create separate PRs for docs and tests?

[figueroa1395]

the branch with all examples and tests using AttributeType instead of strings for a followup PR.

One additional remark: @furqan463 this is a reminder for the follow up. Also, since there is some work left to do, let's not close issue #949 yet.

Yes I'll create a follow up PR. Should I create separate PRs for docs and tests?

Let's do so indeed. Since we are splitting the effort, let's keep it more organized that way.