You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sage's libgap did this because it tried to restrict the tab-completion to only "documented" functions in GAP, but where "documented" is somewhat ill-defined, and generating the complete list of documented globals at runtime is very slow.
I have asked the GAP developers about this in the past and they have also recommended against it. Using a hard-coded list also means globals added by common packages are not picked up.
Generating a list of global variables (excluding GAP keywords) is simple and reasonably fast:
In [23]: keywords = set(gap.GAPInfo['Keywords'])
In [24]: gap_globals = [g for g in gap.Filtered(gap.NamesGVars(), gap.IsBoundGlobal) if g not in keywords]
In [25]: %timeit gap_globals = [g for g in gap.Filtered(gap.NamesGVars(), gap.IsBoundGlobal) if g not in keywords]
51.8 ms ± 1.61 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
The text was updated successfully, but these errors were encountered:
This is basically the same as https://trac.sagemath.org/ticket/27923
Sage's libgap did this because it tried to restrict the tab-completion to only "documented" functions in GAP, but where "documented" is somewhat ill-defined, and generating the complete list of documented globals at runtime is very slow.
I have asked the GAP developers about this in the past and they have also recommended against it. Using a hard-coded list also means globals added by common packages are not picked up.
Generating a list of global variables (excluding GAP keywords) is simple and reasonably fast:
The text was updated successfully, but these errors were encountered: