You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed in #200 and #207 the SegmentationExtractor class has two functions that duplicated the same functionality. get_traces_dict and get_traces and, as illustrated in the referenced issue, this has lead to problems. Maybe we should follow the strongest dictum in the following sentence of the zen of python
There should be one-- and preferably only one --obvious way to do it.
I am opening this issue to keep track of the discussion of whether we should this and how.
The text was updated successfully, but these errors were encountered:
get_traces_dict -> get_traces_types or get_traces_names, both return a list of names that used to be keys of the dict. This would not return anything for the case where a trace is not set to the extractor.
get_traces(..., name="...") works as-is, but you can now loop over all the traces like
What about the opposite approach of getting rid of the getting traces name and keep the dictionary? That way, everything pertaining traces is in a single namespace in a data structure that makes sense for keeping traces (after all you do require both the name and the trace). In other words, why add an extra method to SegmentationExtractor when the python dictionary already represents the data appropriately? What do you think?
Opening an issue to keep track of this:
As discussed in #200 and #207 the
SegmentationExtractor
class has two functions that duplicated the same functionality.get_traces_dict
andget_traces
and, as illustrated in the referenced issue, this has lead to problems. Maybe we should follow the strongest dictum in the following sentence of the zen of pythonThere should be one-- and preferably only one --obvious way to do it.
I am opening this issue to keep track of the discussion of whether we should this and how.
The text was updated successfully, but these errors were encountered: