Tim Peters <t...@python.org> added the comment:
Raymond, what application do you have that wouldn't be completely addressed by sticking to just .add() (to record dependencies) and .static_order() (to retrieve a linear order)? Larry Hastings and I originally worked out the fancier bits of the interface to deal with problems he actually had, and for which no existing Python topsort implementation we could find was of any use: extract maximal parallelism. If you don't want that, fine, stick to the two simple bits. The bits to support parallelism are very easy to use to write correct parallelized code, but of course can seem baffling if you don't give a rip about parallelism. But in that case you have no need to learn about them either. If your alternative isn't equally easy to use in a parallelized context, I'll be at best +0. About "fast", this is linear time, in the sum of the number of items and dependencies. Including the part checking for a cycle, which is by far the "hardest" part. So it's asymptotically optimal, although I've never seen a real context in which topsort speed made a lick of difference. In the real world, in a parallelized context it can be important to check for a cycle _before_ running a topsort: actions are performed ASAP based on order-deduced-so-far, and it can be no good to find out "oh! I can't finish this" at the end. There's actually nothing gratuitous here. If it seems "over-engineered", that's because it's addressing problems you haven't had yet ;-) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue17005> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
