Having an "in" operator for ListSource Class

[hhyurdagul]

Hello everyone,

I was utilizing two distinct table objects with the aim of transferring a value from one list to another, ensuring that the second list contained only unique values.

My approach involved using the in operator on ListSource().data (Can not use on table itself because Table does not inherit from Iterator) to verify if the data already existed in the list before adding it. Below is the code for a clearer understanding.

selection = table1.selection # This returns row object
if selection and selection in table2.data:
    table2.append((selection.item,)) 
    # Cannot append row object by itself because it creates a new row object from the given value

The approach is ineffective because table2.data is merely a list of row objects, and checking each row object will always return false unless the checked object is a reference to one of the objects within table2.data. Wouldn't it be more practical to modify the in operator to verify the values within the rows rather than the row objects themselves? (The append function already accepts values rather than row objects; the API would remain consistent with this method as well.)

[freakboy3742]

To be completely honest: I was a little surprised that __contains__ (the dunder method that implements in) wasn't already implemented - my initial mental model of ListSource suggested it would be. However, on thinking about it a little more, it made sense.

The complication is the handling of equality on rows. ListSource requires that __eq__ on a row object is an instance match - i.e., two rows with the same underlying values are not equal from the perspective of the ListSource. Without this, it would be impossible to store two rows with the same value(s).

This is why index and find both exist - index searches by instance; find searches by value. A similar schism will exist for an implementation of in - the implementation that is closest to the native Python list interface will need to be a "membership by instance"; the public that end-users will be looking for is "membership by value".

[hhyurdagul]

I see, the use of find is a must here. Then, what do you think of a change that makes .find() return -1 in the case of failure instead of throwing an error?

Instead of try-catch blocks, isn't the usage of if-else comparison better?

[freakboy3742]

I'm not sure I agree that a -1 is a better return value here.

"-1 on error" is a historical artefact of UNIX APIs. It makes some sense in the index() case because it allows the return value of the method to always be an integer. However, for the find() case, it's returning the actual row instance, so returning -1 wouldn't be anything more than a sentinel. In that case, using an exception allows for a clear distinction between "value" and "no value found"