Re: [Python-Dev] a different kind of reduce...
Reinhold Birkenfeld wrote:
And we have solved the "map, filter and reduce are going away! Let's all weep together" problem with one strike!
I'm not sure if you're wildly enthusiastic, or very sarcastic. I'm not sure which I should be either ... The thought does appeal to me - especially func.partial(args). I don't see any advantage to func.map(args) over func(*args), and it loses functionality in comparison with map(func, args) (passing the function as a separate reference). Tim Delaney
"Delaney, Timothy (Tim)" <tdelaney@avaya.com> wrote:
I was under the impression that: fcn.<old builtin name>(...) would perform equivalently as <old builtin name>(fcn, ...) does now. So all the following would be equivalent... func.map(args) map(func, args) [func(i) for i in args] Me, I still use map, so seeing it as fcn.map(...) instead of map(fcn,...) sounds good to me...though it does have the ugly rub of suggesting that None.map/filter should exist, which I'm not really happy about. In regards to the instance __call__ method, it seems reasonable to require users to implement their own map/filter/reduce call. - Josiah
"Delaney, Timothy (Tim)" <tdelaney@avaya.com> wrote:
I was under the impression that: fcn.<old builtin name>(...) would perform equivalently as <old builtin name>(fcn, ...) does now. So all the following would be equivalent... func.map(args) map(func, args) [func(i) for i in args] Me, I still use map, so seeing it as fcn.map(...) instead of map(fcn,...) sounds good to me...though it does have the ugly rub of suggesting that None.map/filter should exist, which I'm not really happy about. In regards to the instance __call__ method, it seems reasonable to require users to implement their own map/filter/reduce call. - Josiah
participants (2)
-
Delaney, Timothy (Tim) -
Josiah Carlson