You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Originally I was going to generate Python IDL code "on the fly", but I got caught up in the idea that users should be able to look at the generated code and easily understand it, sorta like they should theoretically be able to do with C++ code (although tao_idl code looks terrible in practice).
The problem is that IDL/C models of including and forward declaration don't perfectly fit with the Python import system. This wouldn't be a problem but I want there to be default values on struct fields and that doesn't seem like it's easy to do. The result was circular import issues that I couldn't get around.
For now I'm returning to the dynamic type route, at least until I reach the 0.1, where I get basic_test to be functional, then I would like to reassess the feasibility of generating normal Python code.
The text was updated successfully, but these errors were encountered:
Today I learned how to properly forward reference Python Type Annotations:
from __future__ importannotationsfromtypingimportTYPE_CHECKINGifTYPE_CHECKING:
from .DomainParticipantimportDomainParticipantclassTopic:
def__init__(self, participant: DomainParticipant):
pass
This would solve one of problem points I had with generating a straightforward and type annotated mapping, which is part of my ideal goal for the mapping:
It should be indistinguishable from a normal Python package
It should be defined in straightforward Python
It should support type annotations
It should support default values for structs
Another thought I had before was writing the type mapping completely in the CPython C API. It would obviously not be in Python, but it might be better than my current approach.
- Make pyopendds.dev.itl2dev an entry point for itl2py
- Rewrote itl2py to use Jinja templates for all the gernated files.
- Generate straightforward Python from ITL. See
https://github.com/iguessthislldo/pyopendds/issues/2 for details.
Originally I was going to generate Python IDL code "on the fly", but I got caught up in the idea that users should be able to look at the generated code and easily understand it, sorta like they should theoretically be able to do with C++ code (although tao_idl code looks terrible in practice).
The problem is that IDL/C models of including and forward declaration don't perfectly fit with the Python import system. This wouldn't be a problem but I want there to be default values on struct fields and that doesn't seem like it's easy to do. The result was circular import issues that I couldn't get around.
For now I'm returning to the dynamic type route, at least until I reach the 0.1, where I get basic_test to be functional, then I would like to reassess the feasibility of generating normal Python code.
The text was updated successfully, but these errors were encountered: