On Mar 4, 2010, at 4:14 PM, Simon King wrote:
Hi Robert!
On 4 Mrz., 19:21, Robert Bradshaw <rober...@math.washington.edu>
wrote:
[...]
See, for example, lazy import athttp://trac.sagemath.org/sage_trac/ticket/7502
Thank you very much, that was almost what I was hoping for.
What I don't like in that solution:
If you lazily import, say, QQ, then QQ will forever be a LazyImport
object -- there will only be an attribute QQ._object eventually
getting assigned to the rational field. Hence, whenever the user wants
to do something with QQ (and this may be very often) then there would
be the attribute lookup. This may be a small overhead, but wouldn't it
be noticable, on the long run?
It seems frigthening to me to have every single thing from sage.all
wrapped up into a LazyImport object
I hope the overhead is small, but it will certainly not be zero. I'm
not imagining that everything be wrapped, only less-commonly used,
expensive stuff. QQ would be imported by default for sure. For
example, EllipticCurve could be wrapped. The schemes directory takes .
3 seconds to load--I use it all the time, but that won't be a big hit
the first time I use it, and the overhead of the wrapper for
constructing an elliptic curve will be (relatively) negligible.
I would prefer that a LazyImport object has an argument G that
provides the name space into which the import shall eventually take
place. In the beginning, the LazyImport object would be written into G
under a certain name.
This is how it works now. You don't even have to provide globals(), as
it deduces it from the call stack. (This won't work from Cython, if
anyone knows how to do that I'd be glad to know ;) Probably should be
an optional argument.)
As soon as anything is done with the object, it
does a *real* import, replaces itself in G with the real thing, and
since the reference from G is gone, the LazyImport object would
eventually be garbage collected.
I've actually intended to do this as well, it'd be easy, but I just
haven't had time to do it. Note, however, that this is not transitive,
so the lazy objects may still be around. (This is less of an issue for
the global namespace, but if someone does "from sage.all import foo"
they'll have the lazy version forever.) There's some other
improvements that I'd like to make too. You willing to referee a patch
in this direction? :)
- Robert
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
