See #22941 for a separate approach (independent of #22933, each ticket
fixes a different problem).
John
On Tuesday, May 2, 2017 at 2:33:27 PM UTC-7, Dima Pasechnik wrote:
>
> this is now #22933, ready for review.
>
> Note that it's not a complete fix;
>
> sage: vars()
>
> still fails
>
> sag
this is now #22933, ready for review.
Note that it's not a complete fix;
sage: vars()
still fails
sage: v=vars()
sage: for k in v.keys(): print v[k]
works with the ticket branch.
On Tuesday, May 2, 2017 at 9:01:42 PM UTC+1, Dima Pasechnik wrote:
>
> In fact, complete_sandpile has been remo
In fact, complete_sandpile has been removed, but the lazy import for it is
still there.
So this has to be fixed. I will open a ticket.
On Tuesday, May 2, 2017 at 8:48:47 PM UTC+1, Dima Pasechnik wrote:
>
> no, it's more serious, perhaps something to do with lazy imports?
>
> sage: v=vars()
> sag
no, it's more serious, perhaps something to do with lazy imports?
sage: v=vars()
sage: v['complete_sandpile']
) failed:
AttributeError: 'module' object has no attribute 'complete_sandpile'>
(I found the value of the guilty key by running
sage: for k in v.keys(): v[k]==None;
until it breaks)
(sa
I think it's a (pretty?) printing problem. For me, running
sage: a = vars()
works without error, but then
sage: a
gives the error. Same thing happens with locals().
--
John
On Tuesday, May 2, 2017 at 2:37:25 AM UTC-7, Dima Pasechnik wrote:
>
> Indeed, it appears that vars() is broken
Indeed, it appears that vars() is broken, and has been broken since Sage
7.5, at least.
Running
sage: vars()
ends with
---
TypeError Traceback (most recent call last)
in ()
> 1 vvv
/hom
