While working on this. I had 2 options, either to put the function in pytave.cc and create a new pytave.h (for including in other .cc files) or put them in a new file. I chose the second way (as I though the first one might require more changes in Makefile). Also, I moved the builtins_module thing to a separate function as it was required at many places.
Currently this doesn't work. I get and undefined symbol error:
I thought that adding pytave_utils.h in Makefile.am should do the trick. I did a make clean also rm Makefile and then did configure and make. Mike MillerColin Macdonald Please provide some suggestions to resolve the error. (I have very less knowledge of makefiles so my mistake might be pretty silly)
In the last test in pyeval.cc I have removed sys from the global namespace. So even if user is using sys before running the test, he will have to re import sys after running the tests. I am assuming that this is not an issue. The last test is necessary as in symbolic we wish to import everything in a new namespace (I think Colin meant this on the issue #25).
I am writing this comment here as I wrote it on the file but I had to do strip (to add 1 more test) which caused the comment to not be shown anymore (although there is "1" displayed next to the message icon in the Files Changed section).
not a fan of the bool return value to indicate success or failure to parse the argument, how about returning a null or None object?
Well, I don't think object can have NULL or nullptr as value, can it? And setting it None may result in conflict since it can be used to get any object from python, even 'None'... I'll try to think of something else for defining success/failure..
It looks to me like you squashed the return value change into the wrong commit. The first commit in this PR adds the new functions, with a bool return value. Then the second commit, which is supposed to be able adding the namespace option, changes it to void and checks for a None object.
I am planning on merging this as-is, but I have to ask, is there a reason to support passing the local namespace as either an identifier name or an object? I see the tests for both, but is there a valid use case for passing the namespace as an identifier of something in the main global namespace? I would like to clean up some redundancy, and I would rather just get rid of this case now if it's not important.
Well, it just that I re-used the pycall syntax. If the user has a dictionary as @pyobject (returned from some function) it would be convenient for him to just pass it instead of first storing it and then passing the variable name.
But, I guess the more important use-case will be passing the namspace as string because instead of keeping track of the @pyobject, I would prefer creating a global dictionary and then always using that via it's name (although now that I see the tests, there is only 1 test that uses dictionary name).
If you wish, you (or I) may remove the case for passing the object for namespace...