{"action":"created","issue":{"url":"https://api.github.com/repos/MatthieuDartiailh/pyclibrary/issues/12","labels_url":"https://api.github.com/repos/MatthieuDartiailh/pyclibrary/issues/12/labels{/name}","comments_url":"https://api.github.com/repos/MatthieuDartiailh/pyclibrary/issues/12/comments","events_url":"https://api.github.com/repos/MatthieuDartiailh/pyclibrary/issues/12/events","html_url":"https://github.com/MatthieuDartiailh/pyclibrary/issues/12","id":87685164,"number":12,"title":"Generalization of backend API","user":{"login":"mrh1997","id":1482077,"avatar_url":"https://avatars.githubusercontent.com/u/1482077?v=3","gravatar_id":"","url":"https://api.github.com/users/mrh1997","html_url":"https://github.com/mrh1997","followers_url":"https://api.github.com/users/mrh1997/followers","following_url":"https://api.github.com/users/mrh1997/following{/other_user}","gists_url":"https://api.github.com/users/mrh1997/gists{/gist_id}","starred_url":"https://api.github.com/users/mrh1997/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mrh1997/subscriptions","organizations_url":"https://api.github.com/users/mrh1997/orgs","repos_url":"https://api.github.com/users/mrh1997/repos","events_url":"https://api.github.com/users/mrh1997/events{/privacy}","received_events_url":"https://api.github.com/users/mrh1997/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-06-12T10:33:45Z","updated_at":"2015-06-29T00:40:03Z","closed_at":null,"body":"While reasoning about my RPC library's design which shall be based on the parser of pyclibrary I came to the conclusion that your (really nice) concept of pluggable backends would be a perfect match for my library.\r\n\r\nBut according to my (yet) limited knownledge of the backend it has a drawback: it i too specialized for the current purpose. In fact it does **two** things:\r\n* (dynamicially) generate python ctype objects from a C header file\r\n* provide (really useful) extensions to ctypes (primarly the CallResult class)\r\n\r\nIf these features would be modularized and the python ctype object generation would be generalized to a static interface file generator, the range of applications of the library would be drasticially extended:\r\n* It would be possible to write a backend for **any language** and for **any ffi-library**!!! \r\n* The extensions (CallResult) could be swapped out into a separate module. This means you could use it even if you do not want to use CParser/CLibrary (i.e. if you do not have a C header file, but want to benefit from this Module either)\r\n* projects which need to access a C library could do this easily without the need to add pyclibrary as dependency (pyclibrary would transform the header file once to a python module, which is added the project)\r\n\r\nMy idea of the static interface generator is basicially a template engine which gets the AST from the CParser and outputs a interface definition for a specific language/ffi-library/parametrization. If one still needs dynamic interface object generation (i.e. if the according C header file is not static; a use case which should barely occur), one could still generated the interface definition module as in-memory string object run ```exec()``` on this string.\r\n\r\nTo come to an example: The current backend would be replaced by a template, that converts the following header file:\r\n```C\r\nstruct sample_struct_t {\r\n   int * a;\r\n} ;\r\nvoid sample_func(struct sample_struct_t * x);\r\n```\r\n\r\nto the follong python module:\r\n\r\n```python\r\nimport ctypes\r\n\r\nlib = ctypes.CDLL('...')\r\n\r\nclass sample_struct_t(ctypes.Structure):\r\n    _fields_ = [(\"a\", ctypes.POINTER(ctypes.c_int))]\r\n\r\nlib.sample_func.restype = ctypes.c_void\r\nlib.sample_func.argtypes = [POINTER(sample_struct_t)]\r\n```\r\n(This example generated a python module without using CallResult. But of course it would also be possible to integrate CallResult into the generated module; would depend on the parametrization of the code generator)\r\n\r\n@MatthieuDartiailh: What do you think about it? Regarding all the work to be done: as I need to do it anyway (for my RPC library, which has to compile a C-wrapper from C Headerf files) I would be glad to do it as part of pyclibary instead of my own project."},"comment":{"url":"https://api.github.com/repos/MatthieuDartiailh/pyclibrary/issues/comments/116363661","html_url":"https://github.com/MatthieuDartiailh/pyclibrary/issues/12#issuecomment-116363661","issue_url":"https://api.github.com/repos/MatthieuDartiailh/pyclibrary/issues/12","id":116363661,"user":{"login":"mrh1997","id":1482077,"avatar_url":"https://avatars.githubusercontent.com/u/1482077?v=3","gravatar_id":"","url":"https://api.github.com/users/mrh1997","html_url":"https://github.com/mrh1997","followers_url":"https://api.github.com/users/mrh1997/followers","following_url":"https://api.github.com/users/mrh1997/following{/other_user}","gists_url":"https://api.github.com/users/mrh1997/gists{/gist_id}","starred_url":"https://api.github.com/users/mrh1997/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mrh1997/subscriptions","organizations_url":"https://api.github.com/users/mrh1997/orgs","repos_url":"https://api.github.com/users/mrh1997/repos","events_url":"https://api.github.com/users/mrh1997/events{/privacy}","received_events_url":"https://api.github.com/users/mrh1997/received_events","type":"User","site_admin":false},"created_at":"2015-06-29T00:40:02Z","updated_at":"2015-06-29T00:40:02Z","body":"Unfortunately I found no Jinja2 compatible mini templating engine.\r\n\r\nTiten (https://code.google.com/p/titen/) looks fairly promising, as it has only ~200 lines of code.\r\n\r\nBut I prefer to use Tempita (http://pythonpaste.org/tempita/) as it is still not too big (~1200 LOCs) and provides much more power."}}