Create a VersionChild datatype

[gerw]

This works towards #122.

In calculations.py we have an exceptional handling for the fields 81-90, since these ten fields contain the version information. Positions 82-90 were uninhabited; with this patch, a new VersionChild sits there and gobbles the value for its parent.

A new flag datatype_internal indicates, that this datatype is only internal and the iterator of Calculations will skip this entry.

[gerw]

pylint complains here. Is this the correct way to overwrite the getter of value in the Base class?

[kbabioch]

• Does this datatype no longer have a name (ID_WEB_SoftStand)?
• I totally get that the handling of this datatype was not particularly nice and iterating over it was generating confusing results. While this fixes it, the definition doesn't look super handy. Couldn't we address this in the iterator itself somehow by indicating the length of each datatype, rather than specifying an internal flag 10 times iteratively?

[gerw]

• The name is unchanged, it is defined in Line 43.
• The version datatype is the only one with a length bigger than 1. Thus, it was more reasonable to me to handle it as an exceptional case by introducing the "sub"-datatype.
• To which "iterator" are you referring to?

[kbabioch]

The name is unchanged, it is defined in Line 43.

Ah, somehow missed that on first glance, sorry for that.

The version datatype is the only one with a length bigger than 1. Thus, it was more reasonable to me to handle it as an exceptional case by introducing the "sub"-datatype.

Depending on how we're going to tackle #33, we might have other datatypes with length > 1, also.

Personally I would prefer some kind of length attribute (with the default being 1), compared to this approach.

To which "iterator" are you referring to?

In the description of this pull request you were referring to the iterator. I suppose you mean the __iter__ method of Calculations. Haven't checked this in close detail yet, probably it didn't need to skip anything before, since the values have not been considered for iteration in the first place.

[gerw]

Concerning #33: In my opinion, the data there has length one (each time sits in one slot). The overall handling of the data there should be (in my opinion) handled in a higher-level way in the sense of #119.

[kbabioch]

There seem to be two issues with pylint (as already noted).

 luxtronik/datatypes.py:354:4: W0236: Method 'value' was expected to be 'property', found it instead as 'method' (invalid-overridden-method)
************* Module tests.test_datatypes
tests/test_datatypes.py:713:15: W0143: Comparing against a callable, did you omit the parenthesis? (comparison-with-callable)

[kbabioch]

Other input from @Bouni et al. might also be welcome ;-).

[gerw]

There seem to be two issues with pylint (as already noted).

 luxtronik/datatypes.py:354:4: W0236: Method 'value' was expected to be 'property', found it instead as 'method' (invalid-overridden-method)
************* Module tests.test_datatypes
tests/test_datatypes.py:713:15: W0143: Comparing against a callable, did you omit the parenthesis? (comparison-with-callable)

Yes, but I do not understand how to fix it.

[gerw]

I realized another possibility which seems to (almost) remove the exceptional handling:

• We introduce a new datatype character which just converts 1 raw value in the corresponding character.
• Parameters 81-90 get this new datatype (and they will store one character of the version string)
• The version string is provided by the new higher-level interface from Provide high level interface #119

[Bouni]

@gerw That seems like the right way to solve this to me 👍🏽

[kbabioch]

I realized another possibility which seems to (almost) remove the exceptional handling:

• We introduce a new datatype character which just converts 1 raw value in the corresponding character.
• Parameters 81-90 get this new datatype (and they will store one character of the version string)
• The version string is provided by the new higher-level interface from Provide high level interface #119

That sounds also more "keep it simple"-like to me and introduces less complexity in the interpretation of the raw data by the current datatypes.

So I would definitely prefer that.

[gerw]

@Bouni @kbabioch Done.

[kbabioch]

Perfect, looks good to me.