Hi,

On 21 Okt., 20:59, Emmanuel Thomé <[EMAIL PROTECTED]> wrote:
> Hmm, it turns out that it's not just any code that triggers this
> behaviour. However, with the following test case I can reproduce the
> problem quite deterministically:
>
> (term1): strace -p `pidof sage.bin` -e trace='stat'
>
> (term2):
> sage: for i in range(100): float(1)/2
>

thanks for reporting this issue!

It's a very nice mind teaser to ponder about.

Since I have currently only Mac boxes in my reach, and on Mac OS X,
there does not seem to be neither "strace" nor "pidof", I only can try
to put pure thought on this one.

Firstly, the sage interpreter should not even know about those sage
core *.pyx files!

In the build process, there are corresponding *.so modules (Python so-
called "Extensions")
made out of them, and that is all a

   from sage.rings.integer import blahblubber

should care about: it should just use the "integer.so", more
precisely: the file
".../SAGE_ROOT/local/lib/python/site-packages/sage/rings/integer.so"
and then do (python-)internally
"load_dynamically(blahblubber)".

Since you don't complain about "Sage is not working", this seems what
happens anyway in each
of the "thousands searches per second" --- firstly, the *.pyx-file is
searched for, and no matter
how long the search takes or whether it is succesful, the
functionality ("blahblubber") is then gotten from
the *.so file (which has been there all the time, and probably ---
hopefully! --- is searched for
and loaded only once during a Sage/IPython/Python session).

So the question is: what parts of the Sage system *do* know about
*.pyx-files?

It's not the "pure" Python part of Sage.
It's not the IPython interpreter part of Sage.

That leaves in my eyes three possible culprits, that certainly do know
about *.pyx files generally:
a.) the "Cython" package inside python      (.../python/site-packages/
Cython/...)
b.) the "pyximport" package inside python  (.../python/site-packages/
pyximport/...)
c.) some "sage.misc" module like "interpreter.py" or "preparser.py"

Now if somewhere in the Sage/IPython/Python startup there would be
issued e.g.:
   import pyximport
   pyximport.install()
I could imagine that the behaviour you desribed would follow from
that:
the "normal" python mechanism to import sth. would have been twisted
in such a way
that every import does a file system access, looking for a *.pyx file
(at least if there is no *.py or *.pyc or *.pyo), and only then
looking internally. or for
a .so-file.

But I admit that I have not come across any clue that "pyximport" is
activated,
nor why that should be.

As for possibility c): these modules seem to be "in action" only if
you load/attach
explicitly some files from the interpreter. But Sage core modules like
"sage.rings.integer"
are built-in, i.e. they are not being interpreted.

Leaves culprit a), i.e. Cython.
But I so far, I only knew that Cython fiddles around with "distutils"
module,
not with the "import" statement.

Well, maybe the "real" Sage developers (I myself have not commited any
code so far)
find some time to investigate.

Cheers,
gsw

> Regards,
>
> E.
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to