Split ChannelList into a ChannelTuple and a ChannelList

[jenshnielsen]

This creates a cleaner interface where the ChannelTuple does not contain modifying methods (which would just raise)

• ChannelList now implementes the full MutableSequece ABC
• All drivers that used lock have been updated to convert the channellist to a channeltuple
• Instrument and station has been updated to allow channeltuples.
• Code coverage of ChannelList/Tuple has been improved to almost 100 %

One could significantly cleanup the code by removing the whole lock functionality but that will need to be left till
the things has been deprecated for a while.

Question? Should we get rid of the whole _channels being a tuple or a list. That would significantly simplify the typing and remove the need for casting in the list implementation.

• Update drivers as possible. Any driver that does not modify its channellists should probably use ChannelTuple
• remove locking logic leftover from channeltuple
• Fix update of channelmapping
• Update tests to cover this. Let the DummyChannelInstrument use a ChannelTuple and rewrite test that modifies channellist to use a channellist. Cover new methods added, ensure that channelmapping logic is covered
• Fix znb driver that modifies internal state of the ChannelList
• Update docs
  Possible future improvements
• Deprecate lock ? Probably not yet. We should first update contrib drivers
• Can we make this more generic so myinstr.chanels is a ChannelTuple[Mychanneltype]

[codecov]

Codecov Report

Merging #3851 (a513359) into master (cb9184b) will increase coverage by 0.14%.
The diff coverage is 81.13%.

@@            Coverage Diff             @@
##           master    #3851      +/-   ##
==========================================
+ Coverage   65.66%   65.80%   +0.14%     
==========================================
  Files         228      228              
  Lines       31055    31056       +1     
==========================================
+ Hits        20392    20437      +45     
+ Misses      10663    10619      -44     

[astafan8]

Question? Should we get rid of the whole _channels being a tuple or a list. That would significantly simplify the typing and remove the need for casting in the list implementation.

as discussed offline, making _channels a list will make things easier. getting rid of it, i think, is possible, but then _channel_mapping becomes THE underlying structure, and i doubt that this will result in a better code. in fact, perhaps removing the _channel_mapping and generating it only when needed, could improve the code, but also might not

Deprecate lock ? Probably not yet. We should first update contrib drivers

agree. first update contrib drivers, but then, yes, deprecate the lock

Can we make this more generic so myinstr.chanels is a ChannelTuple[Mychanneltype]

i think this should be possible. _chan_type needs to become a type alias bound to InstrumentChannel and used in all the signatures. can be attempted in a separate PR :)

[astafan8]

bors merge

[bors]

🕐 Waiting for PR status (Github check) to be set, probably by CI. Bors will automatically try to run when all required PR statuses are set.

[bors]

Build succeeded:

• builddocs (ubuntu-latest, 3.10)
• builddocs (ubuntu-latest, 3.9)
• builddocs (windows-latest, 3.7)
• pytestconda (ubuntu-latest)
• pytestconda (windows-latest)
• pytestmin (ubuntu-latest, 3.7)
• pytestmypy (ubuntu-latest, 3.10)
• pytestmypy (ubuntu-latest, 3.7)
• pytestmypy (ubuntu-latest, 3.8)
• pytestmypy (ubuntu-latest, 3.9)
• pytestnonlocal (3.7)