[Python-ideas] Fast sum() for non-numbers

[Haoyi Li]

> Someone suggested moving this to builtins as "chain" or "flatten" or
similar. I'm at least +0 on this.

That would be nice too; I consider both imports and third-party-modules to
be part of the length-of-code for boilerplate-accounting purposes (not sure
if others do), and having an additional `import itertools; flatten =
blahblah` brings it up to 3 lines of code to flatten a list by that
technique. My files aren't very long, so I can't just do it once at the top
of everything.py and use it throughout my project. Three lines of code to
flatten a list! Or two-lines with a third party package! May aswell use a
for loop and accumulator.

> And it's obvious what it does. If you sum three sortedlists, do you get
the first list's elements, then the second, then the third, or a merge of
the three? I don't know. If you chain or flatten three sortedlists, it's
obvious which one you get.

Does python even *have* a sortedlist in the standard library? If they're
third-party-module classes, then having to do some thinking to see what the
builtins do to them seems acceptable to me; it's up to the sortedlist guy
to document that "yeah you can sum my sortedlists and it'll do XXX". I mean
you can probably *already* sum() them, and it'll do the same thing, just
probably slower.

<rant>I would also really like a nice object-oriented sortedlist to be part
of the standard library, instead of that nasty C-style heapq stuff.</rant>

I'd still rather we make use of the nice new generic dispatch stuff to make
our builtins re-usable, rather than having a set of crufty
only-really-works-on-builtins functions cluttering the *global* namespaces,
and having to manually pick from *another* bunch of non-generic custom
functions to do the same (conceptual) thing to different types. I don't
think that's going to happen anytime before Python 4.0 though. This sort of
"yeah, function_x() doesn't work on y, you have to use special_function_z()
to concat ys and thingy_z() to concat ws" is workable, but reminds me of my
bad-old php days.

-Haoyi



On Tue, Jul 9, 2013 at 9:02 AM, Andrew Barnert <abarnert at yahoo.com> wrote:

> From: Haoyi Li <haoyi.sg at gmail.com>
> Sent: Monday, July 8, 2013 5:39 PM
>
>
> > I for one find it annoying that i have to write a verbose long thingy
> every time i need to flatten lists
>
> What verbose long thingy? You just need to write:
>
>     flatten = itertools.chain.from_iterable
>
> Or, if you use more-itertools:
>
>     from more_itertools import flatten
>
> Someone suggested moving this to builtins as "chain" or "flatten" or
> similar. I'm at least +0 on this.
>
> At any rate, it's about as simple as can be.
>
> Because it gives you an iterable, you don't pay the cost (in time or
> space) of building a list unless you need to, which means in many use cases
> it's actually much faster than sum, at the cost of being a little bit
> slower for lists when you do need a list.
>
>
> It also flattens any iterable of sequences, or even any iterable of
> iterables, in the same time—linear in the total size. With no custom
> optimizations, it works with tuples, blist.sortedlists, cons lists, or
> _anything else you can throw at it_.
>
> And it's obvious what it does. If you sum three sortedlists, do you get
> the first list's elements, then the second, then the third, or a merge of
> the three? I don't know. If you chain or flatten three sortedlists, it's
> obvious which one you get.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130709/766b6c0e/attachment-0001.html>