Re: Feature branches merged to master for 2.8 release

On Mon, Oct 15, 2018 at 1:12 PM Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> wrote:
>
> On Mon, Oct 15, 2018 at 12:48:04PM +0100, Daniele Varrazzo wrote:
>
> > - the new 'errors' module. About it I have a doubt: we convert
> > postgres error messages [2] from lower_case to CamelCase because the
> > latter is the convention for Python class, but maybe leaving as they
> > are makes more sense? Easier to google for them or grep for them in
> > the postgres sources maybe?
>
> Since there is no Right or Wrong here, the "best" option
> might be to offer both:
>
> Raise whatever is Right for Python (that is, CamelCase)
>
> raise PostgresSpecificError
>
> but support catching lower case, too:
>
> class postgres_specific_error(PostgresSpecificError):
> pass
>
> try:
> something()
> except postgres_specific_error:
> print('lower case')
>
> For the lower case one I would exactly copy what's used by
> PostgreSQL itself.
>
> Make sense ?

I think it's responsible to make a decision. Having two names to refer
to a thing is confusing. One of the two would be the "blessed" one -
the one appearing in the tracebacks. And if a traceback says that
'unique_violation' was raised, it would be weird to solve it by
writing a handler for 'UniqueViolation'.

Plus, that module defines already 232 classes (as of Postgres 11): I
wouldn't like doubling their number. I'm pondering whether to write it
as a C module instead of Python but I'm not overly fussed by that.

So I'd say lower_case or CamelCase, not both.

-- Daniele