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

[Steven D'Aprano]

On Thu, Nov 29, 2018 at 10:21:15PM +1100, Chris Angelico wrote:
> On Thu, Nov 29, 2018 at 10:18 PM E. Madison Bray <erik.m.bray at gmail.com> wrote:
> >
> > On Thu, Nov 29, 2018 at 12:16 PM Chris Angelico <rosuav at gmail.com> wrote:
> > >
> > > On Thu, Nov 29, 2018 at 10:14 PM E. Madison Bray <erik.m.bray at gmail.com> wrote:
[...]
> > > If that's the case, then it should be no problem to rebind
> > > builtins.map to return a list. Problem solved.
> >
> > Rebind where?  How?  In sage.__init__?  How do you think that will fly
> > with other packages loaded in the same interpreter?
> 
> Either this is Python, or it's just an algebra language that happens
> to be implemented in Python.

False dichotomy. Sage is *all* of these things:

- a stand-alone application which is (partially) written in Python;
- an application which runs under iPython/Jupiter;
- a package which has to interoperate with other Python packages;
- an algebra language.



> If the former, the Py2/Py3 distinction
> should matter to your users, since they are programming in Python.

Even if they know, and care, about the difference between iterators and 
lists, they cannot be expected to know or care about how the hundreds of 
Sage functions process lists differently from iterators. Which would be 
implementation details of the Sage functions, and subject to change 
without warning.

I sympathise with this proposal. In my own tiny little way, I've had to 
grapple with something similar for the stdlib statistics library, and 
I'm not totally happy with the work-around I came up with. And I have a 
few ideas for the future which will either render the difference moot, 
or make the problem worse, I'm not sure which :-)


> If
> the latter, it's all about Sage, ergo you can rebind map to mean what
> you expect it to mean. Take your pick.

Sage wraps a number of Python libraries, such as numpy, sympy and 
others, and itself can run under iPython which for all we know may 
already have monkeypatched the builtins for its own ~~nefarious~~ useful 
purposes. Are you really comfortable with monkeypatching the builtins in 
this way in such a complex ecosystem of packages? Maybe it will work, 
but I think you're being awfully gung-ho about the suggestion.

(At least my earlier suggestion didn't involve monkey-patching the 
builtin map, merely shadowing it.)

Personally, even if monkeypatching in this way solved the problem, as a 
(potential) user of SageMath I'd be really, really peeved if it patched 
map() in the way you suggest and regressed map() to the 2.x version.


-- 
Steve