Ask Your Question

importing .sage files

asked 2011-01-13 03:19:28 -0500

DSM gravatar image

updated 2011-01-13 03:21:41 -0500

What's the recommended approach for importing .sage scripts as a module, i.e. into their own namespace? I have a file with ~10k functions and it'd be much nicer to keep them filed tidily away.

I've written a hack sage_import wrapper which seems to work for my use case, but hopefully there's a better way.

edit retag flag offensive close merge delete


Maybe you can post your hack as an edit to your post?

kcrisman gravatar imagekcrisman ( 2011-01-13 03:39:12 -0500 )edit

1 answer

Sort by ยป oldest newest most voted

answered 2011-01-13 04:25:32 -0500

niles gravatar image

updated 2011-01-15 03:31:56 -0500

You could instead apply the sage preparser, resulting in a .py file which you can then import with no trouble.

If you call "sage filename.sage", sage will preparse and store in the same directory (as well as carrying out all the commands in the file, which will be problematic in some cases). @ivan-andrus points out that

"sage --preparse filename.sage"

will do just the preparsing :)


edit flag offensive delete link more


I like this, though I don't know if it is answering DSM's question. It would be nice to have something like `attach('foo.sage',global_namespace=False)` available for those who use it from the command line - if that's what DSM is asking.

kcrisman gravatar imagekcrisman ( 2011-01-13 06:34:08 -0500 )edit

I haven't seen any problems with just running `sage --preparse FILE.sage`. What problems do you have?

Ivan Andrus gravatar imageIvan Andrus ( 2011-01-15 02:03:57 -0500 )edit

Ah *that's* the command I was looking for! `sage-preparse` is a separate executable which needs to be called in the right way, which I couldn't figure out; passing the `--preparse` option to sage seems to do the trick. Thanks!

niles gravatar imageniles ( 2011-01-15 03:27:47 -0500 )edit

Well, invoking the functions in sage.misc.preparser is what my hack currently does. One problem with preparser approaches -- mine included, at least so far -- is that the resulting code shows up in a mymodule.somefunc?? call in its postprocessed form, which is often hard to read. (Enough __sage_const_ bits floating around and even simple formulae look confusing.) This gives writing Sage code _in Sage code_ a weirdly second-class status. I'm leaning towards modifying the .func_code.co_* data so that I can see what I actually wrote [possibly putting the post-processed version below it]; this is a little tricky, though.

DSM gravatar imageDSM ( 2011-01-15 04:13:59 -0500 )edit

ah; that is annoying

niles gravatar imageniles ( 2011-01-15 04:22:58 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


Asked: 2011-01-13 03:19:28 -0500

Seen: 1,259 times

Last updated: Jan 15 '11