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
There was a lively discussion here #155 and elsewhere about the merits of having a __len__ method in Cigar since there are meny possible interpretations of length.
in the same vein, one could argue that there are many interpretations of cigar[i]:
the I-th operator
the i-th cigar-element
the i-th character in the string representation
the offset in the read of the i-th base
the offset in the reference of the i-th base
Since we concluded that having len is a "footgun" and may cause more problems than it's worth, this issue hopes to embody the discussion for and against removing__get_item__ i.e. reverting #154
The text was updated successfully, but these errors were encountered:
I agree that if one can do cigar[i] it can be understood that len(cigar)>i so that imposes a relationship between whatever it is we are counting with i when we use it in cigar[i] and the meaning of len(cigar), i.e. the meaning of __len__().
If we accept vetoing __len__() due to possible confusion with other length-adjacent concepts, it seems reasonable to me to not have __get_item__ thereby forcing the user to access elements explicitly, and also helping the reader understand the code.
There was a lively discussion here #155 and elsewhere about the merits of having a
__len__
method in Cigar since there are meny possible interpretations of length.in the same vein, one could argue that there are many interpretations of cigar[i]:
Since we concluded that having len is a "footgun" and may cause more problems than it's worth, this issue hopes to embody the discussion for and against removing
__get_item__
i.e. reverting #154The text was updated successfully, but these errors were encountered: