Row does not support string-key indexing

[dlevy-msft-sql]

Summary

In mssql-python 1.6.0, Row no longer supports string-key indexing (row["ColumnName"]). This worked in 1.5.0 and is not called out as a breaking change in the v1.6.0 release notes.

Repro

import mssql_python

conn = mssql_python.connect("<your conn str>")
cur = conn.cursor()
cur.execute("SELECT 1 AS ProductID, 'foo' AS Name")
row = cur.fetchone()

print(row[0])           # works
print(row.ProductID)    # works (attribute access)
print(row["ProductID"]) # TypeError on 1.6.0; worked on 1.5.0

Output on 1.6.0

1
1
Traceback (most recent call last):
  File "probe.py", line N, in <module>
    print(row["ProductID"])
          ~~~^^^^^^^^^^^^^
TypeError: list indices must be integers or slices, not str

Versions

• mssql-python 1.6.0 (verified via pip show mssql-python)
• Python 3.14 on Windows
• Server: Fabric SQL endpoint (not relevant; reproes with any SELECT ... AS Name)

The same script returns 1 on 1.5.0.

Why this matters

1. Silent regression. The exception message (list indices must be integers or slices) reads like a Python typo, not a deliberate API change. Users will spend time debugging their query and column aliases before they suspect the driver.
2. Not in release notes. The v1.6.0 notes list 1 enhancement and 6 bug fixes, none of which mention Row access semantics or list any "Breaking Changes" section. v0.14.0 set the precedent that breaking changes get their own section and migration notes — v1.6.0 should follow that convention.
3. Public documentation uses this pattern. The official mssql-python quickstart on Microsoft Learn currently shows print(f"Inserted Product ID : {result['ProductID']}") (source). Anyone following the quickstart on 1.6.0 hits this on the last code block. (A docs fix to use attribute access is already staged in our v1.6.0 doc PR, but the broader user base relying on row["col"] in their own code is the real concern.)
4. Attribute access isn't a complete substitute. row.ColumnName only works when the column alias is a valid Python identifier. For aliases with spaces, hyphens, reserved words, or computed/unnamed columns, string-key access was the only ergonomic option short of positional indexing.

Ask

Either:

1. Restore Row.__getitem__(str) (preferred — matches pyodbc Row semantics and 1.5.0 behavior), or
2. Document this as a breaking change in the v1.6.0 release notes with a migration recipe (switch to attribute or positional access; for non-identifier column names, suggest dict(zip([d[0] for d in cur.description], row)) or similar).

Happy to send a PR for either path if it would help.

Related context

• Row was made a public export in 1.5.0 (FEAT: Export Row class and refactor __init__.py (#270) #474), so this is the first release where users were explicitly encouraged to depend on the Row type.
• Searched existing issues for "Row indexing", "Row getitem", and result['ProductID']; no duplicates found (only cursor.execute() with reset_cursor=False raises ProgrammingError: Invalid cursor state #506 which is the unrelated reset_cursor=False fix).

[github-actions]

Hi @dlevy-msft-sql, thank you for opening this issue!

Our team will review it shortly. We aim to triage all new issues within 24-48 hours and get back to you.

If you have additional information to share, please feel free to update the issue.

Thank you for your patience!

[jahnvi480]

Thanks for filing this, @dlevy-msft-sql . I investigated thoroughly and here's what I found:

This is a missing feature, not a v1.5.0 → v1.6.0 regression. String-key indexing ( row["col"] ) was never implemented in any published release. I verified by installing v1.4.0, v1.5.0, and v1.6.0 from PyPI into a clean virtual environment and running the same repro:

# All three versions produce the same result:
mssql-python 1.4.0 → row["ProductID"] => TypeError: list indices must be integers or slices, not str
mssql-python 1.5.0 → row["ProductID"] => TypeError: list indices must be integers or slices, not str
mssql-python 1.6.0 → row["ProductID"] => TypeError: list indices must be integers or slices, not str

I also audited Row.__getitem__ across every tagged release (v0.6.0-preview through v1.6.0) and every commit that touched row.py (~50 commits). In all cases, __getitem__ was:

def __getitem__(self, index):
    return self._values[index]

No string-key handling was ever present.

However, the ask is completely valid. The Microsoft Learn quickstart shows result['ProductID'], pyodbc's Row supports row["col"], and attribute access (row.col) doesn't work for non-identifier column names (spaces, hyphens, reserved words, unnamed columns). String-key access should be supported.

I'll be raising PR to fix this issue.

[dlevy-msft-sql]

@jahnvi480 you're right and I owe you a correction.

When I filed this yesterday I said the regression was confirmed against 1.5.0. That was wrong. Claude Opus 4.7 claimed that it had tested the code but it hadn't actually run the failing block against 1.5.0. The "1.5.0 baseline" was a doc-harness run from April against a docs PR branch that had already changed the line to result.ProductID (attribute access), so the block passed for the wrong reason. When 1.6.0 ran against unfixed main and saw TypeError, it appeared as a 1.5.0 → 1.6.0 regression. It isn't.

I've now actually tested 1.5.0 in a clean venv against a live database:

VERSION: 1.5.0
by_int: 1
by_str failed: TypeError list indices must be integers or slices, not str
attr: 1

Same TypeError as 1.6.0. Confirmed in source: Row.__getitem__ in both v1.5.0 and v1.6.0 tags is def __getitem__(self, index: int) -> Any: return self._values[index] over a list. Your audit across earlier tags is correct: string-key subscript on Row has never been supported on any released version.

So please reframe the issue however is most useful:

• Not a 1.6.0 regression. No breaking-change note needed in the release notes.
• The Microsoft Learn quickstart from June 2025 currently has the failing result['ProductID'] line. The fix (switch to result.ProductID) is in MicrosoftDocs/sql-docs PR #36961.
• Still a reasonable feature request if your team wants to consider it: subscript-by-name matches pyodbc's Row semantics, and attribute access doesn't cover column names with spaces, hyphens, reserved words, or unnamed expression columns. Not asking you to commit to it, just flagging the use case.

Thanks for the careful cross-tag check. That's what caught the error.