News for hackers. Stuff that matters.
Re:The fate of reduce() in Python 3000 (2005) by dorfsmay on Tuesday January 01, 2019 @10:36AM (#18800529)
reduce() is still available in the functools module.

I highly recommend to become familiar with the functools, itertools and collections modules to anybody using Python and not using them regularly.

Re:The fate of reduce() in Python 3000 (2005) by stochastic_monk on Tuesday January 01, 2019 @10:50AM (#18800591)
I’ve really come to miss reduce in Python’s builtins since std::accumulate has become a staple in my C++ development. It seems surprising that with Python 3’s increased support for functional concepts, it would relegate reduce to the standard library.
Re:The fate of reduce() in Python 3000 (2005) by masklinn on Tuesday January 01, 2019 @02:46PM (#18801850)
Not really, increasing support for functional concept was never a goal of Python 3 (or at all), it was mostly incidental and it did regress in other ways than just shoving the (relatively little used due to the existence of min/max/any/all) out of the builtins e.g. while extended unpacking was added, unpacking iterable function parameters was removed.
Re:The fate of reduce() in Python 3000 (2005) by geezerjay on Wednesday January 02, 2019 @01:18AM (#18804530)
+1 for the std::accumulate reference, and I'll add an honorable mention of std::transform which since C++17 also runs in parallel.
Re:The fate of reduce() in Python 3000 (2005) by _asummers on Tuesday January 01, 2019 @10:51AM (#18800595)
This is broadly true across language. In Java, it was Collections, List, Elixir it's Enum, Python is your mentioned stdlib namespaces. Knowing your collection-ey stdlib functions will only help your code be more idiomatic and likely performant.
Re:The fate of reduce() in Python 3000 (2005) by black-tea on Tuesday January 01, 2019 @03:52PM (#18802283)
Indeed, those modules are essential for doing anything in Python beyond small scripts.