Re: Feature branches merged to master for 2.8 release

On Mon, Oct 15, 2018 at 1:12 PM Karsten Hilbert <Karsten.Hilbert@gmx.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