To reproduce, run the following program:

import sqlite3
conn = sqlite3.connect(':memory:')
conn.row_factory = sqlite3.Row
print(conn.execute("SELECT 'John' AS name, 42 AS salary").fetchone())

It prints '<sqlite3.Row object at 0xffffffffffffff>'.
It would be nice if it printed something like "sqlite3.Row(name='Smith', saraly=42)" instead.
It wouldn't satisfy the 'eval(repr(x)) == x' property, but it's still better than nothing.

If the maintainers agree this is useful, I'll implement.

Enhancements only go into future versions.

This would have the same pluses and minuses as printing dicts in full.  I don't know the general feeling about expanding the classes printed out like this, or whether Gerhard is still active.  If you don't get responses within a few days, you might try posting to python-ideas list.

+1 from me.  We're already made regular expression match objects less opaque and that has been useful.  There's no need for a python-ideas discussion for this.

If a repr doesn't round-trip, we generally put it angle brackets (see PEP 8):

    >>> re.search(r'([a-z]+)(\d*)', 'alpha7')
    <re.Match object; span=(0, 6), match='alpha7'>

The Row object access style uses square brackets and has a keys() method.  That suggests a dict-like representation would be intuitive and match how Row objects are used:  ro['salary'] and ro.keys().

Putting those two ideas together we get:

    <sqlite3.Row object; {'name': 'John', 'salary': 42}>

Note the OP's suggestion for keyword argument style doesn't make sense for two reasons: 1) Row objects don't allow attribute access (i.e. ro.name is invalid) and 2) the field names are not required to be valid Python identifiers (i.e. ro['class'] is possible but ro.class is syntactically invalid because "class" is a keyword).

While the proposed formats look nice for artificial inputs, the Row object can have more than two fields and the value of a field can be much longer than that. So, in practice the new repr can make the situation worse than the current repr.

I think wrapping the output of row.keys() (https://docs.python.org/3/library/sqlite3.html#sqlite3.Row.keys) with something like reprlib.recursive_repr() would work better for Row objects with several fields.

There is no need to add explicit knowledge of reprlib to the Row object or vice versa.

Those who use reprlib to limit output size will have no problem. Reprlib already truncates arbitrary reprs at the string level: https://github.com/python/cpython/blob/22bfe637ca7728e9f74d4dc8bb7a15ee2a913815/Lib/reprlib.py#L144

Those who use builtin repr() have to be prepared for the possibility of unbounded repr anyway, because all collection-like objects in Python have unbounded __repr__.

It would be annoying if some collection-like objects decided to be clever and omit parts of their regular __repr__ because they feel it's too much for the user to handle.

I have the same doubts as Berker. sqlite3.Row represents a data from a database. Databases are used in particularly for storing a large amount of data which can not be all loaded in RAM. Therefore sqlite3.Row can contain a data with a very long repr.

If you need to inspect the sqlite3.Row object, it is easy to convert it to a list. If you want to see keys together with values, it is not hard to make a list of key-value pairs or a dict: list(zip(row.keys(), row)) or dict(zip(row.keys(), row)).

If this goes forward, the maximum output size needs to be limited in some way (like what is done in reprlib).

Given Serhiy's doubts, I'm only +0 on this.  Feel free to close this if you like.  For the most part, I don't think people even look at Row objects.

1. "This patch adds too many lines of code and not enough value."
If the maintainers judge it so, I have nothing to say. You have the responsibility to keep the codebase relatively simple.

2a. "Existing programs made with the assumption that repr(row) is short (albeit useless) will break when it becomes not so short."
I have no experience maintaining popular language implementations, so I defer to your judgement on what level of backward compatibility is warranted.

2b. "New users of new repr(row) will run into problems because its size is unbounded."
I think this objection is invalid, as I explained in the comment: https://bugs.python.org/issue35889#msg336291

AFAICS, this is fixed by the attached one-liner, based on Serhiy's suggestion (based on Raymond's suggestion).


$ python3.10 test.py
<sqlite3.Row object at 0x102b91330>
$ ./python.exe test.py  # patch applied
<sqlite3.Row object at 0x10c06b600 {'number': 1, 'string': 'two', 'blob': b'\x1f'}>
$ cat test.py
import sqlite3
cx = sqlite3.connect(":memory:")
cx.row_factory = sqlite3.Row
query = """
  select
    1 as number,
    'two' as string,
    x'1f' as blob
"""
for row in cx.execute(query):
    print(repr(row))


If Berker & Serhiy approves, I'll create a PR for it.

Even better, let's keep Row as it is and just add this as an example in the docs. If a verbose repr is needed, it's easy to override __repr__.

Suggesting to either close this or add an example to the docs. Up to Berker / Serhiy.

What about a __repr__ that includes the primary key value(s) (for tables where that is defined)?  That would be useful and informative, and also generally short.

> What about a __repr__ that includes the primary key value(s) (for tables where that is defined)?

I’d rather have that as a Row method, or read-only property. It should be straight-forward to implement. SQLite provides an API for such purposes.

See:
- https://www.sqlite.org/c3ref/column_database_name.html
- https://www.sqlite.org/c3ref/table_column_metadata.html

Notice that the former is only available if SQLITE_ENABLE_COLUMN_METADATA was defined at compile time.

Let's close it as rejected. Thank you everyone for your input.