On 9/25/20 12:48 AM, Karsten Hilbert wrote:
> Adrian,
>
> thanks for tracing my misunderstanding. I should have
> confirmed my suspicion here:
>
>> https://github.com/psycopg/psycopg2/blob/fbba461052ae6ebc43167ab69ad91cadb7914c83/lib/extras.py
>
>> class DictRow(list):
>
>> def __getitem__(self, x):
>> if not isinstance(x, (int, slice)):
>> x = self._index[x]
>> return super(DictRow, self).__getitem__(x)
>>
>> So if the value passed to __getitem__() is a integer or slice it does a list
>> index.
>
> Indeed. I wonder whether that should be mentioned in the
> psycopg2 docs somewhere as it might be considered to violate
> the Principle Of Least Astonishment.
>
> Or rather, this issues seems unfortunate fallout from python3:
>
> In py2 one *had* to do DictRow.keys() to iterate over the
> keys. In py3
>
> for key in DictRow:
>
> is the suggested idiom for that which, however, iterates over
> DictRow as a list (as it always did).
>
> DictRow.keys() still exists on dicts in py3 (and is not
> deprec(i?)ated to my knowledge) but now returns a memoryview
> (dict_keys, that is) rather than a list, which brings with it
> its own set of issues (dict and keys "list" are not
> independant objects anymore).
>
> So, neither using py2's
>
> for key in DictRow.keys():
>
> under py3 nor changing to py3's
>
> for key in DictRow: # beep: variable wrongly named
>
> leads to fully equivalent code. So this is a py2/py3 Gotcha
> in psycopg2.
Well you can do, borrowing from previous example:
for ky in r0._index:
print(ky)
line_id
category
cell_per
ts_insert
ts_update
user_insert
user_update
plant_type
season
short_category
for ky in r0._index:
print(r0[ky])
5
H PREM 3.5
18
None
2004-06-02 15:11:26
None
postgres
herb
none
HP3
Where _index is a substitute for *.keys().
>
> Not that I complain, but worth a mention in the DictRow docs
> somewhere ?
>
> Karsten
> --
> GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com