Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XML generation and parsing #43

Open
wants to merge 22 commits into
base: master
Choose a base branch
from

Conversation

HUG0-D
Copy link
Contributor

@HUG0-D HUG0-D commented Nov 19, 2024

The overall goal of this PR is to add a profile parser and a profile writer.

To do so, the Base class is extended with 3 main functions:

  • .from_xml(): creates an instance of the class by parsing an xml fragment
  • .updates_from_xml(): updates an instance of the class by parsing an xml fragment
  • .to_xml() : allows to export, for a specified profile, the python object as an etree.Element.

reader.py leverages .from_xml() and .updates_from_xml() to parse different profile (CGMES or custom) to create a dictionary of objects of the form {"mRID": corresponding_python_object}

writer.py exports the python objects to generate the xml Profiles

This PR builds upon the work of #39

…nt. Useful to create a profile reader

Signed-off-by: HUG0-D <[email protected]>
Added ability to add attributes to profile Model header

Signed-off-by: HUG0-D <[email protected]>
Signed-off-by: HUG0-D <[email protected]>
Signed-off-by: HUG0-D <[email protected]>
Signed-off-by: HUG0-D <[email protected]>
…nt subfunction and improve readability

Signed-off-by: HUG0-D <[email protected]>
Signed-off-by: HUG0-D <[email protected]>
Signed-off-by: HUG0-D <[email protected]>
@HUG0-D HUG0-D force-pushed the xml-generation-and-parsing branch from 598b920 to da4ec07 Compare November 25, 2024 08:12
@HUG0-D HUG0-D marked this pull request as ready for review November 25, 2024 08:19
Copy link
Collaborator

@tom-hg57 tom-hg57 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've not yet tried the reader and writer, but I tried the generated classes of the current cimgen master in pycgmes and found some problems - mostly ruff and pyright warnings. pycgmes does a lot of checks.

I solved most of the problems by adding "noqa: E501" etc. to the generated sources (see https://github.com/tom-hg57/pycgmes/tree/try-cimgen-master). But I think there should be better solutions, e.g. using "wrapped_class_comment" in enum_template.mustache.

In test_load_all.py I had to prevent testing Primitive, CIMDatatype, EnumType. It seems these couldn't be instantiated like the other classes. Is this a bug? Or did the t
est the wrong thing trying to instatiate them?

I don't know how to solve the problem with the pyright type test (poetry run scons tests), see https://github.com/tom-hg57/pycgmes/actions/runs/12018172243/job/33502079065. It is caused by "attribute_class": ActivePower etc.

cimgen/languages/modernpython/utils/base.py Outdated Show resolved Hide resolved
Fix attribute_namespace to namespace to be coherant with pycgmes

Signed-off-by: HUG0-D <[email protected]>
@HUG0-D
Copy link
Contributor Author

HUG0-D commented Nov 27, 2024

You are correct wrapped_class_comment shoud be used in enum_template. In the same way wrapped_comment should be implemented for enum instances as it is not the case currently in cimgen.py

Concerning your test in test_load_all.py, it tries to instantiate all classes in resource folder. However, classes generated with primitive_template.mustache, dataclass_template.mustache and enum_template.mustache cannot be instantiated.
One of the goals of the previous PR was to avoid creating classes that are then never instantiated.

  • Classes such as Integer or Float are therefore instances of the class Primitive.
  • Datatype classes such as CurrentFlow are instances of the class CIMDatatype. Theses classes provide information on a value (unit, multiplier, ...).
  • Enum classes such as UnitSymbol cannot be instantiated either.

To test these classes the best way is to test their attributes directly.

I fixed the pyright type test error by setting the attribute_class to the name of the class instead of the object itself.
It will make it less straightforward to retrieve the unit, multipler or type of the attribute_class but fixes the issue and simplifies the class_template.mustache

@HUG0-D HUG0-D requested a review from tom-hg57 November 29, 2024 07:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants