Re: Feature branches merged to master for 2.8 release

On 10/15/2018 07:23 PM, Daniele Varrazzo wrote:
> 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.

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(dot)digregorio(at)dndg(dot)it
DNDG srl http://dndg.it
Una nazionale senza neanche una nazione. -- macchinavapore