I would use a configuration file, that's read by both programs. I've used such files with Python before, there's a library for reading/writing them, and I suppose you can find libraries to read the same for C++.
Not exactly what you asked for but save the .h and convert to py on the fly?
https://github.com/evandrix/cPython-2.7.3/blob/master/Tools/scripts/h2py.py
I ended up putting them in a spreadsheet and then using that to automatically generate the C++ and Python files.
In view of the fact that Python is an interpreted language if you put the constants in a .h file for the C++ program then Python could read and parse that file at startup.
Indeed, there is no need for a special file. Python could read any of the C++ source files. But a special file might make life easiest.
...R
It being interpreted or not doesn't really matter - I'm sure C++ and other compiled languages are perfectly capable of parsing data from a Python file.
wvmarle:
It being interpreted or not doesn't really matter - I'm sure C++ and other compiled languages are perfectly capable of parsing data from a Python file.
But not at compile time 
...R
Python regular expressions to extract constants from a C++ header file. (For simple constants this would be my choice.)
Compile the C++ constants into a DLL / SO with an API for querying the constants. From the C++ side the code is trivial (just call the API). From the Python side this should make the code trivial...
The meta-question is "why?" Just do the whole thing in one or the other. Or turn your C++ code into a Python module (that is how Python itself is structured).
Python and C++ work well with: JSON, XML, INI, and various other simple text files. Any of those would make a fine choice for constants.
I'm a big fan of Firebird. Put the constants in a relational database with complete transaction control (including snapshot!).
If placed in an external file it'd be much easier to reconfigure the device, no need for recompilation if you want to just change a value.
Ah. I misunderstood this part...
Delta_G:
...one end is written in C++ for the Arduino...
In which case we are discussing the on-wire protocol between an Arduino and a PC.
How many command strings?
I have a suggestion: Do not use #define / use const.
From the Python perspective, with #define, you will either have to deduce the datatype or go without that information. In addition, if you add a #define that is not a well formed constant there is a good chance your parser will go haywire.
const not only provides name, datatype, and value, it also has a much more strict syntax which should make parsing nearly trivial.
Huh. I just realized that you can add the constants to your running Python as first-class variables. Got to love self-modifying code.
The language tries to make it so you, the developer, normally do not have to care. But there is a difference between 17 (exact) and 17.0 (estimate). That difference can sometimes be important; even in Python.
You can run code through the C pre-processor to generate python-compatible include files (essentially defining a meta-language for defining your constants.)
#ifdef PYTHON
#define COMMAND(name, string) name=string
#else // C, C++, etc
#define COMMAND(name, string) const char name[] = string;
#endif
COMMAND(dial, "ATDT")
COMMAND(hangup, "ATH")
COMMAND(answer, "ATA")
BillW-MacOSX-2<4993> avr-cpp -P -DPYTHON constants.h
dial="ATDT"
hangup="ATH"
answer="ATA"
BillW-MacOSX-2<4994> avr-cpp constants.h
1 "constants.h"
1 ""
1 ""
1 "constants.h"
const char dial[] = "ATDT";
const char hangup[] = "ATH";
const char answer[] = "ATA";
Note that cpp won't preserve indentation, so you'll be somewhat limited as to where the pre-processed output can be included in a python program...
Clever. I like it. That can just be an extra step in building the C++ image.
(I wonder what it means that I've used a very similar technique ... uh ... more than a year ago and had completely forgotten about it.)
It does when parsing variables and some are character strings and others are numerical values... You can parse them all as string, but doing maths with strings doesn't really work well, even in Python.
westfw:
You can run code through the C pre-processor to generate python-compatible include files (essentially defining a meta-language for defining your constants.)
What advantage would that have compared to getting the Python code to read a .h file?
What might the output of the pre-processor look like, in comparison to what would be in the .h file?
To quote Reply #10
Cause the Arduino won't run Python and it's much easier to write the Pc side that way
why go to the trouble of using C pre-processor stuff to do something when it is easier to do the same thing in Python?
IMHO C pre-processor stuff is even more opaque than C/C++
...R
What advantage would that have compared to getting the Python code to read a .h file?
Because the processed file would be read by the (presumably well optimized) compiler, rather than needing to be parsed by user-written code. You could (at least theoretically) do more complex pre-processor operations.
What might the output of the pre-processor look like, in comparison to what would be in the .h file?
I did give an example; I just had it come out to a bunch of python assignment statements.
IMHO C pre-processor stuff is even more opaque than C/C++
Well; yeah. But it's native to the C program, AND that is what would make it difficult for python to parse correctly without pre-processing.
westfw:
I did give an example;
I had a hunch that that was what the second piece in Reply #16 was. But it seems even more abstruse than the first piece
...R
Why not create a special .h file for the items that you want Python to use? And only put in it #defines in a style that is easy to parse in Python.
An Arduino program could read several .h files of which one is the file with the shared Python data.
Another option might be to get Python to write the .h file in the first place. That way you could have any level of C++ complexity you want because Python would not have to parse it.
...R
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.