[Python-ideas] __len__() for map()

[E. Madison Bray]

On Wed, Nov 28, 2018 at 4:24 PM Chris Angelico <rosuav at gmail.com> wrote:
>
> On Thu, Nov 29, 2018 at 2:19 AM E. Madison Bray <erik.m.bray at gmail.com> wrote:
> >
> > On Wed, Nov 28, 2018 at 4:14 PM Steven D'Aprano <steve at pearwood.info> wrote:
> > >
> > > On Wed, Nov 28, 2018 at 04:04:33PM +0100, E. Madison Bray wrote:
> > >
> > > > That effort is already mostly done and adding a helper function would
> > > > not have worked as users *passing* map(...) as an argument to some
> > > > function just expect it to work.
> > >
> > > Ah, that's what I was missing.
> > >
> > > But... surely the function will still work if they pass an opaque
> > > iterator *other* than map() and/or filter?
> > >
> > > it = (func(x) for x in something if condition(x))
> > > some_sage_function(it)
> >
> > That one is admittedly tricky.  For that matter it might be nice to
> > have more introspection of generator expressions too, but there at
> > least we have .gi_code if nothing else.
>
> Considering that a genexp can do literally anything, I doubt you'll
> get anywhere with that introspection.
>
> > But those are a far less common example in my case, whereas map() is
> > *everywhere* in math code :)
>
> Perhaps then, the problem is that math code treats "map" as something
> that is more akin to "instrumented list" than it is to a generator. If
> you know for certain that you're mapping a low-cost pure function over
> an immutable collection, the best solution may be to proxy through to
> the original list than to generate values on the fly. And if that's
> the case, you don't want the Py3 map *or* the Py2 one, although the
> Py2 one can behave this way, at the cost of crazy amounts of
> efficiency.

Yep, that's a great example where it might be possible to introspect a
given `map` object and take it apart to do something more efficient
with it.  This is less of a problem with internal code where it's easy
to just not use map() at all, and that is often the case.  But a lot
of the people who develop code for Sage are mathematicians, not
engineers, and they may not be aware of this, so they write code that
passes `map()` objects to more internal machinery.  And users will do
the same even moreso.

I can (and have) written horrible C-level hacks--not for this specific
issue, but others like it--and am sometimes tempted to do the same
here :(