minesworld
commented
1 month ago That means that CPythonAPI must be public. No problems - we are all grown up Python developers :-)
These PyXxxxRaw() calls would go away. Maybe it should be
CPython.Raw
so the calls could in be used as
v = Raw.PyXxxx(intptr)
or
v = Raw.PyXxxx(pyObject.ptr)
without interfering the usage of the same name in other classes.
PyObject would define
public IntPtr ptr=> handle;
If we provide the most Raw. calls possible - even if not used yet in the upper layers of CSnakes - will that be a problem regarding load times etc. ?
First some word about my pesonal background: around MacOS X 10.5 I've written a zero-overhead CPython/Objective-C bridge. Its simple "magic": putting an Objective-C class pointer at the front of PyObject definition in Python.h and some modifications to the CPython interpreter. I had even imlemented KeyValueObservation bindings onto CPython objects which were faster than Apples... Too bad Apple made changes to the Objective-C runtime trying to make it an automatic garbage collected language, which turned out garbage...
My approach is always: native GUI, bridges for ease of developing the "business logic". And this project looks really promising in that regard.
I understand that from your (Tony) standpoint the beauty of CSnakes is its ability to generate the C# sources for ease of use.
For me - its the "layered" approach and not trying to do things which shouldn't be done (like hybrid objects, running the Windows message pump from Python etc.).
But: CSnakes "layout" is confusing and it might help not only me to understand the "inner workings" better if it is cleaned up but also others which might use CSnakes in their preferred way and participate in developing CSnakes...
CSnakes.Runtime.CPython.CPythonAPI is it that really ??
No - its a mixture of CPythonAPI and what might be called CPythonSharp.
It took some time for me figuring out that CSnakes uses two types of representions:
My suggestion:
the CPythonAPI should only include code which uses nint and makes no conversions of dotnet objects. Such strings would be supplied at byte * to the UTF-16 (or UTF-8 buffers on some parts)...
CPythonSharp is the part which does the conversions and sits ontop of the CPythonAPI
If done right we should be able to take CPython C code and rewrite that in C# using the CPythonAPI just by using nint instead of PyObject ...
Beside the GIL and Python thread state calls , all other code in CPythonAPI and CPythonSharp should asume that Python thread state is ready and the or a GIL is aquired... Its the callees reponsibilty to ensure that.
While this refactoring is some work, it has direct benefits:
and
Think about that - instead of people asking you a feature, they could try to implement it themselves easily...
As CPythonSharp translates to and from dotnet objects, it should have ability to let the developer use different string translator functions. If someone has a working CPython using UTF-16, no problem with CSnakes then...
The documentation should make clear what parts to use when and provide an exmample how to rewrite C code from "ground up" to the dotnet object level.
As I'm suggesting this - I'm will do that as good I'm able too. You just have to think about the new layout and names etc. .