[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Larry Hastings added the comment: One final aside. Let me preface this by saying: I'm not proposing the following for graphlib.TopologicalSort. It's obviously too late to change that object this much. It's just something I'm thinking about--maybe I'll use this in my own library. Where

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Larry Hastings added the comment: I agree that the API should have as few surprises as possible. AFAICT you haven't made any terminal pronouncements like "it's impossible to add this feature without too many unacceptable surprises", so I'll proceed assuming we can find an API (and

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Tim Peters added the comment: I believe I'm elaborating on your "footgun". It doesn't matter to me whether we pick some scheme and document it, _if_ that scheme is incoherent, impossible to remember, error-prone, etc. That's how, e.g., regular expression syntax was designed. "I know!

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Larry Hastings added the comment: I'm not sure I follow you. What do you suggest graphlib is guessing at? I thought we were discussing what graphlib's (documented, intentional) behavior should be; if there was any guessing going on, it was us doing it, guessing at what behavior the user

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Tim Peters added the comment: Various kinds of tasks: - "Power switch must be on." Needs to done the first time. _May_ need to be done again later (if some later task turns the power off again). Can be done any number of times without harm (beyond the expense of checking), so long as the

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Larry Hastings added the comment: Having slept on it, I think the footgun is slightly bigger than I gave it credit for. Also the problem of nodes lingering forever is easily solved: give the user control. My next iteration will keep the done nodes around, but I'll also add a forget()

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Larry Hastings added the comment: > Assuming we do want to be able to add() after a get_ready(), is there > a reason that "forgetting" already-produced nodes is the correct > behavior, as opposed to remembering all nodes ever added, and > raising iff the addition creates a cycle among all

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Larry Hastings added the comment: I'm using my graph library to manage a list of tasks that need doing in some sort of proper order. One task may spawn other tasks at runtime, and we don't necessarily know what the tasks will be until runtime. It's way more convenient to simply add such

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Dennis Sweeney added the comment: > depends on an already-yielded node I mean "creates a new not-yet-yielded dependency for an already-yielded node". -- ___ Python tracker

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Dennis Sweeney added the comment: Out of curiosity, what are the use cases for adding nodes after get_ready has already produced nodes? I was wondering about avoiding the need to call prepare() by having it automatically do the cycle-checking at the first get_ready() call and then raising

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Eric V. Smith added the comment: My personal usage of a topological sort are restricted to maybe 100 entries max, so I can't really test this in any meaningful way. That, and the project that uses it is stuck on 3.6, so I haven't switched to the graphlib version yet. --

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

New submission from Larry Hastings : I've maintained my own topological sort class for a while now. The API I came up with (or was it Tim and I?) was adopted for graphlib.TopologicalSort(). Some of my method names are slightly different, but the APIs are so similar, I can do a little