New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stop using old_style_globals #18083
Comments
Commit: |
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
This comment has been minimized.
This comment has been minimized.
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
comment:7
Just an idea: Logically, we can't really ask an object to inject itself into "the" globals namespace, because the object doesn't really have access to what that namespace is in the relevant situation. Instead what one can do from the REPL is to bind an object to its print name, which is what injection usually does. Then one actually doesn't need any special machinery on objects. See: In principle then one can spell:
where
except that we'd want to do some validation on Of course to type this is very inconvenient, so we'd need some further wrappers to make the syntax more palatable (the |
comment:8
Replying to @nbruin:
So instead of calling And I don't understand how you would implement |
comment:9
Replying to @jdemeyer:
No, it doesn't make much practical difference. You're basically storing the dictionary on
That's a matter of import, isn't it? Compiling cython normally gives a module |
comment:10
Replying to @nbruin:
So the one-liner |
comment:11
Replying to @jdemeyer:
No, I wasn't proposing to change the user interface of My observation is just that in the architecture of python, it is more natural to ask the REPL to inject a binding than to ask an object to inject itself into the global scope of the REPL. Hence, we might end up with simpler, easier to maintain code if we follow that design and use as a fundamental building block a service provided by the REPL. For things like
it might be nicer (and easier to implement!) to spell it as
|
comment:12
Replying to @nbruin:
That was exactly my question: how? |
comment:13
Replying to @jdemeyer:
Logically the (very thin!) wrapper Alternatively, once "inject" has been defined, we could inject it:
ready for use there. Or one could access the dictionary there via inject.func_globals (which wouldn't be so clean). Admittedly, this is all not so much cleaner than what happens now. The central "cleaner" principle is that there is a way of capturing a "globals" dictionary: define a function there. That should be a portable principle (accessing func_globals directly is probably not strictly portable). I'm not suggesting that we should absolutely implement it like this, but I think it might be useful to design the underlying code in a way that it might have been implemented in this way, simply to stay close to "the python way" of doing things. I don't think the python way is sacred, but since we're basing things on python, we should have good reasons every time we do deviate from it. And I'm not so sure that for injection we do have such a good reason. One "python way" would be to define in, say, sage.misc.inject
and then have the different interfaces/REPLs monkey patch an appropriate "inject" into sage.misc.inject.inject. I'm not so sure how clean monkey patching is and how robust this is against |
comment:14
Replying to @nbruin:
Sorry, I don't understand this sentence.
So everybody's Sage code should start with the boilerplate
Not an elegant solution. Of course you could say "let's define |
comment:15
Replying to @nbruin:
The closest Python statement to what we're doing is |
comment:17
Replying to @jdemeyer:
No, it is. I originally thought that "capturing" the correct In fact, one way a REPL could initialize globals is by injecting I do think that The function |
comment:18
Just discovered the existence of |
comment:19
Just ran into this old ticket myself, looking at how we can work around
There is a way to write such code in python directly. Something like:
should do the trick in most cases (if the caller's "globals" is a read-only dict itself, as a cython module "globals" would be, then one shouldn't be injecting variables in it anyway). I suspect that with |
comment:20
Cython doesn't generate a stack frame, so Indeed, using
This makes a difference because this overrides the Cython-specific |
Instead of using Cython's
old_style_globals
option, we use the newuser_globals
from #12446 to accessglobals()
.In order to support
we make a small change to the preparser: we ensure that
f(x) = ...
makesx
available both as global and as local.Depends on #12446
Depends on #18084
Component: cython
Author: Jeroen Demeyer
Branch/Commit: u/jdemeyer/stop_using_old_style_globals @
9ccd889
Issue created by migration from https://trac.sagemath.org/ticket/18083
The text was updated successfully, but these errors were encountered: