pandas 3.0: three remaining set_index(<str column>.values) calls still raise TypeError (custom-labels paths) #574

Description

#561 (v4.3.1) fixed the module-level ann_class_table.set_index(...) that crashed import wfdb under pandas 3 string semantics — thank you! However, three sibling patterns remain in wfdb/io/annotation.py (checked on main and in the v4.3.1 sdist), all passing a string column's .values directly as set_index keys:

• line ~728 (label_triplets_to_df region):

  custom_labels.set_index(custom_labels["label_store"].values, inplace=True)

• line ~1325 (set_custom_labels / DataFrame custom_labels path):

  self.custom_labels.set_index(self.custom_labels["label_store"].values, inplace=True)

• line ~1347 (get_contained_labels region):

  label_map.set_index(label_map["symbol"].values, inplace=True)

With pandas' new string dtype (pandas 3.0, or 2.x with pd.set_option("future.infer_string", True)), Series.values is an ArrowStringArrayNumpySemantics, which DataFrame.set_index rejects:

TypeError: The parameter "keys" may be a column key, one-dimensional array, or a list containing only valid column keys and one-dimensional arrays.

These are runtime paths (annotation objects with custom labels), so import wfdb now succeeds, but the custom-label functionality still breaks once pandas 3 is the default.

Reproduce

import pandas as pd
pd.set_option("future.infer_string", True)
import wfdb
from wfdb.io.annotation import Annotation
# any path that reaches set_custom_labels / label_triplets_to_df with a
# DataFrame of custom labels -> TypeError above

(Versions: pandas 2.2.3 with the option / pandas 3.0; wfdb 4.3.1 and current main.)

Suggested fix

Pass the column label instead of the array — identical semantics on every pandas version (the keys are the column's values either way):

custom_labels.set_index("label_store", inplace=True)
self.custom_labels.set_index("label_store", inplace=True)
label_map.set_index("symbol", inplace=True)

Happy to open a PR with these three one-line changes if useful.

(Context: downstream ECG libraries, e.g. DeepPSP/torch_ecg, still pin pandas < 3 partly on this; a fix would help unblock the pandas-3 migration.)