Set Table primary key when copied indices are attached - #20362

Set primary_key whenever a new Table receives copied indices

1. How a table gets indices without a primary key

col_copy(col, copy_indices=True) deep-copies a column's SlicedIndex objects and re-points them at the new column, so Table([t["a"]]) and t[["a", "b"]] (which goes through the same constructor) produce columns with live, valid indices. Table._init_from_cols already walks these to deduplicate index objects shared between columns of a multi-column index, but nothing sets self.primary_key, which Table.__init__ initialised to None. Only add_index() sets it, and only when the table has no indices yet.

TableLoc._get_index_id_and_item uses self.table.primary_key as the index id, so None reaches TableIndices.__getitem__, which falls through to list.__getitem__(None).

2. Implementation

Table._init_from_cols, after the existing deduplication loop that fills index_dict (keyed by index id in column order):

if self.primary_key is None and index_dict:
    self.primary_key = next(iter(index_dict))

The first index in column order becomes primary, matching add_index(). This covers Table([indexed_col]), QTable(table_with_indices), and any other constructor path that copies indices. When the input is a Table, __init__ has already copied data.primary_key, so this only fills in a missing key and never overrides one.

Table.__getitem__, in the list-of-column-names branch:

if self.primary_key in [index.id for index in out.indices]:
    out.primary_key = self.primary_key

A reordered slice such as t[["b", "a"]] on a table with indices on both columns would otherwise get ("b",) from the rule above; this keeps the parent's ("a",). The membership test against the slice's actual indices means a stale key (one whose index was dropped by the slice, or one left behind by remove_indices, see below) is never propagated. None in [...] is False, so an unindexed parent is unaffected.

3. Things deliberately left alone

• A multi-column index whose other column is dropped by the slice (t.add_index(["a", "b"]); t[["a", "c"]]) now becomes the primary key. .loc[1] on it raises IndexError: tuple index out of range, but the unsliced t.loc[1] raises the identical error for a composite index, so this is consistent rather than a regression. Filtering such indices out would be a separate policy change.
• Table.remove_indices promises in its docstring to reassign the primary key when the primary index is removed but never does, leaving a stale key. That is pre-existing and not touched here; the __getitem__ guard above just avoids spreading it.
• Table(t, copy_indices=False) already gives a table with a primary_key but no indices. Unchanged.

4. Tests

test_index.py::test_primary_key_from_copied_indices (fails on main, passes here) checks: t[["a", "b"]] has one index and primary_key == ("a",) with working .loc and .iloc; t[["b"]] has no index and no key; Table([t["a"]]) has a working .loc and repr(t4.loc) no longer raises; with a second index on b, t[["b", "a"]] keeps ("a",), t[["b"]] gets ("b",), and Table([t["b"], t["a"]]) gets ("b",).

python -m pytest astropy/table/tests/test_index.py astropy/table/tests/test_df.py docs/table/indexing.rst on this branch: 710 passed, 56 skipped. The full astropy/table, astropy/io/misc and ECSV suites were run with this change applied together with #20361 (6949 passed, 89 skipped, 23 xfailed), not separately. pre-commit run --files on all changed files passes.

5. Backwards compatibility

No API change, but one visible behavior change: to_pandas() (and to_df()) use a single-column primary key as the DataFrame index by default, so t[["a", "b"]].to_pandas() now returns a frame indexed by a with only b as a column, where on main a stayed a regular column with a RangeIndex. That is what the unsliced t.to_pandas() already did, and to_pandas(index=False) restores the old output. Tables without indices, row slices, and tables built through add_index() are bit-for-bit unchanged.

Changelog fragment: docs/changes/table/20362.bugfix.rst.