#14187: Check that lazy imports are not resolved during startup
--------------------------------+-------------------------------------------
Reporter: vbraun | Owner: tbd
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.8
Component: performance | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers: Nicolas M. Thiéry
Authors: Volker Braun | Merged in:
Dependencies: | Stopgaps:
--------------------------------+-------------------------------------------
Comment (by robertwb):
Replying to [comment:31 nbruin]:
> Replying to [comment:30 robertwb]:
> > This is intentionally creating a partially-constructed tuple and using
the fact that get_referrers() can refer to it.
> Agreed. It's intentionally exposing one of the dangers. That's the point
of an example. We need to convince ourselves that this will never happen
with a dictionary. And then probably only do replacements when `type(ref)
is dict` rather than `isinstance(ref,dict)` and document that lazy imports
only work in conventional `globals()` (one never knows what comes of
subclassing).
Totally fine with that.
> > "partially-constructed" dicts are safe, if we ever run across one.
> Do you have a reference that they are? Are you sure it's just partially
constructed ones? Note that as soon as a value in a `dict` we iterate over
is `NULL`, we're done for, since the value fetch will cause an `INCREF` on
that `NULL` pointer. Lazy imports can be triggered to resolve at funny
times, quite possibly when a class definition is being processed. At that
time, the `dict` of that class has not been given out yet, so it would be
under construction and I don't immediately see why it should abstain from
putting a key with a null value in there already.
There's neither an API nor motivation to insert key with a NULL value.
> For infrastructure like this I'd be rather reluctant to just rely on "it
seems to work in all the cases we've tried", especially because it would
be nice if this code were robust in the face of python upgrades.
Agreed.
> (Concerning cost: the call basically requires a full `GC` sweep, so it's
very expensive. If you can make sure that there are very few `lazyimport`
instances then the cost may be acceptable, because the resolution of any
single such instance will trigger a GC)
Fair enough. I don't think this is a huge problem, it's basically deferred
startup. It could be interesting to have the ability to force all lazy
imports to be resolved (perhaps even in the background...) but that could
be trickier.
> Note that in sage, a GC can trigger the callback of a `WeakValueDict`,
which can trigger an `__eq__` on an arbitrary object, which can possibly
trigger the resolution of a `LazyImport`. Are you still sure `dict`s are
safe to examine under those conditions?
I don't see why not. For instance, `dicts` follow the GC protocol of
removing themselves from the loop when they're being destructed.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14187#comment:32>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
