There is a feature mismatch between the python and pt frontends. In the .pt frontend you can build an array from a structure defined in the same package. For example:
package example_pkg {
// A test structure
struct test_struct {
a : scalar[4]
b: scalar[6]
}
// An array of structures
test_struct_array : test_struct[4]
}
Then these can be accessed from the python rendering as example_pkg.test_struct and example_pkg.test_struct_array.
However in the python front end you cannot easily define an array in the same way
@packtype.package()
class example_pkg:
...
@example_pkg.struct()
class test_struct:
a: Scalar[4]
b: Scalar[6]
@packtype.package()
class example2_pkg:
test_struct_array : example_pkg.test_struct[4]
This then means you need to do two imports and access them by example_pkg.test_struct and example2_pkg.test_struct_array
You can work around it with a hack:
@packtype.package()
class example_pkg:
...
@example_pkg.struct()
class test_struct:
a: Scalar[4]
b: Scalar[6]
example_pkg._pt_attach(
test_struct[4],
name="test_struct_array",
)
But its does feel fragile.
Is there an objection to adding in another decorator to define the array? This way extra functions can be added to the class which is the extremely useful feature of writing the definitions in python.
There is a feature mismatch between the python and
ptfrontends. In the.ptfrontend you can build an array from a structure defined in the same package. For example:Then these can be accessed from the python rendering as
example_pkg.test_structandexample_pkg.test_struct_array.However in the python front end you cannot easily define an array in the same way
This then means you need to do two imports and access them by
example_pkg.test_structandexample2_pkg.test_struct_arrayYou can work around it with a hack:
But its does feel fragile.
Is there an objection to adding in another decorator to define the array? This way extra functions can be added to the class which is the extremely useful feature of writing the definitions in python.