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 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. 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. At least to me, this seems slightly nicer. Example session: # lazily import QQ under the name MyQQ sage: LazyImport(globals(),'QQ','sage.rings.rational_field','MyQQ') lazily imported QQ # MyQQ is known in the global name space, but it is not properly imported yet: sage: MyQQ lazily imported QQ # Now do anything with MyQQ: Introspection, or calling: sage: MyQQ(3) 3 # In the preceding line, MyQQ imported QQ and replaces itself with it in globals(). # So, by now, there is absolutely no overhead in calling MyQQ: sage: MyQQ Rational Field What do you think about it? Cheers, Simon -- 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
