IronPython 1.0 - Bugs or Features?

[Claudio Grondi]

(just wanted to share my experience with IronPython 1.0)

The context:
C:\IronPythonip y.exe
IronPython 1.0.60816 on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
vs.
C:\Python24pyth on.exe
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]
on win32

IronPython raises "UnboundLocalEr ror: local variable 'strData'
referenced before assignment" error in following case:
<code>
while(someCondi tion):
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'\\.\Phys icalDrive0', '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

[Marc 'BlackJack' Rintsch]

Re: IronPython 1.0 - Bugs or Features?

In <edmlbv$a9h$1@n ewsreader2.netc ologne.de>, Claudio Grondi wrote:

The context:
C:\IronPythonip y.exe
IronPython 1.0.60816 on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
vs.
C:\Python24pyth on.exe
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]
on win32
>
IronPython raises "UnboundLocalEr ror: local variable 'strData'
referenced before assignment" error in following case:
<code>
while(someCondi tion):
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.

Well I get a `NameError` for `someCondition` . Please post a minimal
*working* example that produced the error.

Ciao,
Marc 'BlackJack' Rintsch

[Larry Bates]

Re: IronPython 1.0 - Bugs or Features?

Claudio Grondi wrote:

(just wanted to share my experience with IronPython 1.0)
>
The context:
C:\IronPythonip y.exe
IronPython 1.0.60816 on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
vs.
C:\Python24pyth on.exe
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]
on win32
>
IronPython raises "UnboundLocalEr ror: local variable 'strData'
referenced before assignment" error in following case:
<code>
while(someCondi tion):
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'\\.\Phys icalDrive0', '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.

-Larry Bates

[Robin Becker]

Re: IronPython 1.0 - Bugs or Features?

Claudio Grondi wrote:

>
Another problem with IronPython where CPython 2.4.2 runs ok was while I
was trying to do:
f = file(r'\\.\Phys icalDrive0', '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?

I guess it's M$ being overprotective. Certainly it works in CPython as expected,

>>f = file(r'\\.\Phys icalDrive0', 'rb')
>>f

<open file '\\.\PhysicalDr ive0', mode 'rb' at 0x01292650>

I have used similar to get boot sectors etc, but then did you really think Bill
would let us play with our own hardware? Just wait till DRM gets here.
--
Robin Becker

[Claudio Grondi]

Re: IronPython 1.0 - Bugs or Features?

Larry Bates wrote:

Claudio Grondi wrote:
>

>>(just wanted to share my experience with IronPython 1.0)
>>
>>The context:
> C:\IronPythonip y.exe
> IronPython 1.0.60816 on .NET 2.0.50727.42
> Copyright (c) Microsoft Corporation. All rights reserved.
>>vs.
> C:\Python24pyth on.exe
> Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]
>>on win32
>>
>>IronPython raises "UnboundLocalEr ror: local variable 'strData'
>>referenced before assignment" error in following case:
>><code>
> while(someCondi tion):
> 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'\\.\Phys icalDrive0', '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'\\.\Phys icalDrive0', '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

[Claudio Grondi]

Re: IronPython 1.0 - Bugs or Features?

Marc 'BlackJack' Rintsch wrote:

In <edmlbv$a9h$1@n ewsreader2.netc ologne.de>, Claudio Grondi wrote:
>
>

>>The context:
> C:\IronPythonip y.exe
> IronPython 1.0.60816 on .NET 2.0.50727.42
> Copyright (c) Microsoft Corporation. All rights reserved.
>>vs.
> C:\Python24pyth on.exe
> Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]
>>on win32
>>
>>IronPython raises "UnboundLocalEr ror: local variable 'strData'
>>referenced before assignment" error in following case:
>><code>
> while(someCondi tion):
> 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.

>
>
Well I get a `NameError` for `someCondition` . Please post a minimal
*working* example that produced the error.

I can't as after constructing one according to what I have thought was
the cause of it I detected that the error was caused by the exception in
the line
strData = strSomeValue()
(see also my other posting)
I have just misinterpreted the origin of the "UnboundLocalEr ror:" as
raised while parsing and was wondering how it comes, that the parser is
able to detect such things ...
Sorry for the eventually caused confusion.

Claudio Grondi

[tjreedy]

Re: IronPython 1.0 - Bugs or Features?


