Undo DecimalFloatValueModelElement constants moving outside of class

[landauermax]

The constants of the DecimalFloatValueModelElement were moved outside of the class in the development branch. This causes that existing parsers are not working anymore, in particular, parsing elements like DecimalFloatValueModelElement('float44', value_sign_type=DecimalFloatValueModelElement.SIGN_TYPE_OPTIONAL). I do not think there is any good reason why this happened; the constants have to be accessible from outside and we should avoid having to change all existing parsers (this would also affect the parser generator).

The error is AttributeError: type object 'DecimalFloatValueModelElement' has no attribute 'SIGN_TYPE_OPTIONAL'. The tests should include checks so that this error is noted if the constants are moved again in the future.

[ernstleierzopf]

Constants belong on a module level, not in every class instance. This change was proposed while rewriting the unittests.
The constants need to be imported like the DecimalFloatValueModelElement and then can be used with DecimalFloatValueModelElement('float44', value_sign_type=SIGN_TYPE_OPTIONAL). This is much shorter and better to use.

Also in PR #627 the same is implemented for the DecimalIntegerValueModelElement.

[ernstleierzopf]

However I can adapt all other projects and open pull requests for these changes.

[landauermax]

I am not sure this is a better solution. When writing a parser with both integers and floats, the constants will clash:

from aminer.parsing.DecimalIntegerValueModelElement import DecimalIntegerValueModelElement, SIGN_TYPE_NONE, PAD_TYPE_NONE
from aminer.parsing.DecimalFloatValueModelElement import DecimalFloatValueModelElement, SIGN_TYPE_NONE, PAD_TYPE_NONE

It will be necessary to import them under another name, which will be likely not consistent across parser models.

[ernstleierzopf]

You are right. We need to find another solution.
These strings are in both classes the same. I think it would make sense to change both of these classes as the DecimalIntegerValueModelElement basically performs the same task as the DecimalFloatValueModelElement, which does even more.
Would it make sense to completely review both of these classes and maybe merge them?
I think of the class DecimalValueModelElement. It would have an boolean parameter to decide if float values are allowed and another parameter which decides if exponent values are allowed.

What do you think of it?

[landauermax]

For now, please put the constants of the float element back inside the class. I agree that constants should not be there, but right now there is no other solution that does not break way too many things - integer elements are rather common in many parsers, including parsers that are not in the public repository but were made for specific projects, which cannot simply be changed and will not work anymore after this update. Also the parser generator differentiates between integers and floats and needs a somewhat big update after this change. Due to all these incompatibilities that would be introduced we should wait for the next major version release of the aminer (i.e., v3.0.0) for such refactorings. Since it is not at all security or functionality relevant and only concerns coding style, it should be okay to wait.

[ernstleierzopf]

okay. I will open a new issue for this.