IronPython 1.0 - Bugs or Features?

Super Spinner Pepe.Smythe at gmail.com
Thu Sep 7 01:03:11 CEST 2006


Claudio Grondi wrote:
> tjreedy wrote:
> > "Claudio Grondi" <claudio.grondi at freenet.de> wrote in message
> > news:edn23m$s6$1 at newsreader2.netcologne.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: DeprecationWarning: 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.




More information about the Python-list mailing list