Macros in py_def signatures should not be expanded

[axw]

The py_def macro uses cmonster's Python-macro feature. This feature generates a _Pragma operator token, stringizing the arguments of the py_def macro. When this is done, any macros that happen to be in the arguments will be expanded. This may not be desirable...

For example:

#define XYZ 456
py_def(ABC(XYZ))
    return 123
py_end

cmonster will barf because XYZ in the signature will be replaced with 456. So we'll get (after extracting the signature/body):

def ABC(456):
    return 123

This is clearly not valid Python syntax for a function signature.

[sztomi]

What is the reason for first generating the token instead of first running the script? (I'm making a fork that compiles with the latest LLVM and also want to fix the issues).

[axw]

@sztomi Sorry for being slow, but I'm not sure what you mean by "first generating the token". Can you please expand?

[sztomi]

That's probably my English, not you being slow :) So what I mean is, why not expand the Python macro first and simply insert the output into the source (just like you do in your example code in the readme)?

[axw]

It's been a couple of years since I looked at any of this, so take what I say with a grain of salt.

py_def is just a macro, and is expanded by the preprocessor, so it follows that the source must be tokenised.

It would be possible to "expand" the py_def prior to entering the preprocessor, i.e. locate all py_def blocks, remove them from the source, and define a pragma/macro in the Clang preprocessor. The problem with that is that it would mean you can't define py_def macros in another file which you then #include.

[sztomi]

Thanks, now I understand the problem.