On Thu, Nov 29, 2018 at 2:19 AM E. Madison Bray <erik.m.b...@gmail.com> wrote: > > On Wed, Nov 28, 2018 at 4:14 PM Steven D'Aprano <st...@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. ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
