On Thu, 2008-01-31 at 10:10 +1100, Cameron Simpson wrote:
> On 30Jan2008 16:22, Aaron Konstam <akonstam@xxxxxxxxxxxxx> wrote:
> | On Thu, 2008-01-31 at 07:16 +1100, Cameron Simpson wrote:
> | > On 30Jan2008 07:40, Aaron Konstam <akonstam@xxxxxxxxxxxxx> wrote:
> | > | The following seems like an bug in python in both f7 and f8 but I would
> | > | like input before I post a bugzilla. It seems the exception handler
> | > | cannot trap the TypeError in python.
> | > | For example:
> | > | def plus(a,b):
> | > | try:
> | > | return(a+b)
> | > | except TypeError:
> | > | return None
> | > |
> | > | If we define plus as above and call it with: plus(3,) we should get
> | > | nothing returned. Instead we get:
> | > | Traceback (most recent call last):
> | > | File "./calculator", line 47, in <module>
> | > | exec("register=op[tokens[0]](register)")
> | > | File "<string>", line 1, in <module>
> | > | TypeError: plus() takes exactly 2 arguments (1 given)
> | > |
> | > | This seems like a bug. An ideas out there?
> | >
> | > The 'b' argument to plus() is not optional. This isn't Perl. plus()
> | > is not being called, and your try/except is not being reached.
> | >
> | > Not a bug.
> | I don't agree. from the point of view of the programmer the statement:
> | result(a+b)
> | has generated an error and that error should be caught.
> | I have taught courses in writing compilers and interpreters and I know
> | how this process is implemented in machine code but the response of the
> | error trapping system should relate to the statement in python and that
> | statement "threw" an error.
>
> Shrug. You're still wrong.
>
> The language specification says that your function definition:
>
> def plus(a,b):
>
> requires two arguments. You supplied ONLY ONE ("plus(3,)"). Unless you fix
> that, the interpreter will never enter the function. If you want to think of
> the function like a lambda you're applying the tuple (3,) to the "plus"
> function. (3,) is a tuple with only one element. Python checks argument
> lists.
>
> Others have already suggested you pass two arguments or allow plus()
> to accept one argument.
>
> The thing that threw the error was your function call ("plus(3,)"),
> and _not_ the function internal, which were never reached. So the
> exception is correct.
>
> Maybe you should post your "calculator" file, since I'm sure more is
> going on than you've described. Using exec() is a lot like using eval()
> in perl - exceptions will be caught by the wrapper; that may be your
> trouble. In perl they land in $@, in python they're probably caught and
> rethrown, hence the slightly surprising error line.
>
> But without "calculator" we're all in the dark.
>
> I've returned this discussion to the list where it belongs.
>
> Cheers,
Ok, I have attached the calculator program to this message as a .tgz
file but the problem exists in just the execution of a simple function
so that fact that calculate used eval and exec seems not relevant.
Now let me be clear. I agree the execution path that is actually
occurring is the one you describe but it is an inconsistent feature of
python that annoys me, but I admit it will not be fixed.
The problem is that the construct:
try
statement block
expect TypeError:
action
Is a source construct. It implies that if a TypeError occurs in the
execution of the statement block it will be caught, To say that this
error occurs before the execution of plus is fallacious in that until
you start execution of the plus you don't know it has two arguments. So
the execution has really been started with checking the arguments as a
early step.
I know how to fix this in my program but I was hoping to use the try
construct do it so it frustrates me.
--
=======================================================================
Love the sea? I dote upon it -- from the beach.
=======================================================================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@xxxxxxxxxxxxx
Attachment:
calculate.tgz
Description: application/compressed-tar
