Author tim.peters
Recipients Zahari.Dim, belopolsky, christian.heimes, eric.smith, gaborjbernat,, lukasz.langa, martin.panter, orsenthil, pablogsal, remi.lapeyre, rhettinger, terry.reedy, tim.peters, tshepang, vstinner, wim.glenn
Date 2020-04-02.22:20:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Possibly, sure.  But I believe it's hard to beat

    add(node, *predecessors)

for usability as a way to build the dependency graph.  For example, a list of pairs is a comparative PITA for most use cases I've had.  Whether it's following a recipe to bake a cake, or tracing a maze of C include files, it seems _most_ natural to get input in the form "this thing depends on these other things".  Not the other way around, and neither a sequence of pairs.

_If_ you buy that, then .add() is screamingly natural, and trying to squash a pile of .add()s into a single sequence-of-sequences argument seems strained.

Typically I don't get input in one big, single gulp.  It's instead discovered one item at a time.  Fine - .add() it and then move on to the next item.  It's certainly possible to append the item and its predecessors to a persistent (across items) list, and call a function once at the end with that list.

But what does that buy?  I'm building the list solely to meet the function's input requirement - the list serves no other purpose.  Instead of calling .add() N times, I call .append() N times.  "add" is 3 letters shorter ;-)
Date User Action Args
2020-04-02 22:20:47tim.peterssetrecipients: + tim.peters, rhettinger, terry.reedy, belopolsky, orsenthil, vstinner, eric.smith, christian.heimes, lukasz.langa, tshepang,, martin.panter, wim.glenn, Zahari.Dim, pablogsal, remi.lapeyre, gaborjbernat
2020-04-02 22:20:46tim.peterssetmessageid: <>
2020-04-02 22:20:46tim.peterslinkissue17005 messages
2020-04-02 22:20:46tim.peterscreate