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

chore(lower-case): read and write cluster and bc groups in lower case #2283

Open
wants to merge 15 commits into
base: dev
Choose a base branch
from

Conversation

MartinBelthle
Copy link
Contributor

No description provided.

@MartinBelthle MartinBelthle self-assigned this Jan 6, 2025
@MartinBelthle MartinBelthle changed the title chore(lower-case): read and write cluster names and groups in lower case chore(lower-case): read and write cluster and bc groups in lower case Jan 8, 2025
@MartinBelthle MartinBelthle marked this pull request as ready for review January 8, 2025 14:01
@MartinBelthle MartinBelthle requested a review from sylvlecl January 8, 2025 14:06
Copy link
Member

@sylvlecl sylvlecl left a comment

Choose a reason for hiding this comment

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

A few comments: for the low level parsing, I think we should have a more configurable method, in particular so that we can re-use it later for the "int to string" issue, but also to have a better separation of concerns: the parsing function should not know by itself how to parse particular fields, it shuld be an argument of the function.

antarest/study/web/study_data_blueprint.py Outdated Show resolved Hide resolved
if depth <= -1 and expanded:
return output

# We need to lower the group attribute and the cluster ids
Copy link
Member

@sylvlecl sylvlecl Jan 16, 2025

Choose a reason for hiding this comment

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

Here we inject some knowledge (group should be lowercase) about specific subclasses of this class, it's not a very good separation of responsibilities.

A better design would be to specify as arguments of the method how stuff should be read or written.
For example, we could have a dict:

parsing_methods = {
    (None, "group"): lambda value: str(value).lower()
}

Meaning that all values associated to any key at the 1st level (None) and "group" key at the 2nd level should use the provided parsing method.

Actually this should probably be something we provide to he ini reader.

This would allow, in the future, to also fix how we parse integers, because we will be able to specify that we want to parse them as strings, instead of letting the reader try to guess the type.

output = str(output).lower()
return output

def save_lowered_content(self, data: SUB_JSON, url: t.List[str]) -> None:
Copy link
Member

Choose a reason for hiding this comment

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

same comments, we could provide the serializers as arguments

Copy link
Contributor Author

@MartinBelthle MartinBelthle Jan 17, 2025

Choose a reason for hiding this comment

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

I agree with you for the get.
But IMO the only save we'll ever need is this one and it's already generic.
So I think i should just rename the method and change the comments i wrote inside but keep the code as it is.
I'll also have to call the get with the right parsing method.
I'll commit this change and you can give me your opinion on it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants