Re: [capi-sig] Creating type object dynamically in run-time
Mateusz Loskot, 10.05.2012 18:58:
Interesting. So you're reflecting on a C/C++ API to dynamically export it to Python space? Then I guess that your internal binding code is also rather generic, right? It won't be able to call the application code directly, for example, if it doesn't know the API at compile time.
I can not use Cython, nor I can use tools like SWIG, Boost.Python. The (C)Python is the only tool I can use.
Also interesting. I wonder who would notice with which tool you have written your source code once it's compiled...
Stefan
On 10 May 2012 18:58, Stefan Behnel <python_capi@behnel.de> wrote:
Yes, roughly, that's the idea.
Then I guess that your internal binding code is also rather generic, right?
Let's describe it in simplified way: There are intermediate Python extensions defined which bridge communication between the C++ world and dynamically generated Python classes. For instance, there is a car and car engine. Now, there is 'base car engine' which defines common protocol for possible behaviours. The 'base car engine" is specified and known at compile time, Next, there is variety of kinds of engines where each provide subset of the well-specified behaviours. Polymorphism, indeed. So, those specific engines are dynamically generated in run-time and they communicate with car through the statically defined 'base car engine' protocol.
It won't be able to call the application code directly, for example, if it doesn't know the API at compile time.
Yes, so there are 'base' extension types defined statically.
I guess nobody. It's just I had not known Cython before I started. Now, I have most of my implementation ready. I also wouldn't want to introduce new dependencies and as long as Cython is not guaranteed to be 100% compatible drop-in replacement for Python 3.2+, then I'm afraid I can't use it. The FAQ does not confirm it is http://wiki.cython.org/FAQ#IsCythonaPythonimplementation.3F
But, I will keep an eye on Cython, it looks & feels a clever and useful idea. and even for "he's stuck his head in C++" hacker :D
Stefan, I appreciate your help. I wish I found CAPI-SIG list earlier!
Best regards,
Mateusz Loskot, http://mateusz.loskot.net
On 10 May 2012 18:58, Stefan Behnel <python_capi@behnel.de> wrote:
Yes, roughly, that's the idea.
Then I guess that your internal binding code is also rather generic, right?
Let's describe it in simplified way: There are intermediate Python extensions defined which bridge communication between the C++ world and dynamically generated Python classes. For instance, there is a car and car engine. Now, there is 'base car engine' which defines common protocol for possible behaviours. The 'base car engine" is specified and known at compile time, Next, there is variety of kinds of engines where each provide subset of the well-specified behaviours. Polymorphism, indeed. So, those specific engines are dynamically generated in run-time and they communicate with car through the statically defined 'base car engine' protocol.
It won't be able to call the application code directly, for example, if it doesn't know the API at compile time.
Yes, so there are 'base' extension types defined statically.
I guess nobody. It's just I had not known Cython before I started. Now, I have most of my implementation ready. I also wouldn't want to introduce new dependencies and as long as Cython is not guaranteed to be 100% compatible drop-in replacement for Python 3.2+, then I'm afraid I can't use it. The FAQ does not confirm it is http://wiki.cython.org/FAQ#IsCythonaPythonimplementation.3F
But, I will keep an eye on Cython, it looks & feels a clever and useful idea. and even for "he's stuck his head in C++" hacker :D
Stefan, I appreciate your help. I wish I found CAPI-SIG list earlier!
Best regards,
Mateusz Loskot, http://mateusz.loskot.net
participants (2)
-
Mateusz Loskot -
Stefan Behnel