Hi John, I don't know if I have a good solution to your question.
At least, let me bring your question back to the first screen (perhaps someone else has a better solution?) and try to explain my not-so-nice- and-far-from-being-really-useful solution... On 30 Jul., 02:00, john_perry_usm <john.pe...@usm.edu> wrote: > I have a file type1.pyx that defines an extension type Type1, and a > file type2.pyx that defines an extension type Type2. Some attributes > of Type2 are of type Type1. If I have the types in one file, > everything runs fine; I'd like to separate them into different files. > > I placed these files in a local working directory. I can attach > type1.pyx with no problem. I cannot attach type2.pyx; this gives me: > > ImportError: No module named _atlas_perry_..._pyx.type1 > > even though I just attached the file containing extension type Type1, > and I can create objects of type Type1. If you attach a .pyx file, then it first needs to be compiled and eventually turned into a .so file (dynamic module). Before that is done, Python would not know how to import it. I guess the problem is that the resulting Python module has not the expected name: The new temporary Python module created from file1.pyx is not called file1, but _full_path_to_the_module_file1_pyx_0. If you change something in file1.pyx then Sage would automatically re-compile -- and thereby changing the name again, numbering the different versions. Example: I've put "class foo: pass" into a file file1.pyx in the directory ~/SAGE/tests, and attached it. sage: attach file1.pyx Compiling ./file1.pyx... sage: foo <class _home_king_SAGE_tests_file1_pyx_0.foo at 0x4402d10> As you can see, the module in which foo is defined is not called file1, but _home_king_SAGE_tests_file1_pyx_0. Now, I touch the file, and press "return" in Sage: sage: Compiling /home/king/SAGE/tests/file1.pyx... sage: foo <class _home_king_SAGE_tests_file1_pyx_1.foo at 0x440ee30> So, the name of the module has changed. But the old version of the module is still available: sage: from _home_king_SAGE_tests_file1_pyx_0 import foo sage: foo <class _home_king_SAGE_tests_file1_pyx_0.foo at 0x4402d10> sage: from _home_king_SAGE_tests_file1_pyx_1 import foo as bar sage: bar <class _home_king_SAGE_tests_file1_pyx_1.foo at 0x440ee30> Concerning a solution: I've put from _home_king_SAGE_tests_file1_pyx_0 import foo class bar(foo): pass into a file file2.pyx. Now, the attachment works (CONTINUING the Sage session from above - you can not attach file2 before you have attached file1): sage: attach file2.pyx Compiling ./file2.pyx... sage: bar <class _home_king_SAGE_tests_file2_pyx_0.bar at 0x45e8470> The obvious problem with that approach is that in file1 you need to provide a version number for the Python module obtained from file1. If you change file1 then file2 would not be aware of it. Besides, the actual .so file (which is what Python imports from) sits in a local directory. That can be seen if you try to get documentation: sage: bar? Type: classobj String Form: _home_king_SAGE_tests_file2_pyx_0.bar Namespace: Interactive File: /mnt/local/king/.sage/temp/mpc622/30190/spyx/ _home_king_SAGE_tests_file2_pyx/_home_king_SAGE_tests_file2_pyx_0.so Actually each version of your local module has its own local directory. Best regards, Simon -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
