> I think that generating the python code makes the most sense. The body of > the code can still defer to the dynamically generated object, since it's not > available until runtime anyway, but the user no longer has to resort to using > lambdas because of the deferred bindings.
Could you ellaborate for why you need to use lambdas? > I imagined it would work like a regular module: > > >>> import vpp_papi.plugins.map as map > >>> dir(map) > ... > >>> help(map) > > vppapigen would generate stubs such as: > > vpp_papi.plugins.map.py: > > def map_add_domain(client_index: u32, context: u32, ip6_prefix: IPV6Network, > ip4_prefix: IPV6Network, ip6_src: IPV6Interface, ea_bits_len : u8, > psid_offset : u8, psid_length : u8, mtu: u16, tag : str ) -> i32: > """docstring from .api block comment > """ > <return <VppApiDynamicMethodHolder> > > > The user, of course, still needs to connect to VPP for their code to run. > > but the typedefs could become data classes and the encode/decode methods in > the test code become unnecessary. What are you thinking about regarding the encode/decode in tests? E.g. for the IP address ones, they can just be deleted. Without any changes to PAPI... > vl_api_ip_ecn_t.IP_API_ECN_NONE could become ip_ecn.NONE > > The IDE's could then provide type checking and auto completion. (So one would > know that NONE was an option without referring to the sources.) > > We would need to play around with it to see how well it works. That seems like a good idea. Let me give you a quick Python plugin for vppapigen that does this. The packaging is going to be a challenge I guess. Best regards, Ole
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18079): https://lists.fd.io/g/vpp-dev/message/18079 Mute This Topic: https://lists.fd.io/mt/78229638/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
