SignalEntry with csv file + refactorings

[Saskia-K]

new

• added option to read & write signal entries with csv files
• changed writing of binary signal entries to match the reading

changed

• moved channel naming and data type inference to separate methods
• simplified _get_index and Entry.add_entry, CustomAttributes.to_element
  -> caution: stacked entries will still be removed only partially with remove_entry()
• separated remove_entry method for unisens class
• restricted read_unisens to internal use
• fixed writability of attrib when passed at initialization
• setting kwargs always with set_attrib independent of passing to init or set_data
• removed cause for _autosave exception: always have a _parent attribute (even when copying)
• removed unreachable code and removed 'return True' where raising exceptions instead of returning False
• refactored paths: no addition of strings, using os.path...
• many minor additions in formatting, typing, comments and docstrings

[skjerns]

(not sure if @jottenbacher actively reads github, maybe you want to shoot him an email instead referencing this PR)

[Saskia-K]

Updated description of changes:

new

• added option to read & write SignalEntry with csv file

changed

• moved channel naming and data type inference to separate methods
• simplified Entry._get_index() and Entry.add_entry(), CustomAttributes.to_element()
  -> caution: stacked entries will still be removed only partially with Entry.remove_entry()
• separate remove_entry method for Unisens class
• fixed writability of attrib when passed at initialization
• setting kwargs always with set_attrib independent of passing to __init__ or set_data
• removed cause for exception in Entry._autosave(): always have a _parent attribute (even when copying)
• removed unreachable code and removed 'return True' where raising exceptions instead of returning False
• refactored paths: no addition of strings, using os.path...
• many minor additions in formatting, typing, comments and docstrings

deprecated

• read_unisens: will be restricted to internal use
• SignalEntry.get_data() default value for argument scaled: will change from True to False, matching Java implementations SignalEntry.read() and SignalEntry.readScaled()
• SignalEntry.get_data() argument return_type: argument is unused and will be removed
• Entry subclass CustomAttribute: no use since it doesn't match CustomAttributes.add_entry(); usable alternative is CustomAttributes.set_attrib()

[Saskia-K]

Updates to the last description of changes:

new

• added option to read & write SignalEntry with csv file

changed

• moved channel naming and data type inference to separate methods
• simplified Entry._get_index() and Entry.add_entry(), CustomAttributes.to_element()
  -> caution: stacked entries will still be removed only partially with Entry.remove_entry()
• separate remove_entry method for Unisens class
• fixed writability of attrib when passed at initialization
• setting kwargs always with set_attrib independent of passing to __init__ or set_data
• removed cause for exception in Entry._autosave(): always have a _parent attribute (even when copying)
• removed unreachable code and removed 'return True' where raising exceptions instead of returning False
• refactored paths: no addition of strings, using os.path...
• many minor additions in formatting, typing, comments and docstrings

deprecated

• read_unisens: will be restricted to internal use
• SignalEntry.get_data() default value for argument scaled: will change from True to False, matching Java implementations SignalEntry.read() and SignalEntry.readScaled()
• SignalEntry.get_data() argument return_type: argument is unused and will be removed
• Entry subclass CustomAttribute: no use since it doesn't match CustomAttributes.add_entry(); usable alternative is CustomAttributes.set_attrib()
• SignalEntry / ValuesEntry.set_data() will require channel names (deprecating the automatic naming). They can be supplied by passing the argument ch_names or by copying and passing the channel attribute from another entry. In the future, channels will be used to verify data orientation.

[Saskia-K]

@skjerns would you please add me as collaborator for the corresponding PyPI project or upload the new release yourself?

[skjerns]

sure, what's your username there?

also saskia-k?

[skjerns]

Might make sense to create a GitHub action for automatic wheel upload on release creation

e.g. using https://github.com/pypa/cibuildwheel

[Saskia-K]

Yes, my PyPI user name is Saskia-K too.
For the extensive version of an automatic upload, I currently don't have the capacity. I can set up a basic actions script though.

[skjerns]

Perfect, then I added the right Saskia-K. Let me know if there's anything else I can do.

[Saskia-K]

Sorry for the late reply. Shouldn't I have received an email or anything for the PyPI access? This is my account: https://pypi.org/user/Saskia-K/

[skjerns]

I think the invite expired. Try again

[Saskia-K]

Merci beaucoup :)

[Saskia-K]

Sorry, to bother you again. Do you have access to Settings / Security / Secrets and variables ? The actions workflow would need an API token (secrets.PYPI_API_TOKEN) which I don't have the rights to insert.

[skjerns]

Nope, @jottenbacher needs to do that or give you full repo admin rights.

[Saskia-K]

@mkirst just added my token for us. So we can test the workflow with the next release. I uploaded version 1.5.0 manually yesterday.