On 23 October 2016 at 17:10, Danilo J. S. Bellini <danilo.bell...@gmail.com> wrote: >> Ah, that makes SIX existing solutions. Do we need a seventh? > > It might have dozens of solutions, perhaps an infinity of solutions. > Brainfuck and assembly can be used, or even turing machine instructions... > > But there should be one, and preferably only one, OBVIOUS way to do it. > Readability counts.
Sure, but you haven't explained why your proposal is more obvious than any of the other six. Built in does not equate to obvious. More obvious is often to have a dedicated tool, in a module designed to provide tools in that particular area. That's partially why reduce got moved to the functools module (another part is the fact that Guido doesn't find functional-style approaches that "obvious" - and what's obvious to a Dutchman is the benchmark here :-)) I'm not against powerful "windowed function" capabilities - my background is SQL, and windowed functions in SQL have even more power than the sort of thing we're talking about here. But I wouldn't call them "obvious" - at least not based on the number of times I get to do explanations of them to colleagues, or the number of tutorials on them I see. So the idea seems fine to me, but I'd very definitely class it as an "advanced" feature, and typically that sort of feature in Python is handled in a library. > Reduce lost the built-in status on Python 3. Lambdas lost the decomposing > arguments like "lambda (a, b), c: a + b * c". Which can be interpreted as evidence that this type of approach is not considered a core feature. In general, I like the idea, but I don't think it fits well in Python in its proposed form. Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
