#18083: Stop using old_style_globals
-------------------------------------+-------------------------------------
       Reporter:  jdemeyer           |        Owner:
           Type:  enhancement        |       Status:  new
       Priority:  major              |    Milestone:  sage-6.6
      Component:  cython             |   Resolution:
       Keywords:                     |    Merged in:
        Authors:  Jeroen Demeyer     |    Reviewers:
Report Upstream:  N/A                |  Work issues:
         Branch:                     |       Commit:
  u/jdemeyer/stop_using_old_style_globals|  
9ccd889321d311903d4ab26449e6dd8154879aee
   Dependencies:  #12446, #18084     |     Stopgaps:
-------------------------------------+-------------------------------------

Comment (by nbruin):

 Replying to [comment:16 jdemeyer]:
 > Are you implying with this sentence that #12446 isn't "entirely Python"?

 No, it is. I originally thought that "capturing" the correct `globals()`
 by defining a function in the relevant scope was cleaner than calling
 `sage.repl.user_globals.initialize_globals(...)`, but that's not really
 the case.

 In fact, one way a REPL could initialize globals is by injecting
 `sage.repl.user_globals.initialize_globals(globals())` into its "user
 input stream" at the start, which should work across REPLs. So I think
 your implementation is fine.

 I do think that `sage.repl.user_globals` is a dirty module, because its
 super-global side effects (that's its point--it's scribbling in a scope it
 shouldn't really have access to by normal python semantics) and hence
 should be used in as few places as possible in the library. So I'm still
 of the opinion that we'd be better off deprecating the
 `.inject_generators()` methods on various parents, in favour of a global
 scope function `inject(QQ['x,y'].gens)`.

 The function `inject` would then normally not be available in library
 modules: it would need an explicit import.

--
Ticket URL: <http://trac.sagemath.org/ticket/18083#comment:17>
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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to