Allow return mismatch to be caught by function

[TedShaneyfelt]

BPO	29467
Nosy	@ericvsmith

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2017-02-07.00:55:03.858>
created_at = <Date 2017-02-06.21:11:31.427>
labels = ['interpreter-core', 'type-feature']
title = 'Allow return mismatch to be caught by function'
updated_at = <Date 2017-02-07.00:55:03.856>
user = 'https://bugs.python.org/TedShaneyfelt'

bugs.python.org fields:

activity = <Date 2017-02-07.00:55:03.856>
actor = 'eric.smith'
assignee = 'none'
closed = True
closed_date = <Date 2017-02-07.00:55:03.858>
closer = 'eric.smith'
components = ['Interpreter Core']
creation = <Date 2017-02-06.21:11:31.427>
creator = 'Ted Shaneyfelt'
dependencies = []
files = []
hgrepos = []
issue_num = 29467
keywords = []
message_count = 2.0
messages = ['287173', '287182']
nosy_count = 2.0
nosy_names = ['eric.smith', 'Ted Shaneyfelt']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue29467'
versions = ['Python 3.5']

[TedShaneyfelt]

def f():
    try: return 0
    except: return 1,2

x = f() # x is 0
x,y = f() # proposal: x,y should be 1,2 instead of uncaught TypeError

It would make sense to be able to catch [TypeError: 'int' object is not iterable] and return the correct number of values. Yes, the way it's done now, the function is no longer running when it is caught - but is it possible and practical to determine if parameters match before the function returns instead of afterward, allowing the called function to catch the error attempting to return?

[ericvsmith]

Thanks for the suggestion. However, I don't think it's possible or desirable for python to implement this.

There are two problems: 1) the internals of python would have to be drastically changed to support this, and 2) you'd need different syntax to support this.

For item 2, consider:

def f():
    try: return some_other_function()
    except: return 1,2

You can't distinguish between your proposed type mis-match exception and some_other_function() raising a TypeError. I suppose you could invent another exception type, but you'll always have a similar problem.

A larger problem is that this behavior would be confusing to both newcomers and existing programmers, it adds nothing that can't currently be done, and it would be a source of subtle bugs.

If you really want to explore this, I suggest working out a more complete example and bringing it up on the python-ideas mailing list.

You'll want to include code that currently exists that would be made simpler with your proposal. If you can find any such code in the standard library, that would be a bonus.

Thanks again.