IronPython 1.0 - Bugs or Features?

[Claudio Grondi]

Larry Bates wrote:
> Claudio Grondi wrote:
> 
>>(just wanted to share my experience with IronPython 1.0)
>>
>>The context:
>>  C:\IronPython> ipy.exe
>>  IronPython 1.0.60816 on .NET 2.0.50727.42
>>  Copyright (c) Microsoft Corporation. All rights reserved.
>>vs.
>>  C:\Python24> python.exe
>>  Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]
>>on win32
>>
>>IronPython raises "UnboundLocalError: local variable 'strData'
>>referenced before assignment" error in following case:
>><code>
>>    while(someCondition):
>>      try:
>>        strData = strSomeValue()
>>      except:
>>        pass
>>      if( type(strData) == str ) : ### <<< HERE THE ERROR
>>        doSomething()
>></code>
>>CPython 2.4.2 doesn't raise an error with same code.
>>
>>As strData is not set anywhere before in the code it seems, that
>>IronPython is somehow right, but I am not sure if it is a bug or a feature.
>>
>>Another problem with IronPython where CPython 2.4.2 runs ok was while I
>>was trying to do:
>>  f = file(r'\\.\PhysicalDrive0', 'rb')
>>getting "ValueError: FileStream will not open Win32 devices such as disk
>>partitions and tape drives. Avoid use of "\\.\" in the path."
>>Here the same - I am not sure if it is a bug or a feature.
>>
>>Can someone knowledgeable elaborate on it a bit please?
>>
>>Claudio Grondi
> 
> 
> Your problem is a blanket exception handler that ignores
> the exception.  Blanket exceptions are almost always a
> bad idea.  Blanket exceptions with pass as the only
> command in the except: block is ALWAYS a bad idea.
> 
> Basically the line strData = strSomeValue() caused an
> exception.  Since it was inside a try: block, it then
> executed what was in the except: block.  Since all that
> was in the except: block was pass, it just fell through
> to the if statement.  At that point strData is not
> defined because the try block failed and never create
> strData object.
> 
> It is doing EXACTLY what you told it to do.
Sorry for the confusion caused, but you are right.
The actual code was a bit more complex, so I tried to get it down to the 
principle, but haven't expected, that
   f = file(r'\\.\PhysicalDrive0', 'rb')
buried within strSomeValue() throws an exception as in CPython the code 
was running ok.
So the second problem was the cause also for the first one ...
I also erroneously assumed, that the first problem was detected during 
parsing ... so, by the way: how can I distinguish an error raised while 
parsing the code and an error raised when actually running the code?

Claudio Grondi