Le Tue, Feb 23, 2021 at 11:24:42AM -0500, Prakhar Goel a écrit :
> I had similar ideas in the past (assuming I understand your proposal). I'd
> love it if a decorator could link to some python function. This python
> function would get something that represents the cdef function (with the
> ast). It would then return a transformed ast that could be spliced into
> the original program.
As I said, I'm not sure allowing AST manipulation would be that useful.
I mean, it's rarely ever needed in python. Why would it be needed with
cython?
However, it would surely make the code much less readable, since the
code that's executed is not the code that's written.
The use-cases I have in mind are more like these. Which are common
patterns in python.
Compile-time implementation choice:
if os == "Windows":
cdef thread_something():
# Handle Windows-specific behavior
else:
cdef thread_something():
# Assume POSIX behavior
Decorators on cdef functions:
def twice(f):
cdef fun(x):
return f(2*x)
return fun
@twice
cdef foo(x):
# Do something math-y
Creating cdef classes on demand:
def make_ptr_class(T):
cdef class C:
cdef T *ptr
return C
IntPtr = make_ptr_class(int)
FloatPtr = make_ptr_class(float)
My current use-case is actually exactly this one. Creating wrappers
classes for pointer types. Which I currently cannot make both generic
and type safe.
The python code run at compile-time would basically manipulate python
objects representing cdef functions, classes and C types.
Internally, the way it could be implemented is that cython could
generate a python program that would produce the AST. But it doesn't
mean the AST itself has to be visible.
Best regards,
Celelibi
_______________________________________________
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
