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
Per discussion in #2787 (comment) if an atom is dynamically defined in C++, then the python bindings should automatically "learn about it", and make it available to the programmer. This seems to be interesting mostly if either #2789 or if opencog/atomspace-rocks#6 is implemented See also #2791.
The text was updated successfully, but these errors were encountered:
New type should be added into types collection. Right now it happens automatically if opencog.atomspace module is loaded after new type is added. types collection can be updated manually calling get_refreshed_types method but in such case previously imported types reference will not be updated. In both cases types are loaded from NameServer and added into new types class as properties. To make types more reactive we could create a subscription on NameServer events and update types when collection of types is changed using NameServer.
Type constructors for new types. Python Atomspace class has add_node and add_link methods to add new atoms using any type passed. So this part is probably solved.
One issue I faced using custom types in Python is that NameServer cuts Link and Node suffix and creates additional short names for atoms. As result one cannot use names like X and XLink at the same time because NameServer cuts Link from XLink and confuses both types. But it is probably separate issue.
Per discussion in #2787 (comment) if an atom is dynamically defined in C++, then the python bindings should automatically "learn about it", and make it available to the programmer. This seems to be interesting mostly if either #2789 or if opencog/atomspace-rocks#6 is implemented See also #2791.
The text was updated successfully, but these errors were encountered: