Re: catching exceptions in expressions

Discussion in 'Python' started by Andrew Dalke, Aug 7, 2003.

  1. Andrew Dalke

    Andrew Dalke Guest

    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
    Andrew Dalke, Aug 7, 2003
    #1
    1. Advertising

  2. 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 <>
    Vaclav Dvorak, Aug 7, 2003
    #2
    1. Advertising

  3. Andrew Dalke

    Chris Reedy Guest

    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! =-----
    Chris Reedy, Aug 7, 2003
    #3
  4. Andrew Dalke

    Andrew Dalke Guest

    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
    Andrew Dalke, Aug 7, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Marina
    Replies:
    2
    Views:
    463
    Marina
    Jul 8, 2003
  2. Amil Hanish
    Replies:
    0
    Views:
    535
    Amil Hanish
    Apr 13, 2006
  3. Adam Maass
    Replies:
    5
    Views:
    387
    Sudsy
    Jul 22, 2003
  4. Mike Schilling
    Replies:
    2
    Views:
    339
    Mike Schilling
    Jul 16, 2003
  5. Mick
    Replies:
    0
    Views:
    411
Loading...

Share This Page