[Python-3000] Pre-peps on raise and except changes (was: Warning for 2.6 and greater)

Phillip J. Eby pje at telecommunity.com
Tue Jan 23 03:53:37 CET 2007


At 04:45 PM 1/22/2007 -0600, Collin Winter wrote:
>On 1/12/07, Steven Bethard <steven.bethard at gmail.com> wrote:
>>On 1/12/07, Barry Warsaw <barry at python.org> wrote:
>> > It's worth spending time thinking about how we can help ease the
>> > transition for each.  There may be more thing too.  I wonder if it
>> > doesn't make sense for all 3xxx PEPs to include a discussion section
>> > on porting.
>>
>>Yeah, when this was talked about last time, I wrote PEP 3002 which
>>requests exactly this:
>>
>>     http://www.python.org/dev/peps/pep-3002/
>>
>>It basically proposes that all backwards-incompatible changes be
>>discussed in a PEP somewhere, and that code like Anthony's be added to
>>2.X to ease the transition.
>
>Attached are drafts of the PEP 3002-compliant PEPs concerning the
>changes to raise and except statements that have been discussed on
>python-3000.
>
>Any suggestions/corrections/additions would be much appreciated.

The correct translation of a try/except should be:

     try:
         ...
     except E as N:
         try:
             ...
         finally:
             N = None
             del N

i.e., you left out the crucial try/finally wrapper.  If you got this 
translation from the current implementation, then the implementation is 
wrong too.  :)

Also, the PEP should discuss the matter of how "except" should change in 
Python 2.6 to support this, including the current open issue of handling 
the .traceback attribute.

The ``throw()`` signature is incorrectly listed as:

     generator.throw(E, [T, [V]])

It is in fact:

     generator.throw(E, [V, [T]])

It should be noted that this will require special handling in Python 2.6; 
the implementation will need to detect whether the exception instance has a 
traceback, in order to convert to 2.x style exception processing.

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.



More information about the Python-3000 mailing list