Date: Mon, 15 Oct 2018 21:27:26 +0300
From: Aryeh Leib Taurog <python@aryehleib.com>
To: psycopg@lists.postgresql.org, psycopg@postgresql.org
Subject: Re: Feature branches merged to master for 2.8 release
Message-ID: <20181015182726.625ioszpjs5yscxi@ds.aryehleib.com>
Mail-Followup-To: psycopg@lists.postgresql.org, psycopg@postgresql.org
References: 
 <CA+mi_8aVzn-4Ujuqg5aMduHjL1XQ3Y7sUU86s3p6shMefaPoSQ@mail.gmail.com>
 <20181015121154.GC2008@hermes.hilbert.loc>
 <CA+mi_8bRgi5rFZbnVAiDLK_B-ZLNa-ze9uK6y3WONHu_zq1u_Q@mail.gmail.com>
 <20181015174247.GF2008@hermes.hilbert.loc>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20181015174247.GF2008@hermes.hilbert.loc>
User-Agent: NeoMutt/20170113 (1.7.2)
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

I also think CamelCase should be preferred for consistency with=20
accepted Python standards.  It seems to me that if the exception=20
string representation includes the PostgreSQL snake_case name (perhaps=20
in parentheses), that should be sufficient for any reference needs,=20
because it will appear in the message printed with the traceback. =20
Usually if I want to search for more information about an error, I=20
just paste that into my browser.

Also, I wouldn=E2=80=99t be surprised if google is smart enough to handle=
 the=20
switch between camel case and snake case, but I haven=E2=80=99t tested it=
.

In any case, this is an exciting and welcome addition to an already=20
excellent library.  Thanks much for all your efforts.


> On Mon, Oct 15, 2018 at 06:23:57PM +0100, Daniele Varrazzo wrote:
>=20