On Sunday 20 April 2003 07:59 am, Raymond Hettinger wrote: > > Now, I think the obvious approach would be to have a function sum, > > callable with any non-empty homogeneous sequence (sequence of > > items such that + can apply between them), returning the sequence's > > summation -- now THAT might help for simplicity, clarity AND power. > > +1 -- this comes-up all the time. Yes, I agree it does -- both in discussions (c.l.py, python-help -- dunno 'bout tutor, as I'm not following it) AND in practical use. > > I'm not > > quite sure where it should go -- a builtin seems most natural (to keep > > company with min and max, for example), but maybe that would be > > too ambitious, and it should be in math or operator instead... > > __builtin__ is already too fat. math is for floats. operator is mostly > for operators. Perhaps make a separate module for vector-to-scalar > operations like min, max, product, average, moment, and dotproduct. __builtin__ has 123 entries. ls Lib/*.py | wc finds 183 toplevel modules (without even mentioning those modules that are already grouped into packages). So, making new modules should be roughly as much of a "fatness" problem as adding new builtins, at least, shouldn't it? min and max are already built-ins. Computing average(x) as sum(x)/len(x) does not seem too much of a problem. product, moment and dotproduct appear to be "nice to have" rather than real needs. True, math deals only with float stuff. But operator doesn't seem too bad -- sure, it mostly exposes stuff that's already elsewhere in the internals (operators AND others, such as countOf), but that could be considered an implementation detail. Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4