BUT, my unconsidered opinion, right now, is that I approve of you
compromise. I don't think having two cases ( zero or one arg ) to
deal with is too big a trade considering the flexibility you get
with the tuple equivalence.
I *don't* think breaking code should be a major consideration right now.
( But then I am the proud author of exactly ONE peice of python code ;-)
One reason for bringing up these issues is that you are at release 0.92
and might as well have all the syntactic shake-outs BEFORE you get to
1.0 . At that point you should consider the major feature cast in stone,
but we will forgive you up till then.
I *didn't* thin the logic of the zero-or-one/tuple-equivalence passing
mechanism was difficult to figure out, and your answer was more or less
what I expected, but I thought it would be a good topic for discussion.
I think zero-or-one is only important in one direction, i.e. the typical
case is a procedure that expects ONE arg and is called with NONE.
How about making argument mismatches a non-error.
Where there are too few dummy args, they get packed as a tuple in the last
arg ( I believe that IS the current action ? )
Where there are too few dummy args, the value 'None" becomes the arg. value.
( I don't know how "None" is represented, so I don't know if that is
practical. )
But if there is no clear winning compromise, I can live with things as they
are. But, perhaps the exception namespace should be a little finer so we
can just catch and only catch some "common" error ( like no arg when one
expected! )
For that, I propose that the semantics be modified so that exception tuples
are effectively "flattened". This will allow a hierarchy in the exception
namespace ( less or more specific ). e.g.
SyntaxError = ( several different types of syntax error )
TypeError = ( several different types of type error )
try:
...
except ( SyntaxError, aSpecificTypeError ):
and the above is effectively the same as
except ( SyntaxErr-1, SyntaxErr-2, ... SyntaxErr-N, aSpecificTypeError ):
Exception signal mechanism's in VMS (for example) and ( I think ) in some
other languages that support exceptions, catch ALL of the appropriate
signals, and give the user-exception processing code the responsibility of
filtering them. There is a "resignal" mechanism is VMS to pass the
exception down to the next level of processing.
This would be equivalent to python code checking the exception argument to
see if it was the one it was expecting, and if not, raising that exception
again, so that some outer code could have a chance of catching it. ( Or of
giving an error message - too general exception classes may have the
effect of masking errors that the user didn't anticipate. That is REALLY
what I'm concerned about! )
Forgive me for not trying out and including some better examples and for
being a bit too verbose for my own good. I'm writing this at home,
( without the Python manual at my side ) and editing on the modem
can be a chore.
If it wasn't 2AM, I would edit this down to two separate messages:
argument passing & exceptions.
- Steve