Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   Re: catching exceptions in expressions (http://www.velocityreviews.com/forums/t320673-re-catching-exceptions-in-expressions.html)

Andrew Dalke 08-07-2003 01:06 AM

Re: catching exceptions in expressions
 
Vaclav Dvorak:
> try: c = int(u)
> except ValueError: c = 99
>
> Not enough to make me want to create a function, but enough to be
> annoying. :-) I was thinking about something like this:
>
> a = int(s) except ValueError then 99


No. In general, Python encourages new functions or
classes over new syntax. What's wrong with

def safe_int(s, default):
try:
return int(s)
except ValueError:
return default

or for something more generic

class TryCatcher:
def __init__(self, function, default, exceptions = (ValueError,)):
self.function = function
self.default = default
self.exceptions = exceptions
def __call__(self, *args, **kwargs):
try:
return self.function(*args, **kwargs)
except self.exceptions:
return self.default

safe_int = TryCatcher(int, 99)
safe_int("a")


> a = int(s) or 99 if ValueError


Parse ambiguity.

a = int(s) or 99

is valid Python today.

> a, b, c = 99, 99, 99
> try:
> a = int(s)
> b = int(t)
> c = int(u)
> except ValueError:
> continue [execution on next line - my comment]


'continue' already has meaning in current Pythons.

> Comments? Should I write a PEP? Am I missing something obvious? Has this
> been debated a million times over already?


Feel free to write a PEP. It won't be accepted.

Andrew
dalke@dalkescientific.com



Vaclav Dvorak 08-07-2003 06:34 PM

Re: catching exceptions in expressions
 
Hi,

Did I arouse nobody's interest except for Andrew? Nobody thinks catching
exceptions inside expressions would be a cool feature to have?

Andrew Dalke wrote:
> Vaclav Dvorak:
>
>>try: c = int(u)
>>except ValueError: c = 99
>>
>>Not enough to make me want to create a function, but enough to be
>>annoying. :-) I was thinking about something like this:
>>
>>a = int(s) except ValueError then 99

>
> No. In general, Python encourages new functions or
> classes over new syntax.


Well, list comprehensions were implemented, and that feature didn't even
need anything new - not even functions, let alone syntax: "List
comprehensions provide a concise way to create lists without resorting
to use of map(), filter() and/or lambda." (Python Tutorial, 5.1.4.) So
that gives me hope. :-)

> What's wrong with
> def safe_int(s, default):

[...]
> or for something more generic
> class TryCatcher:

[...]

Well, it's good when you will use than a hundred times. But when you
need it only here and there, it's more hassle than it's worth.

>>a = int(s) or 99 if ValueError

>
> Parse ambiguity.
>
> a = int(s) or 99
>
> is valid Python today.


I'm not an expert in parsers, but wouldn't the "if" disambiguate it, as
it's not otherwise found inside expressions? Or what if it was in
parentheses:
>>> a = int(s) (or 99 if ValueError)

This syntax has the advantage of not introducing any new keywords. I
still like:
>>> a = int(s) except ValueError then 99

somewhat better, though. But, it adds "then", and without it it wouldn't
be so intuitive.

>>except ValueError:
>> continue [execution on next line - my comment]

> 'continue' already has meaning in current Pythons.


That's why I chose that - no new keyword. But I retract this one, and
the "retry" statement too. I don't really like them myself. :-)

>>Comments? Should I write a PEP? Am I missing something obvious? Has this
>>been debated a million times over already?

>
> Feel free to write a PEP. It won't be accepted.


Why? You're the only one who doesn't like it, so far. ;-) Of course,
you're also the only one who voiced any opinion, so that leaves me with
a not so huge statistical sample of one. :-)

Vaclav Dvorak <dvorakv@idas.cz>


Chris Reedy 08-07-2003 07:18 PM

Re: catching exceptions in expressions
 
Vaclav Dvorak wrote:
> Hi,
>
> Did I arouse nobody's interest except for Andrew? Nobody thinks catching
> exceptions inside expressions would be a cool feature to have?
>


When Guido designed Python he made a clear separation between statements
and expressions. (You might want to contrast this with Lisp where there
is no difference between statements and expressions.) I find myself
occasionally rebelling against this, most usually when using lambda
expressions, where statements might come in handy. As I've gotten used
to Python, I've also gotten used to the "Pythonic" notion that the way
to handle these situations is to define a function and then invoke it.

> Andrew Dalke wrote:
>
>> Vaclav Dvorak:
>> [big snip]
>>> Comments? Should I write a PEP? Am I missing something obvious? Has this
>>> been debated a million times over already?

>>
>>
>> Feel free to write a PEP. It won't be accepted.

>
> Why? You're the only one who doesn't like it, so far. ;-) Of course,
> you're also the only one who voiced any opinion, so that leaves me with
> a not so huge statistical sample of one. :-)
>


Were you here for the great "if-then-else" operator war? Given all the
controversy associated with adding an if-then-else expression, I think
any proposal to add any form of try-except expression is certainly
doomed to failure.

Chris



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

Andrew Dalke 08-07-2003 07:50 PM

Re: catching exceptions in expressions
 
Vaclav Dvorak:
> Well, list comprehensions were implemented, and that feature didn't even
> need anything new - not even functions, let alone syntax:


True, which is why I did say "generally."

When list comprehensions came out, one of the things I found
I liked about it was it replaced a lot of code like

new_data = []
for x in data:
new_data.append(x.attr)
data = new_data

I tried to abstract that into a function, like

def get_list_attr(data, attrname):
new_data = []
...

but could never come up with a good name for that function.
List comprehensions made the code shorter, easier to read,
and solved my naming problem.

While what you want has a meaningful name, like
'safe_int' or 'int_with_default' or ....

> Well, it's good when you will use than a hundred times. But when you
> need it only here and there, it's more hassle than it's worth.


Your syntax-based default value on exception could have the same
principle applied to it - is the number of times of use worth making
the change to the language?

> >>a = int(s) or 99 if ValueError

> >
> > Parse ambiguity.


>
> I'm not an expert in parsers, but wouldn't the "if" disambiguate it, as
> it's not otherwise found inside expressions?


In general, yes. But Python uses a lookahead-one parser, meaning
that the next token should be sufficient to figure things out. Suppose
you have

x = a or b or [....]

is the last or part of the 'or' expression

x = a or b or c

or is it part of an exception catcher

x = a or b or c if ValueError

Parsers can figure things out, but that makes the code harder to
implement and the language harder to read.

> >>except ValueError:
> >> continue [execution on next line - my comment]

> > 'continue' already has meaning in current Pythons.

>
> That's why I chose that - no new keyword. But I retract this one, and
> the "retry" statement too. I don't really like them myself. :-)


What I meant is that

for x in data:
try:
f(x)
except ValueError:
continue
..
already has meaning in Python, not that the word 'continue' by
itself exists as a keyword.

> Why? You're the only one who doesn't like it, so far. ;-) Of course,
> you're also the only one who voiced any opinion, so that leaves me with
> a not so huge statistical sample of one. :-)


Plenty of history using Python and reading c.l.py and seeing
discussions about changing the syntax before, and seeing an utter
dearth of people asking for this sort of feature, and applying my
own sense of sensability and estimating how rarely I would use
the construct.

Andrew
dalke@dalkescientific.com




All times are GMT. The time now is 04:41 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.