Incorrect implementation

[wncka]

118:    if neighbor.out_openset:
            neighbor.out_openset = False
            heappush(openSet, neighbor)
        else:
            # re-add the node in order to re-sort the heap
            openSet.remove(neighbor)
            heappush(openSet, neighbor)

The problem occurs inside the else branch. Remove and heappush may not re-sort the heap completely. The heap is a complete binary tree, the value of the parent node must be less(or greater) than or equal to the child node, so remove operation will destroy the structure of the heap. Heappush will only fix one path(from a leaf node to root), other problematic paths will not be fixed。

I wrote a unit test to reproduce the problem。
heap_unit_test.txt

[wncka]

You can look at the interface reality of heapq, such as heappush, heappop. After modifying the structure of the list, heap must use _siftdown or _siftup to maintain the structure. Modify the heap directly using the list interface(append, remove, pop) may cause bugs, because you can't guarantee that the heap structure is correct, unless you use heapify interface to rebuild heap completely.

The problem with using heapify is that it is very inefficient. The time complexity of heappush, heappop is O(log2N), but heapify is O(N). I think there are two ways to solve the problem:
(1) heappush the better neighbor node again, because of closed flag, we will only deal with the best case once. But it means a node will appear multiple times in the heap, which may cause the heap to bloat very quickly.
(2) Use another data structure, such as set(C++ implementation) replace of heap. Binary balanced tree(AVL) will work well. It guarantees the time complexity of find_min(find_max),add_item,remove_item is O(log2N).

[jrialland]

Thank you for your inputs, I think it is fixed now

• I allowed the use of the sortedcontainers module as an alternative ( https://grantjenks.com/docs/sortedcontainers/sortedlist.html )

• I continue to support the use of heapq, but now I properly run heapify after a remove operation (slow but correct)