This is the kind of question you should be answering yourself. The skills learned doing so will make you a better programmer.
The first question you should have asked yourself is "Why is this thing printing like a list?" It is actually printing like a tuple, but that isn't important for the purposes of this discussion.
When you have questions about the representation used by the print command the first thing you should do is verify that you know the type of the object. If you have a debugger set a breakpoint and ask. If not, add a print statement
print(type(records), records)
This print statement would tell you that records is a tuple and it would print the tuple. If there is only one match for the query I would expect to see something like this:
Output:
<class 'tuple'> (('A. 2',),)
To find out what is in the tuple I alter the print statement.
print(type(records), records, type(records[0]), records[0])
Output:
<class 'tuple'> (('A. 2',),) <class 'tuple'> ('A. 2',)
Another tuple. I change the print one last time to get the result.
print(type(records), records, type(records[0]), records[0], type(records[0][0]), records[0][0])
Output:
<class 'tuple'> (('A. 2',),) <class 'tuple'> ('A. 2',) <class 'str'> A. 2
Now I know that the cursor.fetchall() command returns a tuple of tuples, and the inner tuples contain the query result. I wonder if this is always the case or a peculiarity of my query so I reference the documentation.
Quote:fetchall()
Fetches all (remaining) rows of a query result, returning a list. Note that the cursor’s arraysize attribute can affect the performance of this operation. An empty list is returned when no rows are available.
from
https://python.readthedocs.io/en/latest/...lite3.html
Hmmm. Not all that useful. The docs says it returns a list, not a tuple. This kind of discrepancy happens quite often so I always try to verify what I read. Next I might try a query that returns multiple results or different types of results. I would analyze the return value in each case and improve my understanding of the tool I was using until I was at least proficient in it's use. This would slow my initial development, but a little study at the front end reaps great rewards in and overall reduction in development time and a huge reduction in debugging and testing time (because you now know enough to quickly spot errors and know what can go wrong so you can write effective tests).