Проблема со списком Python для сложных типов

Question

Ниже приведен фрагмент кода в Python, который хранит префиксы IP в основополагающем дереве, а затем связывает IP и ASN в словаре, если IP принадлежит префиксу.

Я хотел бы узнать все различные ASN для конкретного префикса. Более подробная информация представлена ​​ниже:

#rtree is a radix tree which has prefixes stored.
rtree = radix.Radix()    
with open(path-to-prefix-file,'r') as fp:
    for line in fp:
        rnode = rtree.add(line)  # Eg, Prefixes like "192.168.2.0/24"
        rnode.data["count"]= 0
...        
# The code has several lines here for processing a capnproto - skipping them.

rnode.data[IP]=asn_complete  # I read a Capnproto buffer and store IP and asn_complete

...

for rnode in rtree:
    seen_list = []  # defining a list to store different val, i.e.,asn_complete values
    if rnode.data["count"] > 1:
            """  Iterate through the rnode.data dictionary """
            for ip,val in rnode.data.iteritems():
                    if val not in seen_list:  # Condition is always satisfied!!
                            seen_list.append(val) 

Например: val имеет следующее значение из protobuf в несколько итераций:

[<capnp list reader [15169]>, <capnp list reader [1239]>, <capnp list reader [4837]>]

Когда я распечатаю seen_list:

[[<capnp list reader [15169]>, <capnp list reader [1239]>, <capnp list reader [4837]>], [<capnp list reader [15169]>, <capnp list reader [1239]>, <capnp list reader [4837]>], [<capnp list reader [15169]>, <capnp list reader [1239]>, <capnp list reader [4837]>],....]

очевидно val в seen_list; но, if val not in seen_list: всегда верно и val добавляется к seen_list так много раз. Я не понимаю, почему условие всегда возвращает истину. Это из-за типа объекта, хранящегося в seen_list?

Answer 1

В настоящее время читатели Cap'n Proto не поддерживают какого-либо сравнения "равенства". Отчасти это объясняется тем, что неясно, что должно означать равенство: должно ли оно быть идентичным (два читателя равны, если они указывают на один и тот же объект) или оно должно быть по значению (они равны, если они указывают на объекты с эквивалентным содержанием)?

В любом случае, in требует реализации __eq__ для проверки на равенство, и в случае с Cap'n Proto такой реализации нет. Вероятно, в конечном итоге происходит то, что Python сравнивает объекты-оболочки по идентичности - и, поскольку новые объекты-оболочки продолжают создаваться, эти сравнения всегда ложны.

Чтобы получить то, что вы хотите, вам, вероятно, потребуется полностью преобразовать объекты Cap'n Proto в простые объекты Python, которые должным образом сопоставимы.