On 1/23/07, Collin Winter <[EMAIL PROTECTED]> wrote: > On 1/23/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > Phillip J. Eby wrote: > > > The 2-expression "raise" statement translation is incorrect in the general > > > case; it is possible for the second argument to be an instance of the > > > first > > > argument, in which case 'raise E, V' should become just 'raise V'. This > > > is > > > not detectable by the refactoring tool, AFAIK. > > > > There is another issue which currently isn't entirely clear in this PEP > > or in PEP 352 - what happens to except statements which raise a subtype > > of Exception instead of an instance of it. > > > > It's currently implicit that this will continue to be allowed (with > > subtypes being automatically instantiated with no arguments) - I think > > that behaviour should be explicitly stated as intentional in the new > > Py3k PEP. > > Does this language work for you? > > """ > 2. ``raise E`` (with a single argument) is used to raise a new > exception.
For some reason I thought you were initially talking about a single argument to the exception, not to E. >This form has two sub-variants: ``E`` may be either an > instance of ``BaseException`` [#pep352]_ or a subclass of > ``BaseException``. If ``E`` is a subclass, it will be called with > no arguments to obtain an exception instance. > > To raise anything else is an error. > """ I don't think that calling them a variant is right. You can only raise subclasses of BaseException (which implicitly implies BaseException itself). If you want to mention BaseException itself that's fine, but there is no variant here; there is a single rule. -Brett _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
