PyTave and Symbolic play nice: some namespace support

Issue #25 resolved
Colin Macdonald created an issue

This is longer term, but while I'm thinking about it...

Symbolic does all sorts of imports, currently just into the same namespace where PyTave commands such as pyexec and pycall work.

Predictably this can lead to trouble if someone is using both PyTave and Symbolic. Even something as simple as pyexec("N = 10") will mess-up Symbolic b/c N is SymPy function (converts things to numeric values).

We cannot easily change Symbolic, we pretty much have to do import * from sympy (in fact more than that) so that recovering SymPy objects from their sym.pickle string works.

Python namespaces are just dicts. In Python, exec can accept dicts for the global and local namespaces. One solution is to expose some of that. So Symbolic can request a private namespace, and muck it up, independent of other PyTave usage. Perhaps that namespace is itself a @pyobject...

Maybe:

pyexec(cmd, local_ns, global_ns)

Comments (9)

  1. Colin Macdonald reporter

    @genuinelucifer this might also solve your pystore issue. We can just inject _ins into the local_ns Python dict. Something like this:

    ...
    local_ns('_ins') = {1 1.2 "hello" [1 2 3] inf};
    pyexec(cmd, local_ns, global_ns)
    
  2. Abhinav Tripathi

    @macdonald this seems a really nice substitute to pystore. Sorry for not noticing it till now. . I will try to work on this next, if we can get our own namespace as pyobject then this would definitely prove of much use.

  3. Mike Miller repo owner

    So if I understand correctly, this is basically about being able to assign names with pyexec, right? If it weren't for the ability to assign a name in the Python namespace using pyexec this would not be an issue, right?

    Maybe I'm naive but I hope that this becomes more and more of a corner case and users won't even need pyexec at all. Once we have the ability to store references to data and functions and lambdas using pyeval and pycall, maybe there will be no need for pyexec any longer. My hope is that all the state can be stored in Octave's namespace and users will have no need to store things directly in Python (aside from the hidden cache that we use for storing assigned values of course).

  4. Mike Miller repo owner

    And by assigning names I mean any of pyexec("N = 10"), pyexec("import foo"), or pyexec("from foo import bar").

    All of these uses are manipulating names on the Python side of things rather than on the Octave side.

    I do realize that Python's sympy package basically wants you to import everything.

    I still hope that usages like this aren't necessary for most users with where we are going, that names can be assigned and stored on the Octave side only and we can avoid putting names into the Python namespace at all.

  5. Colin Macdonald reporter

    I haven't yet played with Matlab's py, but from their docs, py.eval does support passing a local and global namespace (i.e., it looks like python's usual eval).

    But anyway, I agree with your comments. Its also possible that Symbolic can workaround this in some other way: e.g., do our many imports inside a function.

  6. Mike Miller repo owner

    Add option to specify namespace when calling pyexec and pyeval (fixes issue #25)

    • pyeval.cc, pyexec.cc: Use the second parameter (if supplied) as namespace to eval/exec the python code.

    → <<cset b4e56f7255f7>>

  7. Mike Miller repo owner

    Add option to specify namespace when calling pyexec and pyeval (fixes issue #25)

    • pyeval.cc, pyexec.cc: Use the second parameter (if supplied) as namespace to eval/exec the python code.

    → <<cset b4e56f7255f7>>

  8. Log in to comment