Remove --fiximports helper

[tobiasdiez]

It did its job; the remaining imports are okay (or would need manual work anyway). This is part of trying to eliminate most in misc.

📝 Checklist

• The title is concise and informative.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation and checked the documentation preview.

⌛ Dependencies

[github-actions]

Documentation preview for this PR (built with commit df2d827; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[orlitzky]

looks like some of the CI failures are for real this time

[orlitzky]

Unfortunately it looks like the simpler __module__ approach fails in some cases where import_statements would work, e.g.

sage: ZZ.__module__
'sage.categories.category'
sage: import_statements(ZZ)
# ** Warning **: several names for that object: Z, ZZ
from sage.rings.integer_ring import Z

sage: RDF.__module__
'sage.categories.category'
sage: import_statements(RDF)
from sage.rings.real_double import RDF

So maybe that is worth keeping? I don't know of an easier way to get the right import. I always forget about import_statements and do foo?? followed by grep and reading the source.

I don't know what runsnake is, but I guess it should be deprecated first, moreso in this case to find out if anyone is actually using it. It looks like a very thin wrapper around %prun -T file.txt <command> and then running runsnake file.txt in a terminal. (And could probably be replaced by some profiling documentation that says as much.) That would also address the fact that runsnake() uses a temporary file for your profiling data, and therefore deletes it as soon as sage exits.

(The replace_dot_all module is technically public, too, but I can't imagine anyone trying to use it in their own code.)

[tobiasdiez]

So maybe that is worth keeping? I don't know of an easier way to get the right import. I always forget about import_statements and do foo?? followed by grep and reading the source.

Okay, I've restored the import_statements methods.

I don't know what runsnake is, but I guess it should be deprecated first, moreso in this case to find out if anyone is actually using it.

The global import of runsnake was deprecated in #34259, so I think it should be safe to delete it.

[orlitzky]

The global import of runsnake was deprecated in #34259, so I think it should be safe to delete it.

That only removed it from the global namespace, though -- it's still documented: https://github.com/sagemath/sage/blob/develop/src/doc/en/thematic_tutorials/profiling.rst?plain=1#L79

In case anyone is using it, I think we should update the docs to say "install runsnake and call it on your %prun -T output" rather than suggesting the sage function runsnake(cmd). Then we could deprecate the module itself and point people at the new docs.

[tobiasdiez]

Okay, I've restored the runsnake method now and properly deprecated it.

[orlitzky]

Weird to see the CI green.

[tobiasdiez]

Thanks for the review!

Weird to see the CI green.

You can thank @user202729 for this, who recently fixed quite a few issues.

[fchapoton]

The command fixmports was useful for my own private code.

[orlitzky]

The command fixmports was useful for my own private code.

Sorry, I don't think we were trying to break anyone's workflow. Do you use it continuously, or are you still migrating old code?

[fchapoton]

I am using it from time to time to have clean imports. Let me add that this was also useful when including new pieces of code inside sage; in which one needs to replace from sage.all import xyz,etc by the appropriate precise imports.

I do not reclaim that it's added back. Just grumbling

[orlitzky]

I don't know where it is on anyone's TODO list, but imports from sage.all are deprecated so that those modules can eventually be removed (they don't play well with namespace packages). When that happens you wont even be able to use from sage.all import xyz while testing, you'll have to use sage: import_statements('xyz') to get the explicit module name the first time.

I guess my excuse is that it may be annoying, but that it was going to be annoying in the long run regardless.

[tobiasdiez]

The command fixmports was useful for my own private code.

Sorry, I was not aware of that use case. We should really consider publishing tools that are designed for developers of sage-related code separately to tools that are exclusively meaningful when working directly at sage code.