A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2005-August/055192.html below:

[Python-Dev] FW: PEP 8: exception style

[Python-Dev] FW: PEP 8: exception styleTim Peters tim.peters at gmail.com
Sat Aug 6 19:37:04 CEST 2005
[AMK]
>> PEP 8 doesn't express any preference between the
>> two forms of raise statements:
>> raise ValueError, 'blah'
>> raise ValueError("blah")
>>
>> I like the second form better, because if the exception arguments are
>> long or include string formatting, you don't need to use line
>> continuation characters because of the containing parens.  Grepping
>> through the library code, the first form is in the majority, used
>> roughly 60% of the time.
>>
>> Should PEP 8 take a position on this?  If yes, which one?

[Raymond Hettinger]
> I we had to pick one, I would also choose the second form.  But why
> bother inflicting our preference on others, both forms are readable so
> we won't gain anything by dictating a style.

Ongoing cruft reduction -- TOOWTDI.  The first form was necessary at
Python's start because exceptions were strings, and strings aren't
callable, and there needed to be _some_ way to spell "and here's the
detail associated with the exception".  "raise" grew special syntax to
support that need.  In a Python without string exceptions, that syntax
isn't needed, and becomes (over time) an increasingly obscure way to
invoke an ordinary constructor -- ValueError("blah") does exactly the
same thing in a raise statement as it does in any other context, and
transforming `ValueError, 'blah'` into the former becomes a wart
unique to raise statements.
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4