public inbox for [email protected]
help / color / mirror / Atom feedFrom: Rory Campbell-Lange <[email protected]>
To: Daniele Varrazzo <[email protected]>
Cc: Denis Laxalde <[email protected]>
Cc: [email protected]
Subject: Re: Latest developments in psycopg3
Date: Mon, 8 Feb 2021 15:36:16 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+mi_8YZnEuO=GAJiWnv_0Bx7_6DsL9jUcwhMxtXGqeSBgSp0A@mail.gmail.com>
References: <CA+mi_8btbC_-0KheQ3WYZW81fS4B0MyPyuALihmqHTvqq=6VyA@mail.gmail.com>
<[email protected]>
<CA+mi_8YZnEuO=GAJiWnv_0Bx7_6DsL9jUcwhMxtXGqeSBgSp0A@mail.gmail.com>
On 08/02/21, Daniele Varrazzo ([email protected]) wrote:
> > - There appears to be no card about dictcursor on the project board.
> > What's the plan (and priority) for that (if any)?
...
> In psycopg2 there are:
>
> - DictCursor (returns a hybrid object between a sequence and a dictionary)
> - RealDictCursor (returns a straight subclass of a dictionary, so it's
> not a legit dbapi cursor as it doesn't expose a sequence)
> - NamedTupleCursor (what it says on the tin).
>
> Personally I use the NamedTupeCursor most often, as I prefer the dot
> notation to access attribute.
...
> 1) We can provide a feature to select the type of cursor that is not
> much dissimilar from psycopg2
> 2) Do we need DictCursor/RealDictCursor? ISTM that one of the two
> would be sufficient? Possibly an object inheriting from a Python dict
> instead of emulating it so that e.g. json.dumps()
> 3) Or, conversely, we could have a Row object providing both attribute
> and getattr access, both as index and name:
>
> row.myattr
> row["myattr"]
> row[1]
A comment on this point.
We use NamedTupleCursor a great deal as our system domain is modelled
largely in the database in plpgsql. The only issue we've had with using
NamedTupleCursor is when someone uses a space in column heading (the
space translates to a "_") or trips up and uses the same column name for
two columns. We class both cases as a mistake.
Instead of making the NamedTupleCursor the default, I imagine many
people accessing "raw" sql from python would benefit from the third
option, of permitting list, dict or getattr type access to values. This
would, presumably, be backwards compatible with current usage which I
imagine is typically list oriented.
A major benefit of getattr type access is that interactive debugging in
iPython allows dot expansion, so introspection of the the row's
attributes is wonderfully easy.
Regards
Rory
view thread (10+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Latest developments in psycopg3
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox