This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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