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.b...@gmail.com> > wrote: > > > > On Thu, Nov 29, 2018 at 12:16 PM Chris Angelico <ros...@gmail.com> wrote: > > > > > > On Thu, Nov 29, 2018 at 10:14 PM E. Madison Bray <erik.m.b...@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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/