On 10/15/2018 07:23 PM, Daniele Varrazzo wrote:
On Mon, Oct 15, 2018 at 1:12 PM Karsten Hilbert<karsten.hilb...@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.
Python exceptions are CamelCase in 99% of the cases (pun intended).
Lets not have every single Python programmer out there hate us because
we decided to import a database backend convention into a programming
laguage.
federico
--
Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl http://dndg.it
Una nazionale senza neanche una nazione. -- macchinavapore