"Claudio Grondi" <claudio.grondi @freenet.dewrot e in message
news:edn23m$s6$ 1@newsreader2.n etcologne.de...

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?

Parsing detects and reports syntax errors and maybe something else if you
use non-ascii chars without matching coding cookie. Other errors are
runtime.

tjr

[Claudio Grondi]

Re: IronPython 1.0 - Bugs or Features?

tjreedy wrote:

"Claudio Grondi" <claudio.grondi @freenet.dewrot e in message
news:edn23m$s6$ 1@newsreader2.n etcologne.de...
>

>>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?

>
>
Parsing detects and reports syntax errors and maybe something else if you
use non-ascii chars without matching coding cookie. Other errors are
runtime.

Let's consider
print '"Data ê"'

In CPython 2.4.2 there is in case of non-ascii character:
sys:1: DeprecationWarn ing: Non-ASCII character '\xea' in file
C:\IronPython-1.0-BugsOrFeatures. py on line 3, but no encoding
declared; see http://www.python.org/peps/pep-0263.html for details
"Data♀♂ Û"

IronPython does not raise any warning and outputs:
"Data♀♂ ?"

So it seems, that IronPython is not that close to CPython as I have it
expected.
It takes much more time to run this above simple script in IronPython as
in CPython - it feels as IronPython were extremely busy with starting
itself.

Claudio Grondi

[Super Spinner]

Re: IronPython 1.0 - Bugs or Features?


Claudio Grondi wrote:

tjreedy wrote:

"Claudio Grondi" <claudio.grondi @freenet.dewrot e in message
news:edn23m$s6$ 1@newsreader2.n etcologne.de...

>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?

Parsing detects and reports syntax errors and maybe something else if you
use non-ascii chars without matching coding cookie. Other errors are
runtime.

Let's consider
print '"Data ê"'
>
In CPython 2.4.2 there is in case of non-ascii character:
sys:1: DeprecationWarn ing: Non-ASCII character '\xea' in file
C:\IronPython-1.0-BugsOrFeatures. py on line 3, but no encoding
declared; see http://www.python.org/peps/pep-0263.html for details
"Data♀♂ Û"
>
IronPython does not raise any warning and outputs:
"Data♀♂ ?"
>
So it seems, that IronPython is not that close to CPython as I have it
expected.
It takes much more time to run this above simple script in IronPython as
in CPython - it feels as IronPython were extremely busy with starting
itself.
>
Claudio Grondi

IronPython is a .NET language, so does that mean that it invokes the
JIT before running actual code? If so, then "simple short scripts"
would take longer with IronPython "busy starting itself" loading .NET
and invoking the JIT. This effect would be less noticable, the longer
the program is. But I'm just guessing; I've not used IronPython.

[Claudio Grondi]

Re: IronPython 1.0 - Bugs or Features?

Super Spinner wrote:

IronPython is a .NET language, so does that mean that it invokes the
JIT before running actual code? If so, then "simple short scripts"
would take longer with IronPython "busy starting itself" loading .NET
and invoking the JIT. This effect would be less noticable, the longer
the program is. But I'm just guessing; I've not used IronPython.
>

The time of loading IronPython seem to pay out at the end if the script
takes a longer time to run, so you are most probably right. I am a bit
surprised, that the difference is not that big (e.g. at least half the
time) as I have expected from a JIT concept ... :

<code>
# import psyco
# psyco.full()

def arccot(x, unity):
sum = xpower = unity // x
n = 3
sign = -1
while 1:
xpower = xpower // (x*x)
term = xpower // n
if not term:
break
sum += sign * term
sign = -sign
n += 2
return sum

def pi(digits):
print ' start of setting unity value ...',
unity = 10**(digits + 10)
print ' set unity value, starting arccot() ... ',
pi = 4 * (4*arccot(5, unity) - arccot(239, unity))
return pi // 10**10


f = file("pi-decimal-100000digits.ou t","wb")
f.write(str(pi( 100000)))

print """
PC: Pentium 4, 2.8 GHz, Windows XP SP2
writing 100.000 digits of Pi to a file takes using:
CPython 2.4.2 : 2 min 41 s (of CPU time)
CPython+Psyco : 2 min 45 s (of CPU time)
IronPython 1.0 : 1 min 48 s (of CPU time)
"""
</code>

Claudio Grondi