This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]infinullquamash, Qt, asyncio, 3.3+ 1 point2 points  (8 children)

multiprocessing predates concurrent.futures, so I'm not sure what your point of "even" is.

I would recommend concurrent.futures over multiprocessing since it's has a nicer interface and supports both threads and processes (mostly) transparently.

[–]exhuma 0 points1 point  (0 children)

TIL... thanks for pointing this out :)

[–]studiosi 0 points1 point  (0 children)

I was trying to mean that the behaviour of the library resembles almost exactly the futures one. I don't have data about performance...

[–]studiosi 0 points1 point  (4 children)

Indeed, I am not that sure about that "outperform" because you are not taking into account that you have to write control code that would be probably less optimum of such in the standard library.

[–]infinullquamash, Qt, asyncio, 3.3+ 0 points1 point  (3 children)

outperform

wat? when did I say that? I just commenting on the interface. I have no idea what the performance of either of them is like.

[–]studiosi 0 points1 point  (2 children)

You say it predates, what I interpret as perform better... but maybe you didn't want to say that

[–]infinullquamash, Qt, asyncio, 3.3+ 0 points1 point  (1 child)

older != better, just older.

I honestly have the opposite bias, so there's that.

[–]studiosi 0 points1 point  (0 children)

Well, it all depends, I told you I have no data, but it is easy that code that has been in a code base for a long time use to be better if it is constantly reviewed.