5.16. APIs (Python)

5.16.1. [Critical] Incompatibility between Python API and other APIs when using int8 type *

Communication between Python and the other supported language APIs did not occur when using an int8 type. The int8 types were incorrectly treated as characters instead of octets, leading to communication failures.

The fix for this issue included changing the type to an octet. As a result, communication will not occur between Python applications that apply the fix and Python applications that don’t have the fix, when using an int8 type.

By default, this fix is disabled for backward compatibility. To enable it, you have to unset the python_int8_730() bit (0x00000400) in the Extensible Types compliance mask.

Enabling this fix makes the Python API compliant with the OMG ‘Extensible and Dynamic Topic Types for DDS’ specification, version 1.3 but it will not communicate with Python API applications that don’t have the bit disabled.

For example, to enable the fix, you could set the Extensible Types compliance mask like this:

import rti.connextdds.compliance as compliance
mask = compliance.XTypesMask.PYTHON_INT8_730_BIT
compliance.set_xtypes_mask(
    compliance.get_xtypes_mask() & mask.flip())

See Extensible Types Compliance Mask in the RTI Connext Core Libraries Extensible Types Guide for more information.

If you want to communicate with Python APIs regardless of whether they have the fix, and/or to communicate with all the bindings, a workaround is to not propagate the TypeObject and rely on the topic name for matching:

<domain_participant_qos>
    <resource_limits>
        <type_object_max_serialized_length>0</type_object_max_serialized_length>
    </resource_limits>
</domain_participant_qos>

If the application you’re communicating with uses a version of Connext earlier than 6.0.0, the TypeCode also needs to be configured to not be propagated:

<domain_participant_qos>
    <resource_limits>
        <type_code_max_serialized_length>0</type_code_max_serialized_length>
        <type_object_max_serialized_length>0</type_object_max_serialized_length>
    </resource_limits>
</domain_participant_qos>

See DOMAIN_PARTICIPANT_RESOURCE_LIMITS QosPolicy (DDS Extension) in the Connext Core Libraries User’s Manual for more information on the type_code_max_serialized_length and type_object_max_serialized_length fields.

See Type Representation in the Connext Core Libraries Extensible Types Guide for more information on TypeCode and TypeObjects in current and previous releases.

[RTI Issue ID PY-190]

5.16.2. [Major] x64Linux Connext Python API not able to use libraries from $NDDSHOME/lib *

On x64Linux, applications using the Connext Python API and relying on libraries in $NDDSHOME/lib to, for example, load an add-on library such as the Security Plugins, failed due to an undefined symbol issue due to API incompatibility. Note that normally the Python API doesn’t load the native libraries from Nddshome.

[RTI Issue ID PY-168]

5.16.3. [Major] Exception when printing or converting a sequence of octets to string *

Trying to convert a user type containing sequences or arrays of octets to a string in the Python API may have caused a UnicodeDecodeError.

For example, given the following type in IDL:

struct MyType {
    sequence<octet> my_octets;
};

Or as defined in Python:

@idl.struct
class MyType:
my_octets: Sequence[idl.uint8] = field(default_factory=list)

The problem specifically affected the implementation of the repr methods of the types dds.Int8Seq and dds.Uint8Seq. These methods printed the elements as characters instead of integers.

Now, octet sequences are converted to strings correctly, and the elements are treated as integers instead of characters.

[RTI Issue ID PY-163]

* This bug did not affect you if you are upgrading from 6.1.x or earlier.