What should Sage import by default?

[John H Palmieri]

There is a ticket (https://trac.sagemath.org/ticket/25383) about removing some Sage functions from the global namespace, which I think is a good idea. But Sage also imports some Python modules:

- os

- sys

- operator

- math

- warnings

Should we keep all of these? Remove all? Keep some?

--

John

[Kwankyu Lee]

+1 to remove all.

[Andrey Novoseltsev]

Perhaps it makes sense to keep "math related" imports given that we have a bunch of other "math functionality" available without extra imports and that's the point of Sage in general. While stuff for dealing with files and warnings is special enough to require special commands.

[Kwankyu Lee]

+1 to keep operator in the global name space. The doctests of the coercion model  assumes it.

[Nils Bruin]

On Tuesday, September 1, 2020 at 9:50:07 PM UTC-7, John H Palmieri wrote:

There is a ticket (https://trac.sagemath.org/ticket/25383) about removing some Sage functions from the global namespace, which I think is a good idea. But Sage also imports some Python modules:

- os

- sys

- operator

- math

- warnings

o u

Should we keep all of these? Remove all? Keep some?

While I understand the drive to clean up the global namespace and in principle agree with the aesthetics of doing so, I've never been disappointed by something being available in the global namespace and on occasion am slightly annoyed by having to import something in python prior to use that I for some reason thought would there be by default (e.g., many of the functions in "math"). I've sometimes have had mildly surprising results by encountering something I didn't expect (R being the R interface is the main one there), but that was always quickly diagnosed. So, are we actually solving a practical problem by cleaning up the global namespace? If it measurably improves start-up time then we do have a win, but I suspect that the time-consuming start-up imports are necessary anyway (or are already lazy).

[William]

+1 to Nils remarks. 

Please also consider backward compatibility.   If you remove a bunch of things, I'm probably just going to have to add them back on cocalc to avoid all the headaches of people's code breaking. There might be a ton of random code out there that will break if you remove a bunch of imports.   

It would be nice to have a different entry point to Sage that has *dramatically* less imported by default.  By I don't think it should be the default, just because of backward compatibility.

William

[John H Palmieri]

Backward compatibility is not that convincing. If the items should not be imported (that is, if it was a mistake in some sense to import them), then we should fix that. Is there a good way to deprecate imports? (That is, print a warning the first time someone uses sys...., for example?)

Re Nils' remarks: I think that we should have good reasons every time we deviate from standard Python. From that point of view, maybe (?) "math" or "operator" would be sensible things to import, although I don't remember the last time I used either. Do others use these frequently? "sys" and "os" are not directly tied to anything Sage-specific; they don't seem like they belong at all (although I do use them).

--

John

[Nils Bruin]

On Tuesday, September 8, 2020 at 8:59:20 PM UTC-7, John H Palmieri wrote:

Re Nils' remarks: I think that we should have good reasons every time we deviate from standard Python. From that point of view, maybe (?) "math" or "operator" would be sensible things to import, although I don't remember the last time I used either.

I think we should probably NOT be importing the functions in "math", but instead provide alternatives for most them, with improved functionality. I think that's already reality now. I was just giving "math" as an example in *python* where it's a little irritating that extra action is required to access the functionality.