Hi,
thanks for doing that.
Dag Sverre Seljebotn wrote:
> Just a quick note that in the gsoc-kurt branch I've implemented this:
>
> from UtilityCode import CythonUtilityCode
>
> ...
> env.use_utility_code(foo) # only on env. currently, not code.
That's too bad, because 'code' is where it belongs.
I assume the environment is required to define the utility code? In that
case, what about splitting it up, so that 'env' can be used to define
(parse/analyse/compile) the utility code snippet, but 'code' provides the
functionality to actually use it? (so that it won't turn up in the code if
the code generation decides not to need it)
> foo = CythonUtilityCode(u"""
>
> class __Pyx_UtilClass:
> pass
>
> cdef int __Pyx_UtilityFunction(int arg):
> return arg * 2
>
> """)
>
> Now, this will cause __Pyx_UtilityFunction to be dumped into the final C
> file, and the type descriptor to be called __Pyx_UtilClass (i.e. name
> mangling is dropped in some important cases).
Sounds hairy, but I think that makes sense. You have to know the name to
call the function after all. We could provide the utility code with a way
to mangle names, though. The code generator could then call into it,
instead of knowing the mangled name, so that
my_utility_code.mangle("UtilityFunction")
would return the above "__Pyx_UtilityFunction", or whatever the compiler
decided to use as name.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
