Re: [IronPython] When does data binding occur?
Oops, my bad. DataBind is apparently only available in ASP.Net apps. There, it makes the data binding happen when you want it to (in the page processing model); in Windows Forms apps, I knew it happens by itself -- but I thought you could get it to happen earlier, as you seemed to need, by calling it (on the DataGridView). At 02:10 PM 7/26/2006, jeff sacksteder wrote Do you call DataBind ? No, Call it on what? The Datagridview? J. Merrill / Analytical Software Corp ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] NET Attributes.
Martin Maly wrote:
>
> Unfortunately, no. Adding .NET attributes on Python classes in
> IronPython is not possible.
>
> Somewhat similar Pythonic thing is function and method decorators:
>
> @command(“MyCommand”, CommandFlags.Modal)
>
> def RunMyCommand():
>
> ….
>
> However, this will not interoperate well with .NET since .NET is not
> aware of the decorator mechanism.
>
> For more information, you can check out:
> http://docs.python.org/whatsnew/node6.html
>
> There is another option to use function doc strings, but that would be
> more complicated to use and I’d probably use it as one of the last
> resorts.
>
However if you need to mark a class as serializable (or use any other
.NET attribute), you just can't do it from IronPython at the moment. :-(
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
> Martin
>
>
>
> *From:* [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] *On Behalf Of *Tim Riley
> *Sent:* Wednesday, July 26, 2006 10:17 AM
> *To:* Discussion of IronPython
> *Subject:* [IronPython] NET Attributes.
>
> Is it possible to use .NET attributes in IronPython? For example I
> have C# code that looks like:
>
> [CommandMethod("MyCommand", CommandFlags.Modal)]
> public static void RunMyCommand()
> {
> 'code here
> }
>
> Can I do something similiar in IP? I'll take anything.
>
>
>
> ___
> users mailing list
> users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Bug in urllib?
Thanks Bruce - it's not a huge prob for me right now - I was just trying to come up with a benchmark script for you guys to use to test BeautifulSoup performance. Will look at doing it with text files rather than urls tomorrow.
On 7/26/06, Bruce Christensen <[EMAIL PROTECTED]> wrote:
This is a bug. It has never worked—although it would be
great if it did. As noted in socket.__doc__, socket.makefile() (which
urllib.urlopen() depends on) is not implemented. We're aware of the
problem, and I've filed a bug at
http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=1368
to track it.
Here's the long technical explanation why makefile() is
missing: CPython actually implements the socket module in two parts:
_socket.pyd (the main implementation written in C) and socket.py (a thin
wrapper written in Python). We originally planned to implement only the _socket
module (in C#) and have people use it with the standard socket.py module.
However, we discovered that socket.py depends on CPython's refcounting
garbage collector work correctly, and so we had to modify our socket module to
work without socket.py. Unfortunately, makefile() is one of the things that socket.py
provides, and we haven't had time yet to implement it.
--Bruce
From:
[EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED]] On
Behalf Of Mike Raath
Sent: Wednesday, July 26, 2006 12:53 AM
To: Discussion of IronPython
Subject: [IronPython] Bug in urllib?
I'm getting an error trying to
use urllib - AttributeError: 'socket' object has no attribute 'makefile' Using
1.0 RC1. Not sure if this has ever worked - get NotImplementedError:
getaddrinfo() is not currently implemented in the Beta 9.
>>> import sys
>>> sys.path.append("C:\\Python24\\Lib")
>>> import urllib
>>> f = urllib.urlopen("http://www.microsoft.com
")
Traceback (most recent call last):
File , line 0, in ##151
File C:\Python24\Lib\urllib.py, line 82, in urlopen
File C:\Python24\Lib\urllib.py, line 194, in open
File C:\Python24\Lib\urllib.py, line 316, in open_http
File C:\Python24\Lib\httplib.py, line 1150, in getreply
File C:\Python24\Lib\httplib.py, line 863, in getresponse
File C:\Python24\Lib\httplib.py, line 275, in __init__
AttributeError: 'socket' object has no attribute 'makefile'
Same on CPython 2.4 gives:
>>> import sys
>>> sys.path.append("C:\\Python24\\Lib")
>>> import urllib
>>> f = urllib.urlopen("
http://www.microsoft.com")
>>> print f.read()
(etc.)
___users mailing listusers@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] __future__ is a little too magic for its own good
Hi Jonathan, You may be getting this error because you do not have __future__.py in the path. See the following examples: 1. When you do not have __future__.py C:\ip2\IronPython\Public\Src\Test>ip IronPython 1.0.2396 on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> from __future__ import division Traceback (most recent call last): File , line 0, in ##1 File , line 0, in __import__##5 ImportError: No module named __future__ 2. create a file __future__.py with content below( or use the attached one): division=1 with_statement=1 now, invoke ironpython C:\ip2\IronPython\Public\Src\Tests>ip IronPython 1.0.2396 on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> from __future__ import division >>> #you still can not import with_statement since it is Python25 feature >>> from __future__ import with_statement Traceback (most recent call last): SyntaxError: future feature is not defined: with_statement (, line 1) You still get error for with_statement because, it is enabled only with -X:Python25 switch. 3. Now invoke ironpython with -X:Python25 and you can import with_statement also. C:\ip2\IronPython\Public\Src\Tests>ip -X:Python25 IronPython 1.0.2396 on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> from __future__ import with_statement >>> Hope this helps. Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Jacobs Sent: Wednesday, July 26, 2006 1:44 AM To: IronPython List Subject: [IronPython] __future__ is a little too magic for its own good IronPython 1.0.60725 on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> with Traceback (most recent call last): File , line 0, in ##3 NameError: name 'with' not defined >>> from __future__ import with_statement Traceback (most recent call last): File , line 0, in ##4 File , line 0, in __import__##8 ImportError: No module named __future__ >>> with Traceback (most recent call last): SyntaxError: unexpected token (, line 1) This appears to happen with every other __future__ import I tried. P.S. Icons! Whee!!! -- Jonathan ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com __future__.py Description: __future__.py ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] When does data binding occur?
Do you call DataBind ?No, Call it on what? The Datagridview? ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] NET Attributes.
Unfortunately, no. Adding .NET attributes
on Python classes in IronPython is not possible.
Somewhat similar Pythonic thing is
function and method decorators:
@command(“MyCommand”,
CommandFlags.Modal)
def RunMyCommand():
….
However, this will not interoperate well
with .NET since .NET is not aware of the decorator mechanism.
For more information, you can check out: http://docs.python.org/whatsnew/node6.html
There is another option to use function
doc strings, but that would be more complicated to use and I’d probably
use it as one of the last resorts.
Martin
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Riley
Sent: Wednesday, July 26, 2006
10:17 AM
To: Discussion
of IronPython
Subject: [IronPython] NET
Attributes.
Is it possible to use .NET attributes in IronPython? For example I have
C# code that looks like:
[CommandMethod("MyCommand", CommandFlags.Modal)]
public static void RunMyCommand()
{
'code here
}
Can I do something similiar in IP? I'll take anything.
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Bug in urllib?
This is a bug. It has never worked—although it would be
great if it did. As noted in socket.__doc__, socket.makefile() (which
urllib.urlopen() depends on) is not implemented. We’re aware of the
problem, and I’ve filed a bug at http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=1368
to track it.
Here’s the long technical explanation why makefile() is
missing: CPython actually implements the socket module in two parts:
_socket.pyd (the main implementation written in C) and socket.py (a thin
wrapper written in Python). We originally planned to implement only the _socket
module (in C#) and have people use it with the standard socket.py module.
However, we discovered that socket.py depends on CPython’s refcounting
garbage collector work correctly, and so we had to modify our socket module to
work without socket.py. Unfortunately, makefile() is one of the things that socket.py
provides, and we haven’t had time yet to implement it.
--Bruce
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Mike Raath
Sent: Wednesday, July 26, 2006 12:53 AM
To: Discussion of IronPython
Subject: [IronPython] Bug in urllib?
I'm getting an error trying to
use urllib - AttributeError: 'socket' object has no attribute 'makefile' Using
1.0 RC1. Not sure if this has ever worked - get NotImplementedError:
getaddrinfo() is not currently implemented in the Beta 9.
>>> import sys
>>> sys.path.append("C:\\Python24\\Lib")
>>> import urllib
>>> f = urllib.urlopen("http://www.microsoft.com
")
Traceback (most recent call last):
File , line 0, in ##151
File C:\Python24\Lib\urllib.py, line 82, in urlopen
File C:\Python24\Lib\urllib.py, line 194, in open
File C:\Python24\Lib\urllib.py, line 316, in open_http
File C:\Python24\Lib\httplib.py, line 1150, in getreply
File C:\Python24\Lib\httplib.py, line 863, in getresponse
File C:\Python24\Lib\httplib.py, line 275, in __init__
AttributeError: 'socket' object has no attribute 'makefile'
Same on CPython 2.4 gives:
>>> import sys
>>> sys.path.append("C:\\Python24\\Lib")
>>> import urllib
>>> f = urllib.urlopen("
http://www.microsoft.com")
>>> print f.read()
(etc.)
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] NET Attributes.
Is it possible to use .NET attributes in IronPython? For example I have C# code that looks like:[CommandMethod("MyCommand", CommandFlags.Modal)]public static void RunMyCommand(){ 'code here
}Can I do something similiar in IP? I'll take anything.
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] When does data binding occur?
Do you call DataBind ? At 01:25 PM 7/25/2006, jeff sacksteder wrote >In my __init__ method, I create a DataGridview and set it's datasource to a >BindingSource previously created. If the very last line of my __init__ gets >the 'Rows' property of the DGV, it is an empty collection. I can get other >attributes( like 'Name') without any problem. If I get 'Rows' from outside the >__init__ method, I see what I expect. > >Is the binding delayed until the method returns? Is there anyway to force the >Rows to be populated so that that can be examined/manipulated before returning? J. Merrill / Analytical Software Corp ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] PythonEngine.EvaluateAs and future division
The following code gives different results. Is this expected
or a bug?
IronPython.Compiler.Options.Division =
IronPython.Compiler.DivisionOption.New;
PythonEngine _pe = new PythonEngine();
_pe.Execute("result1 = 1/2");
double result1 = Convert.ToDouble(_pe.Globals["result1"]);
double result2 =
_pe.EvaluateAs("1/2");
result1 = 0.5
result2 = 0.0
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Hosting question
I have been playing around with embedding IronPython into an application to provide scripting support for my .NET application. One thing that I have noticed is that to get the output from the interpreter you have to use EvalToConsole. So to capture the input, I have to use SetStandardOut to some memory stream, etc, etc. I played with Boo prior to IronPython and they had a cool feature of the interactive interpreter where there was an event for when the interpreter printed something to its standard output, so to get the output it was as easy as adding an event handler to that event. Is there anything in the works like this, or should I just continue piping the output to a memory stream and go from there? Thanks ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] profiling ipy apps
You could use a third-party product like Red-Gate software's "ANTS Profiler" -- http://red-gate.com/products/ants_profiler/index.htm There's a 14-day trial, and it's a lot cheaper than Team Suite (one copy is $295, 10 copies are <$160 per user). Buying hint: at the end of each month, the sales folks would like to get the sale into this month's activity and could likely be convinced to give you the "one year maintenance and support" for free (normally $74). At 08:02 PM 7/25/2006, Arman Bostani wrote >Hello all, > >Is there a recommended process for profiling ipy applications? >Understandably, the cpython profile module doesn't work (no >sys.setprofile). Also, CLR Profiler isn't geared towards performance >analysis. So, do I need to somehow run my ipy applications under VS >2005 Team Suite? > >Thanks, >-arman J. Merrill / Analytical Software Corp ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] ActiveX Winfowms and IronPython
Михаил Подгурский wrote: > Is there any way to add any ActiveX controls to WinForm in IronPython > code? Hi, The procedure should be similar to that used in C#. There are details about that here: http://www.codeproject.com/csharp/importactivex.asp. Basically, all you need to do is generate a managed wrapper for the ActiveX component using one of the tools in the .NET SDK: AxImp /source activex_control_path_name Once you have this wrapper, you import it into IronPython in the usual way (clr.AddReference), and can create instances of the control (you can browse the assembly that has been generated to find the control class using dir() in IronPython or the SDK tool ildasm) and add it to your windows form with ease. Please note, however, that this is all theory: I haven't actually tried doing this, but I can't see any obstacles to this working. That said, there may very will be some issues here, so I'd be interested to hear how you get on! Hope this helps, Max ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] __future__ is a little too magic for its own good
Jonathan Jacobs wrote: > This appears to happen with every other __future__ import I tried. Actually, I suppose this is because I don't have the Python stdlib in my path. So ignore that. :) > P.S. Icons! Whee!!! This still applies. -- Jonathan ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] __future__ is a little too magic for its own good
IronPython 1.0.60725 on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> with Traceback (most recent call last): File , line 0, in ##3 NameError: name 'with' not defined >>> from __future__ import with_statement Traceback (most recent call last): File , line 0, in ##4 File , line 0, in __import__##8 ImportError: No module named __future__ >>> with Traceback (most recent call last): SyntaxError: unexpected token (, line 1) This appears to happen with every other __future__ import I tried. P.S. Icons! Whee!!! -- Jonathan ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Bug in urllib?
I'm getting an error trying to use urllib - AttributeError: 'socket' object has no attribute 'makefile' Using 1.0 RC1. Not sure if this has ever worked - get NotImplementedError: getaddrinfo() is not currently implemented in the Beta 9.
>>> import sys>>> sys.path.append("C:\\Python24\\Lib")>>> import urllib>>> f = urllib.urlopen("http://www.microsoft.com
")Traceback (most recent call last): File , line 0, in ##151 File C:\Python24\Lib\urllib.py, line 82, in urlopen File C:\Python24\Lib\urllib.py, line 194, in open File C:\Python24\Lib\urllib.py, line 316, in open_http
File C:\Python24\Lib\httplib.py, line 1150, in getreply File C:\Python24\Lib\httplib.py, line 863, in getresponse File C:\Python24\Lib\httplib.py, line 275, in __init__AttributeError: 'socket' object has no attribute 'makefile'
Same on CPython 2.4 gives:>>> import sys>>> sys.path.append("C:\\Python24\\Lib")>>> import urllib>>> f = urllib.urlopen("
http://www.microsoft.com")>>> print f.read()
(etc.)
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] 'DataGridView' object has no attribute 'BeginInit'
BeginInit is an explicitly implemented interface (ISupportInitialize) method on the DataGridView class. To call it, you need to use the explicit syntax: grid = DataGridView( ... ) ISupportInitialize.BeginInit(grid) In this case we wanted to preserve the nature of explicitly implemented interface methods and allow them to be called in this manner only. Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cheemeng Sent: Tuesday, July 25, 2006 11:28 PM To: users@lists.ironpython.com Subject: [IronPython] 'DataGridView' object has no attribute 'BeginInit' hi IP team, the DataGridView object has no attribute BeginInit this is previously fix in 1.0 beta4 I think. cheemeng ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] 'DataGridView' object has no attribute 'BeginInit'
hi IP team, the DataGridView object has no attribute BeginInit this is previously fix in 1.0 beta4 I think. cheemeng ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] ImportError: No module named parser
Thanks for the response, Dino. FYI, what I wanted to use is miniconf 1.0.1 written by Sylvain Fourmanoit: http://cheeseshop.python.org/pypi/miniconf/1.0.1 Regards, 2006/7/26, Dino Viehland <[EMAIL PROTECTED]>: > Well, it's only a problem if you need the parser module :) I've opened > CodePlex work item 1347 for this - > http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=1347 > - it'll have to wait until after 1.0 at this point though because we're too > close to the 1.0 release. We've also had a similar request for better > quality checking tools support which rely on the parser module so this is > starting to look more compelling. Thanks for reporting this. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of HEMMI, Shigeru > Sent: Tuesday, July 25, 2006 12:19 AM > To: Discussion of IronPython > Subject: [IronPython] ImportError: No module named parser > > In IP, parser - an interface to Python's internal parser, is not implemented. > Is it a problem or not? > > IronPython 1.0.60712 (Beta) on .NET 2.0.50727.42 Copyright (c) Microsoft > Corporation. All rights reserved. > >>> import parser > Traceback (most recent call last): > File , line 0, in ##3 > File , line 0, in __import__##7 > ImportError: No module named parser > >>> > ___ > users mailing list > users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > ___ > users mailing list > users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] md5.py throws exception
Thanks. Ignore my other post reporting the same thing, mailing list seems a little slow at distributing things at the moment. On 7/26/06, Martin Maly <[EMAIL PROTECTED]> wrote: > This appears to be a bug in IronPython. I tried with Beta 8 and 9 and they > both worked, RC fails. I've filed the bug on CodePlex. It is a good one to > look at for the final release. > > Thanks for the report! > > Martin > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Rees > Sent: Tuesday, July 25, 2006 8:14 PM > To: Discussion of IronPython > Subject: [IronPython] md5.py throws exception > > On 7/26/06, Kevin Chu <[EMAIL PROTECTED]> wrote: > > I try this md5.py,but throw an exception! > > > > >>> import md5 > > >>> m=md5.new() > > Traceback (most recent call last): > > File , line 0, in ##12 > > File D:\TECH\IronPython\Lib\md5.py, line 31, in new > > File D:\TECH\IronPython\Lib\md5.py, line 15, in __init__ > > TypeError: multiple overloads of Create could match () > > Create() > > Create() > > It worked in previous betas, but hadn't tested against RC1 yet. Let me > have a look and see if I can fix. > > Mark > ___ > users mailing list > users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > ___ > users mailing list > users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] TypeError: multiple overloads of Create could match()
On 7/26/06 in another thread, Kevin Chu <[EMAIL PROTECTED]> wrote:
> I try this md5.py,but throw an exception!
>
> >>> import md5
> >>> m=md5.new()
> Traceback (most recent call last):
> File , line 0, in ##12
> File D:\TECH\IronPython\Lib\md5.py, line 31, in new
> File D:\TECH\IronPython\Lib\md5.py, line 15, in __init__
> TypeError: multiple overloads of Create could match ()
> Create()
> Create()
The MD5 class has 2 overloads for the Create method
Create()
Create(str)
In Beta 9:
m = MD5.Create() worked
but in RC1 it gives the error Kevin reported.
I get a similar error if I do:
m = MD5.Create("MD5")
Is this a bug?
Regards
Mark
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] md5.py throws exception
This appears to be a bug in IronPython. I tried with Beta 8 and 9 and they both worked, RC fails. I've filed the bug on CodePlex. It is a good one to look at for the final release. Thanks for the report! Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Rees Sent: Tuesday, July 25, 2006 8:14 PM To: Discussion of IronPython Subject: [IronPython] md5.py throws exception On 7/26/06, Kevin Chu <[EMAIL PROTECTED]> wrote: > I try this md5.py,but throw an exception! > > >>> import md5 > >>> m=md5.new() > Traceback (most recent call last): > File , line 0, in ##12 > File D:\TECH\IronPython\Lib\md5.py, line 31, in new > File D:\TECH\IronPython\Lib\md5.py, line 15, in __init__ > TypeError: multiple overloads of Create could match () > Create() > Create() It worked in previous betas, but hadn't tested against RC1 yet. Let me have a look and see if I can fix. Mark ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 1.0 RC1 is Released
I try this md5.py,but throw an exception! >>> import md5 >>> m=md5.new() Traceback (most recent call last): File , line 0, in ##12 File D:\TECH\IronPython\Lib\md5.py, line 31, in new File D:\TECH\IronPython\Lib\md5.py, line 15, in __init__ TypeError: multiple overloads of Create could match () Create() Create() 2006/7/26, Mark Rees <[EMAIL PROTECTED]>: > As an interim solution our friend Seo has an implementation of md5 for > IronPython. > > http://sparcs.kaist.ac.kr/~tinuviel/fepy/lib/ > > On 7/26/06, Kevin Chu <[EMAIL PROTECTED]> wrote: > > I am glade to hear about this greate news! > > Especially, it implemented a large number of the standard CPython > > built-in modules. > > But I found md5 module is not implemented yet! > > > > 2006/7/26, Dino Viehland <[EMAIL PROTECTED]>: > > > Hello IronPython Community, > > > > > > We have just released IronPython 1.0 RC1. We're anticipating that this > > > build will be the same as 1.0 final unless we hear otherwise. We're > > > looking for any feedback, but in particular we'd like to know of any > > > blocking issues discovered against this build or fundamental language > > > incompatibilities. Please try out the latest build over the next 2 weeks > > > and let us know if you encounter any issues as soon as possible. > > > Additionally, if there are any 1.01 Alpha bugs on CodePlex that are > > > blocking you please bring these to our attention so we can take a second > > > look at them. > > > > > > Our goal for IronPython 1.0 is to be compatible with CPython 2.4 We've > > > fixed all known language incompatibilities and implemented a large number > > > of the standard CPython built-in modules with a focus on those most used. > > > RC1 includes one new module that hasn't shipped previous (cPickle). We > > > do have some issues remaining but we believe these will not affect > > > compatability with CPython. In addition RC1 has several new 2.5 Python > > > features that can be enabled with the experimental switch -X:Python25, > > > but by default these are disabled: > > > > > > a. PEP 308: Conditional Expressions > > > b. PEP 343: The 'with' statement. (as per PEP 343, you need to do > > > 'from __future__ import with_statement' for enabling 'with' statement ) > > > c. Other Language Changes > > >1. The dict type has a new hook for letting subclasses provide a > > > default value with '__missing__' method. > > >2. Both 8-bit and Unicode strings have new partition(sep) and > > > rpartition(sep) methods. > > >3. The startswith() and endswith() methods of string types now > > > accept tuples of strings to check for. > > >4. The min() and max() built-in functions gained a 'key' keyword > > > parameter. > > >5. Two new built-in functions, any() and all(), evaluate whether > > > an iterator contains any true or false values. > > >6. The list of base classes in a class definition can now be empty. > > > > > > You can download the release from: http://www.CodePlex.com/IronPython > > > > > > We'd like to thank everyone in the community for your bug reports and > > > suggestions that helped make this a better release: audespc, Jonathan > > > Jacobs, Lee Culver, Luis M. Gonzalez, Miguel de Icaza, Mike Raath, > > > paparipote, Sanghyeon Seo, and Vincent Wehren. > > > > > > Thanks and keep in touch, > > > The IronPython Team > > > > > > More complete list of changes and bug fixes: > > > > > > Bugfix: 824 - IP Fails to trap AttributeError from __getattr__ > > > Bugfix: 825 - weakref.proxy needs all special methods > > > Bugfix: test_descr: two class init issues > > > Bugfix: test_descr: minor negative cases we're missing (classmethod, > > > __cmp__, __get__, read-only properties) > > > Bugfix: test_descr: dict compat issues > > > Bugfix: test_descr: four minor issues (wrong except on invalid format > > > string, hex is uppercase, moduletype, Ellipsis) > > > Bugfix: 872 - NullRef exception in finally w/o yield > > > ClrModule.Path was deprecated, to be removed in Beta 7, but it's still > > > there > > > Also removed sys.LoadAssemblyXXX methods > > > Tutorial Update: Added some bulletproofing to pyevent.py so that you > > > could only add callable objects to events, quietly handle removing > > > handlers that aren't there, and r > > > emoved some old/unused code. > > > Tutorial Update: Added comments to winforms to explain what it was doing > > > and why > > > Bugfix: 348 RE_Pattern.match matches start-of-string too optimistically > > > when endpos is specified > > > Bugfix: 438 os functions raise wrong exception types > > > Bugfix: 897 Memory leak in ClrModule > > > Bugfix: 901 SystemError when deriving from a parent class and a > > > grandparent class with __slots__ > > > Bugfix: 813 Builtin eval with dict subclass as locals does not work as in > > > CPython 2.4 > > > Bugfix: Add filename, lineno, offset and text to SyntaxErro
[IronPython] md5.py throws exception
On 7/26/06, Kevin Chu <[EMAIL PROTECTED]> wrote: > I try this md5.py,but throw an exception! > > >>> import md5 > >>> m=md5.new() > Traceback (most recent call last): > File , line 0, in ##12 > File D:\TECH\IronPython\Lib\md5.py, line 31, in new > File D:\TECH\IronPython\Lib\md5.py, line 15, in __init__ > TypeError: multiple overloads of Create could match () > Create() > Create() It worked in previous betas, but hadn't tested against RC1 yet. Let me have a look and see if I can fix. Mark ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython and Swig
Actually if this is a Python-based swig DLL then it won't work at all.
IronPython does not support loading of CPython based modules as of yet.
You'd have to ask the team if this is eventually planned.
Trying to do so will result in:
>>> from pyogre import ogre
Traceback (most recent call last):
File , line 0, in ##37
File [snip]\IronPython-1.0-Beta9\Lib\pyogre\ogre.py, line 4, in
Initialize
File , line 0, in __import__##7
ImportError: No module named _ogre
Since IronPython can't load .pyd files.
If swig was used to generate a C# library (instead of a Python library),
then it can be compiled into a DLL assembly and loaded exactly as Dino
says below...
-Lee
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Tuesday, July 25, 2006 5:43 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython and Swig
You'll need to tell us about the DLL first:
import clr
clr.AddReference('_myDll')
import someNamespaceOrTypeFrom_myDll
then we'll be able to load types & namespaces from it.
From: [EMAIL PROTECTED] On Behalf Of Lyle Thompson
Sent: Tuesday, July 25, 2006 5:42 PM
To: users@lists.ironpython.com
Subject: [IronPython] IronPython and Swig
Hi All,
I have a C++ DLL that I wrapped with Swig. Inside the python wrapper it
imports the DLL, i.e. "import _myDll". In IronPython, I get the error:
ImportError: No Module named _myDll.
I have made sure that the directory with my DLL is in both my PATH and
PYTHONPATH.
Does IronPython not support this usage of the import statement?
Thanks,
Lyle
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] speed
Yes the speed improvement in RC1 is much appreciated. I am doing an IronPython presentation at the Sydney Python User Group tomorrow evening, and was expecting negative comments about IronPython Console launch time. RC1 has given a 2.5 speedup. Thanks. Mark On 7/26/06, Luis M. Gonzalez <[EMAIL PROTECTED]> wrote: > So I see that Beta 9 was up to 12x slower, while the latest version is only > 3x slower. > Great speedup! > > Congratulations for the great job you and your team are doing (and thank > you!) > > Luis ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 1.0 RC1 is Released
As an interim solution our friend Seo has an implementation of md5 for IronPython. http://sparcs.kaist.ac.kr/~tinuviel/fepy/lib/ On 7/26/06, Kevin Chu <[EMAIL PROTECTED]> wrote: > I am glade to hear about this greate news! > Especially, it implemented a large number of the standard CPython > built-in modules. > But I found md5 module is not implemented yet! > > 2006/7/26, Dino Viehland <[EMAIL PROTECTED]>: > > Hello IronPython Community, > > > > We have just released IronPython 1.0 RC1. We're anticipating that this > > build will be the same as 1.0 final unless we hear otherwise. We're > > looking for any feedback, but in particular we'd like to know of any > > blocking issues discovered against this build or fundamental language > > incompatibilities. Please try out the latest build over the next 2 weeks > > and let us know if you encounter any issues as soon as possible. > > Additionally, if there are any 1.01 Alpha bugs on CodePlex that are > > blocking you please bring these to our attention so we can take a second > > look at them. > > > > Our goal for IronPython 1.0 is to be compatible with CPython 2.4 We've > > fixed all known language incompatibilities and implemented a large number > > of the standard CPython built-in modules with a focus on those most used. > > RC1 includes one new module that hasn't shipped previous (cPickle). We do > > have some issues remaining but we believe these will not affect > > compatability with CPython. In addition RC1 has several new 2.5 Python > > features that can be enabled with the experimental switch -X:Python25, but > > by default these are disabled: > > > > a. PEP 308: Conditional Expressions > > b. PEP 343: The 'with' statement. (as per PEP 343, you need to do 'from > > __future__ import with_statement' for enabling 'with' statement ) > > c. Other Language Changes > >1. The dict type has a new hook for letting subclasses provide a > > default value with '__missing__' method. > >2. Both 8-bit and Unicode strings have new partition(sep) and > > rpartition(sep) methods. > >3. The startswith() and endswith() methods of string types now > > accept tuples of strings to check for. > >4. The min() and max() built-in functions gained a 'key' keyword > > parameter. > >5. Two new built-in functions, any() and all(), evaluate whether an > > iterator contains any true or false values. > >6. The list of base classes in a class definition can now be empty. > > > > You can download the release from: http://www.CodePlex.com/IronPython > > > > We'd like to thank everyone in the community for your bug reports and > > suggestions that helped make this a better release: audespc, Jonathan > > Jacobs, Lee Culver, Luis M. Gonzalez, Miguel de Icaza, Mike Raath, > > paparipote, Sanghyeon Seo, and Vincent Wehren. > > > > Thanks and keep in touch, > > The IronPython Team > > > > More complete list of changes and bug fixes: > > > > Bugfix: 824 - IP Fails to trap AttributeError from __getattr__ > > Bugfix: 825 - weakref.proxy needs all special methods > > Bugfix: test_descr: two class init issues > > Bugfix: test_descr: minor negative cases we're missing (classmethod, > > __cmp__, __get__, read-only properties) > > Bugfix: test_descr: dict compat issues > > Bugfix: test_descr: four minor issues (wrong except on invalid format > > string, hex is uppercase, moduletype, Ellipsis) > > Bugfix: 872 - NullRef exception in finally w/o yield > > ClrModule.Path was deprecated, to be removed in Beta 7, but it's still there > > Also removed sys.LoadAssemblyXXX methods > > Tutorial Update: Added some bulletproofing to pyevent.py so that you could > > only add callable objects to events, quietly handle removing handlers that > > aren't there, and r > > emoved some old/unused code. > > Tutorial Update: Added comments to winforms to explain what it was doing > > and why > > Bugfix: 348 RE_Pattern.match matches start-of-string too optimistically > > when endpos is specified > > Bugfix: 438 os functions raise wrong exception types > > Bugfix: 897 Memory leak in ClrModule > > Bugfix: 901 SystemError when deriving from a parent class and a grandparent > > class with __slots__ > > Bugfix: 813 Builtin eval with dict subclass as locals does not work as in > > CPython 2.4 > > Bugfix: Add filename, lineno, offset and text to SyntaxError Exception when > > dealing with pure Python > > Bugfix: test_sys: Implement various missing sys functions WAS: Implement > > sys.settrace function > > Bugfix: cpython supports backslash to concat long string? > > Bugfix: clr.LoadAssemblyByName and LoadAssemblyByPartialName publish the > > assembly > > Bugfix: MethodBinder: choose which explicitly implemetned interface methods > > with the same name > > Bugfix: implement type.mro()Bugfix: test_isinstance: Assertion triggered > > for test case calling isinstance with a class that has n
Re: [IronPython] IronPython 1.0 RC1 is Released
This is FANTASTIC!I've made a quick announcments/thanks to the O'Reilly Windows DevCenter > http://www.oreillynet.com/windows/blog/2006/07/msironpython_ironpython_10_rc1_1.html < and furthermore plan to get a hold of Preston Gralla (the editor of the Windows DevCenter) to discuss the potential of starting up a column specific to the development needs of the IronPython development community. While I can't promise he'll go for it, with enough community interest/support suggesting this to be something of interest my guess the chances of interest will be greater than if no interest were to be showcased. While I have a couple ideas of how to present this to him, one area that I think would provide a TON of value would be to create an application "spotlight" area where, for example, you could write a tutorial/overview of the application of which I would list a quick summary and then a link to your blog entry. This brings you traffic and exposure, while providing a nice service to the O'Reilly community members to gain access to this content via the same source they're already subscribed to (the O'Reilly weblog feed) Would this be of interest to any of you if I were to move forward with the proposal to Preston? Feel free to respond to this post directly, or follow-up in a private thread, either way is fine by me.Thanks again to each of you involved with bringing this project into reality! On 7/25/06, Dino Viehland <[EMAIL PROTECTED]> wrote: Hello IronPython Community,We have just released IronPython 1.0 RC1. We're anticipating that this build will be the same as 1.0 final unless we hear otherwise. We're looking for any feedback, but in particular we'd like to know of any blocking issues discovered against this build or fundamental language incompatibilities. Please try out the latest build over the next 2 weeks and let us know if you encounter any issues as soon as possible. Additionally, if there are any 1.01 Alpha bugs on CodePlex that are blocking you please bring these to our attention so we can take a second look at them.Our goal for IronPython 1.0 is to be compatible with CPython 2.4 We've fixed all known language incompatibilities and implemented a large number of the standard CPython built-in modules with a focus on those most used. RC1 includes one new module that hasn't shipped previous (cPickle). We do have some issues remaining but we believe these will not affect compatability with CPython. In addition RC1 has several new 2.5 Python features that can be enabled with the experimental switch -X:Python25, but by default these are disabled: a. PEP 308: Conditional Expressions b. PEP 343: The 'with' statement. (as per PEP 343, you need to do 'from __future__ import with_statement' for enabling 'with' statement ) c. Other Language Changes1. The dict type has a new hook for letting subclasses provide a default value with '__missing__' method.2. Both 8-bit and Unicode strings have new partition(sep) and rpartition(sep) methods. 3. The startswith() and endswith() methods of string types now accept tuples of strings to check for.4. The min() and max() built-in functions gained a 'key' keyword parameter.5. Two new built-in functions, any() and all(), evaluate whether an iterator contains any true or false values. 6. The list of base classes in a class definition can now be empty.You can download the release from: http://www.CodePlex.com/IronPythonWe'd like to thank everyone in the community for your bug reports and suggestions that helped make this a better release: audespc, Jonathan Jacobs, Lee Culver, Luis M. Gonzalez, Miguel de Icaza, Mike Raath, paparipote, Sanghyeon Seo, and Vincent Wehren. Thanks and keep in touch,The IronPython TeamMore complete list of changes and bug fixes:Bugfix: 824 - IP Fails to trap AttributeError from __getattr__ Bugfix: 825 - weakref.proxy needs all special methodsBugfix: test_descr: two class init issuesBugfix: test_descr: minor negative cases we're missing (classmethod, __cmp__, __get__, read-only properties)Bugfix: test_descr: dict compat issues Bugfix: test_descr: four minor issues (wrong except on invalid format string, hex is uppercase, moduletype, Ellipsis)Bugfix: 872 - NullRef exception in finally w/o yieldClrModule.Path was deprecated, to be removed in Beta 7, but it's still there Also removed sys.LoadAssemblyXXX methodsTutorial Update: Added some bulletproofing to pyevent.py so that you could only add callable objects to events, quietly handle removing handlers that aren't there, and r emoved some old/unused code.Tutorial Update: Added comments to winforms to explain what it was doing and whyBugfix: 348 RE_Pattern.match matches start-of-string too optimistically when endpos is specifiedBugfix: 438 os functions raise wrong exception types Bugfix: 897 Memory leak in ClrModuleBugfix: 901 SystemError when deriving from a parent class and a grandparent class w
Re: [IronPython] IronPython 1.0 RC1 is Released
I am glade to hear about this greate news! Especially, it implemented a large number of the standard CPython built-in modules. But I found md5 module is not implemented yet! 2006/7/26, Dino Viehland <[EMAIL PROTECTED]>: > Hello IronPython Community, > > We have just released IronPython 1.0 RC1. We're anticipating that this build > will be the same as 1.0 final unless we hear otherwise. We're looking for > any feedback, but in particular we'd like to know of any blocking issues > discovered against this build or fundamental language incompatibilities. > Please try out the latest build over the next 2 weeks and let us know if you > encounter any issues as soon as possible. Additionally, if there are any > 1.01 Alpha bugs on CodePlex that are blocking you please bring these to our > attention so we can take a second look at them. > > Our goal for IronPython 1.0 is to be compatible with CPython 2.4 We've fixed > all known language incompatibilities and implemented a large number of the > standard CPython built-in modules with a focus on those most used. RC1 > includes one new module that hasn't shipped previous (cPickle). We do have > some issues remaining but we believe these will not affect compatability with > CPython. In addition RC1 has several new 2.5 Python features that can be > enabled with the experimental switch -X:Python25, but by default these are > disabled: > > a. PEP 308: Conditional Expressions > b. PEP 343: The 'with' statement. (as per PEP 343, you need to do 'from > __future__ import with_statement' for enabling 'with' statement ) > c. Other Language Changes >1. The dict type has a new hook for letting subclasses provide a > default value with '__missing__' method. >2. Both 8-bit and Unicode strings have new partition(sep) and > rpartition(sep) methods. >3. The startswith() and endswith() methods of string types now accept > tuples of strings to check for. >4. The min() and max() built-in functions gained a 'key' keyword > parameter. >5. Two new built-in functions, any() and all(), evaluate whether an > iterator contains any true or false values. >6. The list of base classes in a class definition can now be empty. > > You can download the release from: http://www.CodePlex.com/IronPython > > We'd like to thank everyone in the community for your bug reports and > suggestions that helped make this a better release: audespc, Jonathan Jacobs, > Lee Culver, Luis M. Gonzalez, Miguel de Icaza, Mike Raath, paparipote, > Sanghyeon Seo, and Vincent Wehren. > > Thanks and keep in touch, > The IronPython Team > > More complete list of changes and bug fixes: > > Bugfix: 824 - IP Fails to trap AttributeError from __getattr__ > Bugfix: 825 - weakref.proxy needs all special methods > Bugfix: test_descr: two class init issues > Bugfix: test_descr: minor negative cases we're missing (classmethod, __cmp__, > __get__, read-only properties) > Bugfix: test_descr: dict compat issues > Bugfix: test_descr: four minor issues (wrong except on invalid format string, > hex is uppercase, moduletype, Ellipsis) > Bugfix: 872 - NullRef exception in finally w/o yield > ClrModule.Path was deprecated, to be removed in Beta 7, but it's still there > Also removed sys.LoadAssemblyXXX methods > Tutorial Update: Added some bulletproofing to pyevent.py so that you could > only add callable objects to events, quietly handle removing handlers that > aren't there, and r > emoved some old/unused code. > Tutorial Update: Added comments to winforms to explain what it was doing and > why > Bugfix: 348 RE_Pattern.match matches start-of-string too optimistically when > endpos is specified > Bugfix: 438 os functions raise wrong exception types > Bugfix: 897 Memory leak in ClrModule > Bugfix: 901 SystemError when deriving from a parent class and a grandparent > class with __slots__ > Bugfix: 813 Builtin eval with dict subclass as locals does not work as in > CPython 2.4 > Bugfix: Add filename, lineno, offset and text to SyntaxError Exception when > dealing with pure Python > Bugfix: test_sys: Implement various missing sys functions WAS: Implement > sys.settrace function > Bugfix: cpython supports backslash to concat long string? > Bugfix: clr.LoadAssemblyByName and LoadAssemblyByPartialName publish the > assembly > Bugfix: MethodBinder: choose which explicitly implemetned interface methods > with the same name > Bugfix: implement type.mro()Bugfix: test_isinstance: Assertion triggered for > test case calling isinstance with a class that has no __bases__ attribute > Tutorial Update: Tweaks to text for winforms and avalon exercises. > Added test cases for COM interop > Bugfix: 1018 - Function call with expanded argument list passes values > incorrectly > Bugfix: AddReference* APIs eat exceptionsBugfix: Some of the > ClrModule.LoadAssemblyXxx methods swallow exceptions from the Assembly APIs > they
Re: [IronPython] speed
>> The only additional thing that I would have liked to see here would be a more complete description of the machine and version of .NET and IronPython that you were running against. Hi Jim, This is how I run this script: IronPython 1.0.60712 (Beta) on .NET 2.0.50727.42 (this is Beta 9) Intel celeron 2.0 - WinXP Professional 512 Mb RAM First pass: 30.7604572648 Second pass:29.9800466260 On the same machine with Cpython 2.4.2: First pass: 2.46591424329 Now with IronPython 1.0.60725 on .NET 2.0.50727.42 (RC 1): First pass: 7.52073545660 Second pass: 7.98481566791 So I see that Beta 9 was up to 12x slower, while the latest version is only 3x slower. Great speedup! Congratulations for the great job you and your team are doing (and thank you!) Luis ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] IronPython 1.0 RC1 is Released
Hello IronPython Community, We have just released IronPython 1.0 RC1. We're anticipating that this build will be the same as 1.0 final unless we hear otherwise. We're looking for any feedback, but in particular we'd like to know of any blocking issues discovered against this build or fundamental language incompatibilities. Please try out the latest build over the next 2 weeks and let us know if you encounter any issues as soon as possible. Additionally, if there are any 1.01 Alpha bugs on CodePlex that are blocking you please bring these to our attention so we can take a second look at them. Our goal for IronPython 1.0 is to be compatible with CPython 2.4 We've fixed all known language incompatibilities and implemented a large number of the standard CPython built-in modules with a focus on those most used. RC1 includes one new module that hasn't shipped previous (cPickle). We do have some issues remaining but we believe these will not affect compatability with CPython. In addition RC1 has several new 2.5 Python features that can be enabled with the experimental switch -X:Python25, but by default these are disabled: a. PEP 308: Conditional Expressions b. PEP 343: The 'with' statement. (as per PEP 343, you need to do 'from __future__ import with_statement' for enabling 'with' statement ) c. Other Language Changes 1. The dict type has a new hook for letting subclasses provide a default value with '__missing__' method. 2. Both 8-bit and Unicode strings have new partition(sep) and rpartition(sep) methods. 3. The startswith() and endswith() methods of string types now accept tuples of strings to check for. 4. The min() and max() built-in functions gained a 'key' keyword parameter. 5. Two new built-in functions, any() and all(), evaluate whether an iterator contains any true or false values. 6. The list of base classes in a class definition can now be empty. You can download the release from: http://www.CodePlex.com/IronPython We'd like to thank everyone in the community for your bug reports and suggestions that helped make this a better release: audespc, Jonathan Jacobs, Lee Culver, Luis M. Gonzalez, Miguel de Icaza, Mike Raath, paparipote, Sanghyeon Seo, and Vincent Wehren. Thanks and keep in touch, The IronPython Team More complete list of changes and bug fixes: Bugfix: 824 - IP Fails to trap AttributeError from __getattr__ Bugfix: 825 - weakref.proxy needs all special methods Bugfix: test_descr: two class init issues Bugfix: test_descr: minor negative cases we're missing (classmethod, __cmp__, __get__, read-only properties) Bugfix: test_descr: dict compat issues Bugfix: test_descr: four minor issues (wrong except on invalid format string, hex is uppercase, moduletype, Ellipsis) Bugfix: 872 - NullRef exception in finally w/o yield ClrModule.Path was deprecated, to be removed in Beta 7, but it's still there Also removed sys.LoadAssemblyXXX methods Tutorial Update: Added some bulletproofing to pyevent.py so that you could only add callable objects to events, quietly handle removing handlers that aren't there, and r emoved some old/unused code. Tutorial Update: Added comments to winforms to explain what it was doing and why Bugfix: 348 RE_Pattern.match matches start-of-string too optimistically when endpos is specified Bugfix: 438 os functions raise wrong exception types Bugfix: 897 Memory leak in ClrModule Bugfix: 901 SystemError when deriving from a parent class and a grandparent class with __slots__ Bugfix: 813 Builtin eval with dict subclass as locals does not work as in CPython 2.4 Bugfix: Add filename, lineno, offset and text to SyntaxError Exception when dealing with pure Python Bugfix: test_sys: Implement various missing sys functions WAS: Implement sys.settrace function Bugfix: cpython supports backslash to concat long string? Bugfix: clr.LoadAssemblyByName and LoadAssemblyByPartialName publish the assembly Bugfix: MethodBinder: choose which explicitly implemetned interface methods with the same name Bugfix: implement type.mro()Bugfix: test_isinstance: Assertion triggered for test case calling isinstance with a class that has no __bases__ attribute Tutorial Update: Tweaks to text for winforms and avalon exercises. Added test cases for COM interop Bugfix: 1018 - Function call with expanded argument list passes values incorrectly Bugfix: AddReference* APIs eat exceptionsBugfix: Some of the ClrModule.LoadAssemblyXxx methods swallow exceptions from the Assembly APIs they call, making debugging difficult Bugfix: 940 - Cannot cast OldClass to DynamicType exception when importing xml.dom.minidom Bugfix: 922 - __getitem__ is no longer callable w/ multiple indexesBugfix: 930 - Performance degradation between beta 8 and 9 doing multi-dimensional array copies Bugfix: CodeDom: Ignore empty Indent and always force it to indent Bugfix: 871 - Overriding __call
Re: [IronPython] IronPython and Swig
You'll need to tell us about the DLL first:
import clr
clr.AddReference('_myDll')
import someNamespaceOrTypeFrom_myDll
then we'll be able to load types & namespaces from it.
From: [EMAIL PROTECTED] On Behalf Of Lyle Thompson
Sent: Tuesday, July 25, 2006 5:42 PM
To: users@lists.ironpython.com
Subject: [IronPython] IronPython and Swig
Hi All,
I have a C++ DLL that I wrapped with Swig. Inside the python wrapper it
imports the DLL, i.e. "import _myDll". In IronPython, I get the error:
ImportError: No Module named _myDll.
I have made sure that the directory with my DLL is in both my PATH and
PYTHONPATH.
Does IronPython not support this usage of the import statement?
Thanks,
Lyle
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] IronPython and Swig
Hi All, I have a C++ DLL that I wrapped with Swig. Inside the python wrapper it imports the DLL, i.e. "import _myDll". In IronPython, I get the error: ImportError: No Module named _myDll. I have made sure that the directory with my DLL is in both my PATH and PYTHONPATH. Does IronPython not support this usage of the import statement? Thanks, Lyle ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython (PythonCodePovider) for ASP.NET?
On 7/26/06, Mark Rees <[EMAIL PROTECTED]> wrote: > It does give you access to "true" ASP.NET page generation, needs some > docs and a lillte more work. Opps, a small typo, I meant: It does not give you access to "true" ASP.NET page generation, Sorry if the typo got people excited. :-) Mark ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython (PythonCodePovider) for ASP.NET?
Dino wrote: The main concern is that we are shoe-horning a dynmamic language into a static world and that's not really the right thing to do. With enough effort we might be able to pull it off, but there might be a better way to go which enables ASP.NET w/o the feeling of it not being Python. There might also always be rough edges that we can never quite make work correctly - and given we've spent all this time making IronPython work like CPython we don't want to just throw that away. One pythonic way of "hosting" IronPython within ASP.NET is to use WSGI (http://wsgi.org/wsgi/What_is_WSGI) Seo did the original work and I have made his stuff more WSGI PEP compliant and work with the latest IronPython Beta hosting API. SInce Seo is not near a network connection for a few weeks and cannot add these changes to his code, I have put my changes up under subversion at: http://svn.isapi-wsgi.python-hosting.com/sandbox/mark/ironpy-wsgi/ It does give you access to "true" ASP.NET page generation, needs some docs and a lillte more work. But I have been using it for RSS/Atom feed generation from a ADO.NET database under both IIS ASP.NET and Apache mod_mono. This email post of Seo's should help you get going: http://lists.ironpython.com/pipermail/users-ironpython.com/2006-March/002049.html Mark ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] profiling ipy apps
Hello all, Is there a recommended process for profiling ipy applications? Understandably, the cpython profile module doesn't work (no sys.setprofile). Also, CLR Profiler isn't geared towards performance analysis. So, do I need to somehow run my ipy applications under VS 2005 Team Suite? Thanks, -arman ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] speed
You're correct that most of our work in getting to IronPython 1.0 has been
focused on completeness and correctness rather than performance. IronPython 1.0
is roughly as fast as IronPython 0.1 was - which is reasonably fast (see more
at the end of this message). As anyone who's built a large system knows, not
losing performance while achieving completeness and correctness is a challenge.
When we talk about IronPython performance, we try to reference specific
benchmarks. The standard line you'll see is, "IronPython is fast - up to 1.8x
faster than CPython on the standard pystone benchmark." Performance will vary
on different tasks.
Even though performance will vary, any time that IronPython is 21x slower than
CPython that should be considered a bug in IronPython and you should file it as
an issue on CodePlex. I ran your test script on my ThinkPad X60 laptop with a
1.83GHz Intel Core Duo processor and 1.5GB of RAM under Windows XP SP2 with the
final RTM release of .NET 2.0. Running your test with the 1.0beta9 release of
IronPython, I find that it is ~8x slower in IronPython than in CPython-2.4.
This is much better than your result, but still is not acceptable performance
for such a simple test case.
Over the past week, we looked into this more closely. There were two major
performance issues revealed by your test case. One was that the way we are
packaging our signed release builds caused worse performance than the standard
internal builds we tested on. The second issue was we had some bad performance
issues calling methods on builtin types. Both of these issues have been fixed
in the soon to be released IronPython 1.0 RC 1 (which you can build from the
current codeplex sources today). After the fix, I find that IronPython-1.0rc1
is about 2.2x slower than CPython-2.4 on your benchmark code. While I wish that
IronPython was faster on this test, for this stage of the project a ~2x
performance hit on some benchmarks is considered acceptable. There are other
benchmarks where IronPython will be 2x faster than CPython. In fact, I can
modify your test below to write it in a more abstract style and it will run
with roughly the same performance on IronPython as CPython.
import time
def do_x(i):
if i % 2:
return 10
else:
return "a string"
def do_z(i):
if isinstance(i, str):
return i.upper()
else:
return i*3
def test():
start= time.clock()
x = [do_x(i) for i in xrange(100)]
z = [do_z(i) for i in x]
end= time.clock() - start
print end
test() # pre-run to ignore initialization time
test()
I can't stress enough how much we appreciate this kind of performance bug
report. Because you included a small self-contained test script without any
external dependencies, it was easy for us to isolate the issues in IronPython
and get them fixed. Right now, we don't have the time to help people who are
encountering performance issues in complete apps, but we can address issues
when they are reported this clearly and are this easy to reproduce. The only
additional thing that I would have liked to see here would be a more complete
description of the machine and version of .NET and IronPython that you were
running against.
I mentioned at the start of this email that IronPython's performance hasn't
changed much from the 0.1 version. Keep in mind that IronPython 0.1 was a tiny
little translator that I wrote from Python to C# that had everything it needed
to run the pystone benchmark and nothing else. I'm quite excited that we've
been able to keep the good performance aspects of that initial prototype in the
1.0 release. Here's a copy of data from the original email that I sent about
IronPython 0.1:
Date: Mon, 8 Dec 2003 17:16:15 -0800
From: Jim Hugunin <[EMAIL PROTECTED]>
Subject: Python can run fast on the CLR
To: [EMAIL PROTECTED]
IronPython-0.1 Python-2.3 Python-2.1
pystone 0.581.001.29
function call 0.191.001.12
integer add 0.591.001.18
string.replace 0.921.001.00
range(bigint) 5.571.001.09
eval("2+2") 66.97 1.001.58
---
These numbers are measuring time to run each of the benchmarks and are all
relative to Python-2.3. Smaller number are better and indicate faster
performance. For IronPython 0.1, the performance on function calls and integer
add were both considerably faster than CPython, string.replace was roughly the
same speed, range was too slow and performance on eval("2+2") was horrible.
Out of curiosity, I reran these same benchmarks on 1.0rc1 as well as
CPython-2.4 and 2.5beta2 using the same machine as described above.
IronPython-1.0rc1 Python-2.5b2 Python-2.4
pystone
Re: [IronPython] IronPython & Windows Forms VII, Dock & Anchor
Thanks for pointing that out - I've updated it (removed the part #s, added the description names and all 7 articles). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Tuesday, July 25, 2006 3:17 PM To: users@lists.ironpython.com Subject: Re: [IronPython] IronPython & Windows Forms VII, Dock & Anchor Dino Viehland wrote: > I've added this to the list of articles at > http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython&title=More%20Information > (the other 4 were already up there). That's great, thanks. I'm getting quite a few hits from those links, so it looks like the subject is popular. For what it's worth, there are six others rather than four others. As each entry starts with links to the others it's not really an issue though... :-) All the best, Michael Foord http://www.voidspace.org.uk/python/index.shtml > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord > Sent: Saturday, July 22, 2006 12:44 PM > To: Discussion of IronPython > Subject: [IronPython] IronPython & Windows Forms VII, Dock & Anchor > > Hello all, > > I've completed another entry in the "IronPython & Windows Forms" series. > > > http://www.voidspace.org.uk/python/weblog/arch_d7_2006_07_22.shtml#e39 > 9 > > This one covers using the Dock and Anchor properties to layout controls in a > form. It is a short entry, but contains essential information for creating > any GUI application. > > The series has now covered all the essential basics. Hopefully the > next entries can put this information together and show how it can be > used. I won't be covering data binding just yet, we've got events, > images and dialogs (at least) to go through first... ;-) > > Oh, as usual, corrections and comments welcomed. > > All the best, > > Michael Foord > http://www.voidspace.org.uk/python/index.shtml > ___ > users mailing list > users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > ___ > users mailing list > users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython & Windows Forms VII, Dock & Anchor
Dino Viehland wrote: > I've added this to the list of articles at > http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython&title=More%20Information > (the other 4 were already up there). That's great, thanks. I'm getting quite a few hits from those links, so it looks like the subject is popular. For what it's worth, there are six others rather than four others. As each entry starts with links to the others it's not really an issue though... :-) All the best, Michael Foord http://www.voidspace.org.uk/python/index.shtml > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord > Sent: Saturday, July 22, 2006 12:44 PM > To: Discussion of IronPython > Subject: [IronPython] IronPython & Windows Forms VII, Dock & Anchor > > Hello all, > > I've completed another entry in the "IronPython & Windows Forms" series. > > http://www.voidspace.org.uk/python/weblog/arch_d7_2006_07_22.shtml#e399 > > This one covers using the Dock and Anchor properties to layout controls in a > form. It is a short entry, but contains essential information for creating > any GUI application. > > The series has now covered all the essential basics. Hopefully the next > entries can put this information together and show how it can be used. I > won't be covering data binding just yet, we've got events, images and dialogs > (at least) to go through first... ;-) > > Oh, as usual, corrections and comments welcomed. > > All the best, > > Michael Foord > http://www.voidspace.org.uk/python/index.shtml > ___ > users mailing list > users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > ___ > users mailing list > users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
