Replace 2nd parameter of callback functions by a traversal attribute?

[HeWeMel]

Currently, each NextVertices and NextEdges function needs to have a second parameter to receive the current traversal state from NoGraphs when the callback function is called by NoGraphs to get the next vertices or edges for a vertex. But is is needed only for search-aware graphs, a special case.

NoGraphs could also provide access to the state 'at the time of the callback' by some attribute, instead of the parameter.

[HeWeMel]

Pro: With just one parameter, the callback functions would be more intuitive

[HeWeMel]

Pro: The second parameter disturbs caching, e.g. with @functools.cache

[HeWeMel]

Contra: It is intuitive to get some state, that is valid when the callback happens, as parameter of the callback function. It is less intuitive to get it from a special attribute of the traversal object that represents the state of the traversal when results are reported.

[HeWeMel]

Contra: Future extensions of NoGraphs with features of parallelism are easier to handle with the current approach of a parameter, because then, several states 'when the callback happens' can occur in parallel.

[leshabirukov]

Can user attach his own data to it?

[HeWeMel]

NoGraphs does not guarantee that application code can attach additional attributes to a traversal object. Currently, this might be possible, but in the future, e.g., in a compiled version of NoGraphs (extension module), this might not be possible anymore.

And it is not very helpful to do so - not now, and not with the proposed change:

1. The application code, that starts a traversal run and receives reported vertices, can store data whereever it likes. It is not needed or in any way better to store something just in this object.

2. And in a callback function:

   a) Currently, the offered traversal object can even be another object each time a callback happens. Thus, storing something there does not make sense.

   b) With the proposed change, there would be a guarantee that for each call of the callback function, the traversal object that provides access to the traversal state would be the same object. But still, storing data to it would not be very useful: In order to access the traversal object within the callback function, the function would need to be defined as closure, because only the application that defines the callback function has the possibility to get the traversal object from the library. And then, arbitrary objects of this scope could be accessed and used to store data in them, not only this traversal object.

(If you like to get further information about how an application can handle some kind of state (independently of the change proposed above), please post this as separate question to the Q&A.)

[leshabirukov]

Well, I think, changing API needs more serious reasons at least for now. This parameter confuses me a little at first, but later it was useful for debugging. Me be, it coud be useful for something like https://en.wikipedia.org/wiki/Alpha-beta_pruning