On Wed, Mar 3, 2010 at 5:50 PM, Lisandro Dalcin <[email protected]> wrote:
> On 3 March 2010 22:01, Ondrej Certik <[email protected]> wrote:
>> On Wed, Mar 3, 2010 at 3:54 PM, Lisandro Dalcin <[email protected]> wrote:
>>> On 3 March 2010 20:28, Ondrej Certik <[email protected]> wrote:
>>>>>
>>>>> Cython could grow support for your use case... If you really feel you
>>>>> will need this (as opposed to implementing the "Python" class),
>>>>> perhaps I could take a look at it and implement something...
>>>>
>>>> Do you have some ideas how Cython could be improved to make my use case
>>>> easier?
>>>>
>>>
>>> The easier way to get something working would be to use a preprocessor
>>> macro to control the storage (i.e. static vs. extern) of the symbols
>>> you get in the generated C header... Then you just have to #include
>>> the module API header like this:
>>>
>>> #define CYTHON_USE_GLOBAL_API
>>> #include <mymodule_api.h>
>>>
>>> You will still need to call import_mymodule(), but you just need to do
>>> it earlier in your code, likely a few lines below Py_Initialize()
>>>
>>> Does this look good/easy enough for you?
>>
>> That looks cool, I'll give it a shot.
>>
>
> OK, but you will need an additional step... You have to create an
> additional C source, #include the generated API header, and make it
> 'define' all these pointers... So perhaps you will need an additional
> macro (let say, named CYTHON_DEFINE_GLOBAL_API) to tell the header
> file "define these symbols at this point"
>
> Am I being clear enough?
Yes, that is clear to me, thanks.
>
>>>
>>>> I can try to write something too --- I am still in the stage of
>>>> figuring things out, not sure yet what I really want in details. I
>>>> only know my general goal --- it should be easy for C++ users to use
>>>> it, should be robust (no segfaults) and Python internals should not be
>>>> visible at all. I am half way there already.
>>>>
>>>
>>> I have to insist: The best (though admittedly complex) way to do this
>>> is you have a 'Python' class, in such a way its instances serve as a
>>> execution context... If you start with this, using separate
>>> interpreters (like Apache's mod_python) in the near future could be
>>> straightforward.
>>
>> Yes, I currently store the context in the "namespace" global
>> dictionary in Cython. I'll give it a shot too. I don't mind using one
>> interpreter, but at least each Python class instance should have it's
>> own namespace.
>>
>
> That should work (don't remember the C-API equivalent of "exec in
> namespace", but Cython sources have the trick in order to implement
> the 'exec' statement)
That is already implemented, here is my exec function:
cdef api object run_cmd(const_char_p text, object namespace):
try:
verbose = namespace.get("verbose")
if verbose:
print "got a text:", text
if verbose:
print "evaluting in the namespace:"
print namespace
code = compile(text, "", "exec")
eval(code, {}, namespace)
if verbose:
print "new namespace:"
print namespace
return namespace
except SystemExit, e:
try:
exit_code = int(e)
except:
exit_code = -1
exit(exit_code)
except:
etype, value, tb = sys.exc_info()
s = "".join(traceback.format_exception(etype, value, tb))
s = "Exception raised in the Python code:\n" + s
throw_exception(s)
>
>> One more question --- can there be any problem if I call for example
>> from Python:
>>
>> m.add()
>>
>> and add() is implemented in C++, and internally it calls some stuff in
>> Python (like scipy). In principle it could be recursively nested
>> couple times.
>
> Normal recursion limit applies here... A couple of times should not be
> a problem, a couple thousand times, better don't do that...
>
>> Can the Python interpreter be confused by this
>> "nesting"? Normally it's not an issue since one usually just wraps a
>> C/C++ code, which doesn't call Python.
>>
>
> Cython itself can call Python, that calls Cython that call Python,
> that calls ...
Ok, great! i was worried if there were some issues, but it seems
everything will work very smoothly and the C++ guys in my group will
not even notice that they are using Python. :)
Ondrej
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
