On Thu, Nov 29, 2018 at 2:22 PM Chris Angelico <[email protected]> wrote: > > On Fri, Nov 30, 2018 at 12:18 AM Steven D'Aprano <[email protected]> wrote: > > 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. > > To be quite honest, no, I am not comfortable with it. But I *am* > comfortable with expecting Python programmers to program in Python, > and thus deeming that breakage as a result of user code being migrated > from Py2 to Py3 is to be fixed by the user. You can mess around with > map(), but there are plenty of other things you can't mess with, so I > don't see why this one thing should be Sage's problem.
The users--often scientists--of SageMath and many other scientific Python packages* are not "Python programmers" as such**. My job as a software engineer is to make the lower-level libraries they use for their day-to-day research work _just work_, and in particular _optimize_ that lower-level code in as many ways as I can find to. In some cases we do have to tell them about Python 2 vs Python 3 things (especially w.r.t. print()) but most of the time it is relatively transparent, as it should be. Steven has the right idea about it. Not every detail can be made perfectly transparent in terms of how users use or misuse them, no. But there are lots of areas where they should absolutely not have to care (e.g. like Steven wrote they cannot be expected to know how every single function might treat an iterator like map() over a finite sequence distinctly from the original finite sequence itself). In the case of map(), although maybe I have not articulated it well, I can say for sure that I've had perfectly valid use cases that were stymied merely by a semi-arbitrary decision to hide the data the wrapped by the "iterator returned by map()" (if you want to be pedantic about it). I'm willing to accept some explanation for why that would be actively harmful, but as someone with concrete problems to solve I'm less convinced by appeals to abstracts, or "why not just X" as if I hadn't considered "X" and found it flawed (which is not to say that I don't mind any new idea being put thoroughly through its paces.) * (Pandas, SymPy, Astropy, and even lower-level packages like NumPy, not to mention Jupyter which implements kernels for dozens of languages, but is primarily implemented in Python) ** With an obligatory asterisk to counter a common refrain from those who experience impostor syndrome, that if you are using this software then yes you are in fact a Python programmer, you just haven't realized it yet ;) _______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
