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

Improve the parameter_info() function #348

Merged
merged 3 commits into from
Sep 25, 2024

Conversation

andlaus
Copy link
Collaborator

@andlaus andlaus commented Sep 24, 2024

It now knows about system parameters, SCALE-LINEAR, RAT-FUNC and SCALE-RAT-FUNC and COMPU-CODE parameters. Also, the code is a bit easier to read and contains a few smaller drive-by fixes.

this is a spin-off of #347 and thus build on top of that PR.

Andreas Lauser <[email protected]>, on behalf of MBition GmbH.
Provider Information

It now knows about system parameters, `SCALE-LINEAR`, `RAT-FUNC` and
`SCALE-RAT-FUNC` and `COMPU-CODE` parameters.

Signed-off-by: Andreas Lauser <[email protected]>
Signed-off-by: Gerrit Ecke <[email protected]>
return "<unknown type>"


def _get_linear_segment_info(segment: LinearSegment) -> str:
Copy link
Collaborator

Choose a reason for hiding this comment

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

I have a feeling this should be in the __str__ or __repr__ function of LinearSegment

Copy link
Collaborator Author

@andlaus andlaus Sep 25, 2024

Choose a reason for hiding this comment

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

I don't think that LinearSegment and RationalSegment objects should be printed under normal circumstances, and if they are, usually something like the slope and the offset are desired? (IMO this is not the case in the context of parameter_info() were we are only interested in what ranges can be specified for a given parameter. Opinions welcome...)

Copy link
Collaborator

Choose a reason for hiding this comment

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

The idea is that the function that describes the object is human readable way, should be in the object itself, even if it's just for the sake of showing better values in the debugger.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yes. my main point is that in most contexts other than parameter_info(), this probably requires a bit more information than just the domain where the segment is defined (i.e., some info what the segment does)...

odxtools/parameterinfo.py Outdated Show resolved Hide resolved
this method returns what the `DataType` object would be on the python
side. as [at]kayoub5 points out, this is probably what is wanted 90%
of the time such an object is printed. Also, this can now be directly
used by `parameter_info()`.

thanks to [at]kayoub5 for the insistence.

Signed-off-by: Andreas Lauser <[email protected]>
Signed-off-by: Gerrit Ecke <[email protected]>
odxtools/odxtypes.py Outdated Show resolved Hide resolved
odxtools/odxtypes.py Outdated Show resolved Hide resolved
thanks to [at]kayoub5 for pointing this out.

Signed-off-by: Andreas Lauser <[email protected]>
Signed-off-by: Gerrit Ecke <[email protected]>
@andlaus andlaus merged commit 769dae3 into mercedes-benz:main Sep 25, 2024
7 checks passed
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