Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IDL to Python Implementation #2

Open
iguessthislldo opened this issue Dec 24, 2019 · 2 comments
Open

IDL to Python Implementation #2

iguessthislldo opened this issue Dec 24, 2019 · 2 comments
Milestone

Comments

@iguessthislldo
Copy link
Member

iguessthislldo commented Dec 24, 2019

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.

@iguessthislldo iguessthislldo added this to the 0.2 milestone Dec 24, 2019
@iguessthislldo
Copy link
Member Author

Commit in question is ec2cd86

@iguessthislldo
Copy link
Member Author

Today I learned how to properly forward reference Python Type Annotations:

from __future__ import annotations
from typing import TYPE_CHECKING
if TYPE_CHECKING:
    from .DomainParticipant import DomainParticipant

class Topic:
    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.

iguessthislldo referenced this issue Jan 13, 2020
- 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant