From bob at redivi.com  Fri Apr  1 00:16:56 2005
From: bob at redivi.com (Bob Ippolito)
Date: Thu, 31 Mar 2005 17:16:56 -0500
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <f2b57319050331135765963ea7@mail.gmail.com>
References: <695D7C410F74A644B5335E47FB73E17E0385461B@RED-MSG-52.redmond.corp.microsoft.com>
	<f2b57319050331135765963ea7@mail.gmail.com>
Message-ID: <9A05035E-7219-4042-A606-9F878A690005@redivi.com>

On Mar 31, 2005, at 4:57 PM, Anthony Tarlano wrote:

> On Thu, 31 Mar 2005 13:49:10 -0800, Jim Hugunin  
> <jimhug at microsoft.com> wrote:
>
>> Thanks for the feedback on names for IronPythonConsole.  I notice  
>> that
>> there were zero votes for keeping the name as is <wink>.
>>
>> The two names that had votes in favor of them were fepy and ironpy.
>> There were a few more of you in favor of fepy than ironpy for that
>> science geek charm; however, I didn't notice a strong outpouring of
>> feelings either way.  I'd prefer to go with ironpy for the 0.7.1  
>> release
>> and see what the response is.  This name is far from set in stone and
>> comments and suggestions are always welcome.
>>
> Sorry I didn't get my vote in before you close the ballot.. But I do
> what to register my vote for ipython
>
> Btw, that's what I have named the console already and it is natural
> for me to continue to type python with just a leading i.... Give it a
> try, I think you may like it..

I'm almost positive that this was stated earlier, but ipython is  
probably the worst possible choice.  IPython <http:// 
ipython.scipy.org>, an existing and popular Python project, already  
has a script of the same name (in lower case).  To top that, it is  
also an interactive interpreter.

-bob




From almondb at gmail.com  Fri Apr  1 00:39:58 2005
From: almondb at gmail.com (Brian Almond)
Date: Thu, 31 Mar 2005 14:39:58 -0800
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <695D7C410F74A644B5335E47FB73E17E0385461B@RED-MSG-52.redmond.corp.microsoft.com>
References: <695D7C410F74A644B5335E47FB73E17E0385461B@RED-MSG-52.redmond.corp.microsoft.com>
Message-ID: <21f1e270050331143932137355@mail.gmail.com>

Personally, I like ironpy.  I too was a little late in voting ;-)

I'm happy we're getting new releases at all, frankly.

(Jim - I meant to send this to the list the first time around not
direct to you, oops.)

On Thu, 31 Mar 2005 13:49:10 -0800, Jim Hugunin <jimhug at microsoft.com> wrote:
> Thanks for the feedback on names for IronPythonConsole.  I notice that
> there were zero votes for keeping the name as is <wink>.
> 
> The two names that had votes in favor of them were fepy and ironpy.
> There were a few more of you in favor of fepy than ironpy for that
> science geek charm; however, I didn't notice a strong outpouring of
> feelings either way.  I'd prefer to go with ironpy for the 0.7.1 release
> and see what the response is.  This name is far from set in stone and
> comments and suggestions are always welcome.
> 
> Thanks - Jim
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From reginald at rare-it.com  Fri Apr  1 00:46:35 2005
From: reginald at rare-it.com (R.R. Sprinkhuizen)
Date: Fri, 1 Apr 2005 00:46:35 +0200
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <21f1e270050331143932137355@mail.gmail.com>
Message-ID: <20050331224632.E32E284D49@che.dreamhost.com>

> Personally, I like ironpy.  I too was a little late in voting ;-)

Count me in. I don't like fepy.

> I'm happy we're getting new releases at all, frankly.

Me too, but very unhappy that it needs 2.0. Can't there be a 1.1 and a 2.0
version?

Cheers!
Reginald



  _____  

SwitchBL8's  <http://www.rare-it.com/b2e/blogs/switchbl8> gebazel





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050401/3b6d6629/attachment.html>

From mahs at telcopartners.com  Fri Apr  1 01:26:43 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Thu, 31 Mar 2005 15:26:43 -0800
Subject: [IronPython] Re: Renaming IronPythonConsole
In-Reply-To: <21f1e270050331143932137355@mail.gmail.com>
References: <695D7C410F74A644B5335E47FB73E17E0385461B@RED-MSG-52.redmond.corp.microsoft.com>
	<21f1e270050331143932137355@mail.gmail.com>
Message-ID: <d2i10e$vc3$1@sea.gmane.org>

Brian Almond wrote:
> Personally, I like ironpy.  I too was a little late in voting ;-)
> 
The name doesn't matter much to me - I rarely invoke the console directly - but 
my reaction to ironpy was the same as Google's: Did you mean: irony.

> I'm happy we're getting new releases at all, frankly.
> 
+1


Michael



From thane at magna-capital.com  Fri Apr  1 01:38:50 2005
From: thane at magna-capital.com (Thane)
Date: Thu, 31 Mar 2005 16:38:50 -0700
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <f2b57319050331135765963ea7@mail.gmail.com>
Message-ID: <20050331233854.7D69B84D49@che.dreamhost.com>

I think it would be nice to have "Python" in the name.  
Imagine the book title:

	"Programming in ___________________"

		A.  IronPythonConsole
		B.  FePy
		C.  IronPy
		D.  IronPython

Choice "D" gets my vote - it's not too hard to type the last 4 letters of
Python.  It adds a lot to the name for people who may have heard of Python
but not IronPython.

Although the distribution name (*.exe) doesn't have to be the same as the
"official" name, it certainly helps to keep things as simple and clear as
reasonably possible.

--Thane


> -----Original Message-----
> From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-
> ironpython.com-bounces at lists.ironpython.com] On Behalf Of Anthony Tarlano
> Sent: Thursday, March 31, 2005 2:57 PM
> To: Jim Hugunin
> Cc: users-ironpython.com at lists.ironpython.com
> Subject: Re: [IronPython] Renaming IronPythonConsole
> 
> Jim,
> 
> Sorry I didn't get my vote in before you close the ballot.. But I do
> what to register my vote for ipython
> 
> Btw, that's what I have named the console already and it is natural
> for me to continue to type python with just a leading i.... Give it a
> try, I think you may like it..
> 
> Anthony
> 
> 
> 
> 
> On Thu, 31 Mar 2005 13:49:10 -0800, Jim Hugunin <jimhug at microsoft.com>
> wrote:
> > Thanks for the feedback on names for IronPythonConsole.  I notice that
> > there were zero votes for keeping the name as is <wink>.
> >
> > The two names that had votes in favor of them were fepy and ironpy.
> > There were a few more of you in favor of fepy than ironpy for that
> > science geek charm; however, I didn't notice a strong outpouring of
> > feelings either way.  I'd prefer to go with ironpy for the 0.7.1 release
> > and see what the response is.  This name is far from set in stone and
> > comments and suggestions are always welcome.
> >
> > Thanks - Jim
> > _______________________________________________
> > users-ironpython.com mailing list
> > users-ironpython.com at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com




From abubakarm at gmail.com  Fri Apr  1 06:30:10 2005
From: abubakarm at gmail.com (Muhammad Abubakar)
Date: Fri, 1 Apr 2005 09:30:10 +0500
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <695D7C410F74A644B5335E47FB73E17E0385461B@RED-MSG-52.redmond.corp.microsoft.com>
References: <695D7C410F74A644B5335E47FB73E17E0385461B@RED-MSG-52.redmond.corp.microsoft.com>
Message-ID: <c40f6d3505033120302a07bd7c@mail.gmail.com>

every time I read ironpy my mind recalls "american pie" movie :). But
its cool name.

Ab.

On Apr 1, 2005 2:49 AM, Jim Hugunin <jimhug at microsoft.com> wrote:
> Thanks for the feedback on names for IronPythonConsole.  I notice that
> there were zero votes for keeping the name as is <wink>.
> 
> The two names that had votes in favor of them were fepy and ironpy.
> There were a few more of you in favor of fepy than ironpy for that
> science geek charm; however, I didn't notice a strong outpouring of
> feelings either way.  I'd prefer to go with ironpy for the 0.7.1 release
> and see what the response is.  This name is far from set in stone and
> comments and suggestions are always welcome.
> 
> Thanks - Jim
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From swaroopch at gmail.com  Fri Apr  1 06:33:09 2005
From: swaroopch at gmail.com (Swaroop C H)
Date: Fri, 1 Apr 2005 10:03:09 +0530
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <695D7C410F74A644B5335E47FB73E17E0385461B@RED-MSG-52.redmond.corp.microsoft.com>
References: <695D7C410F74A644B5335E47FB73E17E0385461B@RED-MSG-52.redmond.corp.microsoft.com>
Message-ID: <351e88710503312033152ca6eb@mail.gmail.com>

On Apr 1, 2005 3:19 AM, Jim Hugunin <jimhug at microsoft.com> wrote:
> The two names that had votes in favor of them were fepy and ironpy.

I think 'ironpython' is the best choice. I don't believe that an extra
4 characters is going to make such a big difference. Having the
command line name and the software name as the same leads to lesser
confusion.


-- 
Swaroop C H
Blog: http://www.swaroopch.info
Book: http://www.byteofpython.info


From sriramk at gmail.com  Fri Apr  1 06:34:47 2005
From: sriramk at gmail.com (Sriram Krishnan)
Date: Fri, 1 Apr 2005 10:04:47 +0530
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <20050331224632.E32E284D49@che.dreamhost.com>
Message-ID: <424ccf7b.19cec34b.6d70.6938@mx.gmail.com>

>>Me too, but very unhappy that it needs 2.0. Can't there be a 1.1 and a 2.0
version?
 
I don't think that would be possible - IronPython makes heavy use of 2.0
specific features such as Lightweight Code Generation
 
Thanks,
Sriram

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of R.R.
Sprinkhuizen
Sent: 01 April 2005 04:17
To: users-ironpython.com at lists.ironpython.com
Subject: RE: [IronPython] Renaming IronPythonConsole



> Personally, I like ironpy.  I too was a little late in voting ;-)

Count me in. I don't like fepy.

> I'm happy we're getting new releases at all, frankly.

Me too, but very unhappy that it needs 2.0. Can't there be a 1.1 and a 2.0
version?

Cheers!
Reginald



________________________________

SwitchBL8's gebazel <http://www.rare-it.com/b2e/blogs/switchbl8> 








From bob at redivi.com  Fri Apr  1 06:47:47 2005
From: bob at redivi.com (Bob Ippolito)
Date: Thu, 31 Mar 2005 23:47:47 -0500
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <424ccf7b.19cec34b.6d70.6938@mx.gmail.com>
References: <424ccf7b.19cec34b.6d70.6938@mx.gmail.com>
Message-ID: <a27ac579e14420690a279753dfc45e5e@redivi.com>


On Mar 31, 2005, at 11:34 PM, Sriram Krishnan wrote:

>>> Me too, but very unhappy that it needs 2.0. Can't there be a 1.1 and 
>>> a 2.0
> version?
>
> I don't think that would be possible - IronPython makes heavy use of 
> 2.0
> specific features such as Lightweight Code Generation

Also, it's clearly not production material yet, so why would you need 
to use it on a legacy runtime?

-bob



From martin-list-1 at axure.com  Fri Apr  1 11:03:45 2005
From: martin-list-1 at axure.com (Martin Smith)
Date: Fri, 1 Apr 2005 01:03:45 -0800
Subject: [IronPython] Generics support in IronPython
Message-ID: <200504010403890.SM01516@martin>

Hi,

Will IronPython support generics?

Also, is support for calling python code from other CLR languages scoped for
1.0?  It would be a particularly useful to be able to call compiled python
code from C#, or, even better, extend python classes in C#.

Keep up the great work.  I'm looking forward to the day I can write ASP.NET
applications in python!

Best regards,

Martin Smith




From P at draigBrady.com  Fri Apr  1 12:13:26 2005
From: P at draigBrady.com (P at draigBrady.com)
Date: Fri, 01 Apr 2005 11:13:26 +0100
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <695D7C410F74A644B5335E47FB73E17E0385461B@RED-MSG-52.redmond.corp.microsoft.com>
References: <695D7C410F74A644B5335E47FB73E17E0385461B@RED-MSG-52.redmond.corp.microsoft.com>
Message-ID: <424D1EC6.1070003@draigBrady.com>

Jim Hugunin wrote:
> Thanks for the feedback on names for IronPythonConsole.  I notice that
> there were zero votes for keeping the name as is <wink>.
> 
> The two names that had votes in favor of them were fepy and ironpy.

ironpy is very like irony, so maybe pirony would be better?
More seriously how about piron or pyron?

-- 
P?draig Brady - http://www.pixelbeat.org
--


From terry at triplett.org  Fri Apr  1 18:17:55 2005
From: terry at triplett.org (Terry L. Triplett)
Date: Fri, 1 Apr 2005 11:17:55 -0500
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <424D1EC6.1070003@draigBrady.com>
References: <695D7C410F74A644B5335E47FB73E17E0385461B@RED-MSG-52.redmond.corp.microsoft.com>
	<424D1EC6.1070003@draigBrady.com>
Message-ID: <200504011117.56070.terry@triplett.org>

On Friday 01 April 2005 05:13, P at draigBrady.com wrote:
> Jim Hugunin wrote:
> > Thanks for the feedback on names for IronPythonConsole.  I notice that
> > there were zero votes for keeping the name as is <wink>.
> >
> > The two names that had votes in favor of them were fepy and ironpy.

Not to contribute to the proliferation of name suggestions, but (one serious 
suggestion and a couple of unserious ones):

Java + python = jython => .NET + python = nython

and with tongue in cheek:

Microsoft + python + embrace/extend = mython
Microsoft + fear of OSS + shared source = shython


From mailinglist.account at gmail.com  Fri Apr  1 21:14:24 2005
From: mailinglist.account at gmail.com (Anthony Tarlano)
Date: Fri, 1 Apr 2005 21:14:24 +0200
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <200504011117.56070.terry@triplett.org>
References: <695D7C410F74A644B5335E47FB73E17E0385461B@RED-MSG-52.redmond.corp.microsoft.com>
	<424D1EC6.1070003@draigBrady.com>
	<200504011117.56070.terry@triplett.org>
Message-ID: <f2b5731905040111145cc3e8a2@mail.gmail.com>

I take back my vote for ipython and throw my entire one vote behind nython...

"Programming in Nython" ... 

Anthony

On Apr 1, 2005 6:17 PM, Terry L. Triplett <terry at triplett.org> wrote:
> On Friday 01 April 2005 05:13, P at draigBrady.com wrote:
> > Jim Hugunin wrote:
> > > Thanks for the feedback on names for IronPythonConsole.  I notice that
> > > there were zero votes for keeping the name as is <wink>.
> > >
> > > The two names that had votes in favor of them were fepy and ironpy.
> 
> Not to contribute to the proliferation of name suggestions, but (one serious
> suggestion and a couple of unserious ones):
> 
> Java + python = jython => .NET + python = nython
> 
> and with tongue in cheek:
> 
> Microsoft + python + embrace/extend = mython
> Microsoft + fear of OSS + shared source = shython
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From theller at python.net  Fri Apr  1 22:06:30 2005
From: theller at python.net (Thomas Heller)
Date: Fri, 01 Apr 2005 22:06:30 +0200
Subject: [IronPython] Re: Renaming IronPythonConsole
References: <695D7C410F74A644B5335E47FB73E17E0385461B@RED-MSG-52.redmond.corp.microsoft.com>
	<424D1EC6.1070003@draigBrady.com>
	<200504011117.56070.terry@triplett.org>
Message-ID: <3buai7nd.fsf@python.net>

"Terry L. Triplett" <terry at triplett.org> writes:

> Microsoft + fear of OSS + shared source = shython

Sounds somewhat like the german 'scheissen'.



From reginald at rare-it.com  Fri Apr  1 22:31:29 2005
From: reginald at rare-it.com (R.R. Sprinkhuizen)
Date: Fri, 1 Apr 2005 22:31:29 +0200
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <a27ac579e14420690a279753dfc45e5e@redivi.com>
Message-ID: <20050401203143.3DFC818183@olive.qinip.net>

I guess you're right: by the time IronPython (or whatever the name will be)
is production ready, everybody will have 2.0 on their machine. Right? I
guess it's just another Microsoft way of saying: you must upgrade to 2.0. I
don't like that tone. I like Python, I like the addition of .NET and I liked
the way that IronPython *was* licensed.

-----Original Message-----
From: Bob Ippolito [mailto:bob at redivi.com] 
Sent: vrijdag 1 april 2005 6:48
To: Sriram Krishnan
Cc: 'R.R. Sprinkhuizen'; users-ironpython.com at lists.ironpython.com
Subject: Re: [IronPython] Renaming IronPythonConsole


On Mar 31, 2005, at 11:34 PM, Sriram Krishnan wrote:

>>> Me too, but very unhappy that it needs 2.0. Can't there be a 1.1 and 
>>> a 2.0
> version?
>
> I don't think that would be possible - IronPython makes heavy use of 
> 2.0 specific features such as Lightweight Code Generation

Also, it's clearly not production material yet, so why would you need to use
it on a legacy runtime?

-bob








From bob at redivi.com  Fri Apr  1 23:56:04 2005
From: bob at redivi.com (Bob Ippolito)
Date: Fri, 1 Apr 2005 16:56:04 -0500
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <20050401203143.3DFC818183@olive.qinip.net>
References: <20050401203143.3DFC818183@olive.qinip.net>
Message-ID: <23710692b4d48b1a6d510f1c97c18c27@redivi.com>

On Apr 1, 2005, at 15:31, R.R. Sprinkhuizen wrote:

> I guess you're right: by the time IronPython (or whatever the name 
> will be)
> is production ready, everybody will have 2.0 on their machine. Right? I
> guess it's just another Microsoft way of saying: you must upgrade to 
> 2.0. I
> don't like that tone. I like Python, I like the addition of .NET and I 
> liked
> the way that IronPython *was* licensed.

Microsoft is paying for it, they can do whatever makes sense for them.  
You're lucky that it's as liberally licensed as it is!

I have no problems with them requiring the latest and greatest .NET 
runtime, especially because it has features designed to support use 
cases like IronPython... and will grow them as necessary *because* 
Microsoft is supporting IronPython.

If you liked it better with the old license and old requirements, fork 
the old one.

-bob



From reginald at rare-it.com  Sat Apr  2 00:04:45 2005
From: reginald at rare-it.com (R.R. Sprinkhuizen)
Date: Sat, 2 Apr 2005 00:04:45 +0200
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <23710692b4d48b1a6d510f1c97c18c27@redivi.com>
Message-ID: <20050401220455.3510D84D4D@che.dreamhost.com>


> If you liked it better with the old license and old requirements, fork the
old one.

If I had that kind of programming capabilities, I wouldn't be here whining
about 2.0, now would I?

Cheers!
Reginald






From joe at notcharles.ca  Sat Apr  2 03:09:07 2005
From: joe at notcharles.ca (Joe Mason)
Date: Fri, 01 Apr 2005 20:09:07 -0500
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <20050401220455.3510D84D4D@che.dreamhost.com>
References: <23710692b4d48b1a6d510f1c97c18c27@redivi.com>
	<20050401220455.3510D84D4D@che.dreamhost.com>
Message-ID: <20050402010907.GA4268@notcharles.ca>

On Sat, Apr 02, 2005 at 12:04:45AM +0200, R.R. Sprinkhuizen wrote:
> 
> > If you liked it better with the old license and old requirements, fork the
> old one.
> 
> If I had that kind of programming capabilities, I wouldn't be here whining
> about 2.0, now would I?

So put up some money to have someone else do it... I'd be willing.

Or contribute organizational and management skills to a forking project
and try to attract coders to work on it.

Joe


From KarmaSlave at MyRealBox.com  Sat Apr  2 03:08:21 2005
From: KarmaSlave at MyRealBox.com (Burning)
Date: Fri, 01 Apr 2005 20:08:21 -0500
Subject: [IronPython] VS 2005/#Develop/MonoDevelop plugins
In-Reply-To: <C3134A7926032341A87978BFDF6863470277895A@westgate.melbourne.infogrames.loc>
References: <C3134A7926032341A87978BFDF6863470277895A@westgate.melbourne.infogrames.loc>
Message-ID: <424DF085.4020000@MyRealBox.com>

Writing the IDE plug-in for Visual Studio or SharpDevelop might be more 
beneficial to IronPython if the plugin is written in IronPython (!). The 
Boo plug-in for SharpDevelop exposed a few bugs in Boo that nobody had 
really noticed before, which was convient, to say the least.

Not that I'm volunteering.

Cartwright, Iain wrote:

>For dev's coming from a Windows/.NET environment IDE plug-ins are in my
>opinion a real drawcard. It would really aid the progress and adoption of
>IronPython if these are made available as soon as possible.
>
>I am guessing that this is beyond the scope of Jim and Martin's tasks.
>Perhaps this would make a good ironpy community project?
>
>VS 2005
>I have looked briefly at the MS VSIP SDK
>(http://msdn.microsoft.com/vstudio/extend/) - It appears to be a lot of work
>to get full language support + integrated help + ironpy window.
>
>#Develop
>The Boo folks have working code that might be useful as a basis for a
>#develop plug-in.
>
>MonoDevelop
>Appears to use the same/similar plug-in format to #Develop.
>
>It would of course be best to have MS do the VS 2005 plug-in and release it
>as (shared source) example code for the VSIP program maybe?
>
>iain
>_______________________________________________
>users-ironpython.com mailing list
>users-ironpython.com at lists.ironpython.com
>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>  
>



From jimhug at microsoft.com  Sat Apr  2 03:17:30 2005
From: jimhug at microsoft.com (Jim Hugunin)
Date: Fri, 1 Apr 2005 17:17:30 -0800
Subject: [IronPython] Generics support in IronPython
Message-ID: <695D7C410F74A644B5335E47FB73E17E03898B3B@RED-MSG-52.redmond.corp.microsoft.com>

Martin Smith wrote:
> Will IronPython support generics?

Here's the short answer to your question:

>>> from System.Collections.Generic import *
>>> l = List[str]()
>>> l.Add('hi')
>>> list(l)
['hi']
>>> l.Add(42)
System.Exception: bad args to this method <method# Add on
<snip>

This works today and creates a List<String>.  All of the methods have
the right signatures and will be dynamically checked like any other CLR
library code called from Python.  The syntax is the same as Guido
proposed in his blog entry on optional static types here:
  http://www.artima.com/weblogs/viewpost.jsp?thread=86641

There are still many open design questions about how generics and a
dynamic language can best work together, but most of the obvious things
just work in IronPython today.  This is easy on the CLR because all of
the information about generic type instantiations is kept at runtime so
the standard reflective type inspection work just does the right thing.

> Also, is support for calling python code from other CLR languages
scoped
> for
> 1.0?  It would be a particularly useful to be able to call compiled
python
> code from C#, or, even better, extend python classes in C#.

Absolutely.  You can already do some of this today where code that
expects a delegate can be passed a Python function which will look just
like a delegate to the C#/VB/etc programmer.  The next level is to
provide some sort of static compilation to a .dll or .exe and that's
clearly on the 1.0 todo list, but not something you should expect
tomorrow.

Extending a Python class in C# is an interesting challenge, and that
might be outside of the scope of 1.0.  BTW - extending C# classes in
Python is something that works pretty well today and will only get
better.  I'm not sure how much of a Python class's dynamic nature you'd
have to give up in order to make extending it from C# a sensible thing
to do.  This one will need some more thought. 

> Keep up the great work.  I'm looking forward to the day I can write
> ASP.NET
> applications in python!

I look forward to that day as well.  I don't think it's that far off
anymore.

Thanks - Jim


From kfarmer at thuban.org  Sat Apr  2 04:38:37 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Fri, 1 Apr 2005 18:38:37 -0800
Subject: [IronPython] Generics support in IronPython
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F82@nostromo.circle-cross.home>

So that shows consumption -- is creation supported?
 
Very cool

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Jim Hugunin
Sent: Fri 4/1/2005 5:17 PM
To: Martin Smith; users-ironpython.com at lists.ironpython.com
Subject: RE: [IronPython] Generics support in IronPython



Martin Smith wrote:
> Will IronPython support generics?

Here's the short answer to your question:

>>> from System.Collections.Generic import *
>>> l = List[str]()
>>> l.Add('hi')
>>> list(l)
['hi']
>>> l.Add(42)
System.Exception: bad args to this method <method# Add on
<snip>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3856 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050401/be932a24/attachment.bin>

From firemoth at gmail.com  Sat Apr  2 05:23:02 2005
From: firemoth at gmail.com (Timothy Fitz)
Date: Fri, 1 Apr 2005 19:23:02 -0800
Subject: [IronPython] CPython access
Message-ID: <972ec5bd050401192368b86bc5@mail.gmail.com>

Where there be any plans for allowing IronPython to work with an
instance of CPython directly? There are quite a few instances where
this would be extremely handy (SWIG-wrapped libraries such as
wxPython, or tightly optimized pieces that deal directly with
operating system concepts such as Twisted reactors where rewriting in
IronPython or converting may not be trivial enough)

As a sidenote, I believe the compiler was originally prototyped in
python, why was C# chosen as a language? System.Reflection.Emit argues
for itself, however it is easily accessed from CPython with Python for
.NET, and that code would be a simply bootstrapping stage that could
be moved into IronPython code.


From martmaly at exchange.microsoft.com  Sat Apr  2 10:10:04 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Sat, 2 Apr 2005 00:10:04 -0800
Subject: [IronPython] IronPython 0.7.1 released
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7C81@df-chewy-msg.exchange.corp.microsoft.com>


We are excited to announce the release of IronPython 0.7.1.  The
improvements over the recent 0.7 release are mostly bug fixes for bugs
reported by the community and suggestions from the mailing lists and
message boards:

* Slicing operator parsing and runtime implementation
* Descending sequences in xrange and range
* implementation of "del", "assert" and "iter(a,b)"
* issubclass throws correct exception on invalid arguments
* multiplication of string and int (5 * 's')
* division of complex numbers
* comparison of large numbers
* iteritems on dict
* correct exception thrown when accessing dictionary with the missing
key
* inheritance from classes with no public constructor
  (reported as "Cannot inherit from MarshalByRefObject")
* Delegate objects can be explicitly created
* Trivial Makefile included
* The distribution unzips into the directory named "IronPython-0.7.1"

Our thanks go to the following members of the community who reported the
bugs:

MadMccoy, remani, perhaps, jeffhi, vargaz, spencermah, tarlano, Sriram
Krishnan, lupus

You might notice that the interactive interpreter is still called
IronPythonConsole.exe.  There's been a lot of interesting discussion on
this list about names and we decided to take a little more time with
that discussion before rushing in a new name here.  By keeping the old
name those of you with existing scripts can keep using them unchanged
and the name is still bad enough to make it clear we're still looking
for a final one.

Thanks and keep in touch,
The IronPython Team

http://workspaces.gotdotnet.com/ironpython
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
http://www.microsoft.com/downloads/details.aspx?FamilyID=cf952fdb-2344-4
b1e-b169-3f5dfbca2984&DisplayLang=en



From mahs at telcopartners.com  Sat Apr  2 23:31:13 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Sat, 02 Apr 2005 13:31:13 -0800
Subject: [IronPython] Re: IronPython 0.7.1 released
In-Reply-To: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7C81@df-chewy-msg.exchange.corp.microsoft.com>
References: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7C81@df-chewy-msg.exchange.corp.microsoft.com>
Message-ID: <d2n2ul$plh$1@sea.gmane.org>

Martin Maly wrote:
> We are excited to announce the release of IronPython 0.7.1.  The
> improvements over the recent 0.7 release are mostly bug fixes for bugs
> reported by the community and suggestions from the mailing lists and
> message boards:
> 
Thanks for the new release (on schedule!).  I have submitted a number of bugs in 
this version.  (It appears there is nowhere on the bug-form to note which 
version they apply to.)

I also can't find a statement of which Python version fepy 0.7 is intended to 
match - I have assumed 2.3.3.  What is your goal?  Do you want discrepancies 
with 2.4/2.5 behavior reported?

You don't include a test suite with the source.  Do you have a plan for one? 
ISTM it would be a good idea to share tests with pypy.

Michael



From mahs at telcopartners.com  Sun Apr  3 00:24:03 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Sat, 02 Apr 2005 14:24:03 -0800
Subject: [IronPython] Missing builtins
Message-ID: <d2n61n$1dq$1@sea.gmane.org>

Here is the set of built-ins that 2.3.3 has and that fepy 0.7.1 lacks.  Absence 
from this list does not mean an object is correctly implemented.

Functions:
  callable (reported as bug)
  locals (reported as bug)
  vars
  __import__
  input
  reload
  raw_input

Types:
  file
  buffer

Deprecated
  coerce

Runtime/introspection
  __doc__
  __name__

Information:
  copyright
  credits
  license


Michael



From joe at notcharles.ca  Sun Apr  3 01:16:09 2005
From: joe at notcharles.ca (Joe Mason)
Date: Sat, 02 Apr 2005 18:16:09 -0500
Subject: [IronPython] Missing builtins
In-Reply-To: <d2n61n$1dq$1@sea.gmane.org>
References: <d2n61n$1dq$1@sea.gmane.org>
Message-ID: <20050402231609.GA6094@notcharles.ca>

On Sat, Apr 02, 2005 at 02:24:03PM -0800, Michael Spencer wrote:
> Here is the set of built-ins that 2.3.3 has and that fepy 0.7.1 lacks.  
> Absence from this list does not mean an object is correctly implemented.

Is this list exhaustive, or only what you've noticed so far?

Joe


From mahs at telcopartners.com  Sun Apr  3 01:12:41 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Sat, 02 Apr 2005 15:12:41 -0800
Subject: [IronPython] Re: Missing builtins
In-Reply-To: <20050402231609.GA6094@notcharles.ca>
References: <d2n61n$1dq$1@sea.gmane.org> <20050402231609.GA6094@notcharles.ca>
Message-ID: <d2n8ss$7g8$1@sea.gmane.org>

Joe Mason wrote:
> On Sat, Apr 02, 2005 at 02:24:03PM -0800, Michael Spencer wrote:
> 
>>Here is the set of built-ins that 2.3.3 has and that fepy 0.7.1 lacks.  
>>Absence from this list does not mean an object is correctly implemented.
> 
> 
> Is this list exhaustive, or only what you've noticed so far?
> 
> Joe
It is intended to be exhaustive, generated from 2.3.3 with:

 >>> for obj in vars(__builtin__):
... 	if obj not in checkbi.fepy:
... 	    print obj
... 		

where checkbi.fepy is a cut'n'paste copy of dir(__builtin__) in fepy 0.7.1

Michael



From martmaly at exchange.microsoft.com  Sun Apr  3 01:25:13 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Sat, 2 Apr 2005 15:25:13 -0800
Subject: [IronPython] Re: IronPython 0.7.1 released
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7CA2@df-chewy-msg.exchange.corp.microsoft.com>

Thanks for all the bug reports, Michael.

As for the compatibility, when in doubt on specific issues, I consult
Python 2.4 myself so that is what I personally compare our
implementation against at the moment.

Test suite ... we do already have a test suite to test basic
functionality and regressions from all fixed bugs. I am in the process
of making it more independent on other pieces of our infrastructure at
which point I assume we will include it with the release.

Ideally, I want to see (hopefully soon) IronPython pass the whole set of
tests that come with standard Python and we are working on it along with
trying to respond quickly to external bug reports.

Martin

> -----Original Message-----
> From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-
> ironpython.com-bounces at lists.ironpython.com] On Behalf Of Michael
Spencer
> Sent: Saturday, April 02, 2005 1:31 PM
> To: users-ironpython.com at lists.ironpython.com
> Subject: [IronPython] Re: IronPython 0.7.1 released
> 
> Martin Maly wrote:
> > We are excited to announce the release of IronPython 0.7.1.  The
> > improvements over the recent 0.7 release are mostly bug fixes for
bugs
> > reported by the community and suggestions from the mailing lists and
> > message boards:
> >
> Thanks for the new release (on schedule!).  I have submitted a number
of
> bugs in
> this version.  (It appears there is nowhere on the bug-form to note
which
> version they apply to.)
> 
> I also can't find a statement of which Python version fepy 0.7 is
intended
> to
> match - I have assumed 2.3.3.  What is your goal?  Do you want
> discrepancies
> with 2.4/2.5 behavior reported?
> 
> You don't include a test suite with the source.  Do you have a plan
for
> one?
> ISTM it would be a good idea to share tests with pypy.
> 
> Michael
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From randall_burns at yahoo.com  Sun Apr  3 02:25:58 2005
From: randall_burns at yahoo.com (Randall Burns)
Date: Sat, 2 Apr 2005 16:25:58 -0800 (PST)
Subject: [IronPython] Re: users-ironpython.com Digest, Vol 9, Issue 2
In-Reply-To: <20050402200743.AF6C884D49@che.dreamhost.com>
Message-ID: <20050403002558.37752.qmail@web14323.mail.yahoo.com>

My related question:
what would it take to make Python full featured enough
that it really could be used for a compiler project
like this?

--- Timothy Fitz <firemoth at gmail.com>wrote:
> 
> As a sidenote, I believe the compiler was originally
> prototyped in python, why was C# chosen as a 
> language? System.Reflection.Emit argues
> for itself, however it is easily accessed from
> CPython with Python for .NET, and that code would 
> be a simply bootstrapping stage that could be moved
> into IronPython code.



		
__________________________________ 
Yahoo! Messenger 
Show us what our next emoticon should look like. Join the fun. 
http://www.advision.webevents.yahoo.com/emoticontest


From jvm_cop at spamcop.net  Sun Apr  3 03:47:21 2005
From: jvm_cop at spamcop.net (J. Merrill)
Date: Sat, 02 Apr 2005 20:47:21 -0500
Subject: [IronPython] Renaming IronPythonConsole
Message-ID: <4.3.2.7.2.20050402204713.06196f10@mail.comcast.net>

I don't know why you're whining about it anyway.  2.0 is faster and better, and (unlike previous technologies inflicted upon us by MS) it won't cause any trouble to have both 2.0 and earlier versions on the same machine at the same time.

At 05:04 PM 4/1/2005, R.R. Sprinkhuizen wrote

>> If you liked it better with the old license and old requirements, fork the old one.
>
>If I had that kind of programming capabilities, I wouldn't be here whining about 2.0, now would I?
>
>Cheers!
>Reginald


J. Merrill / Analytical Software Corp



From reginald at rare-it.com  Sun Apr  3 10:26:44 2005
From: reginald at rare-it.com (R.R. Sprinkhuizen)
Date: Sun, 3 Apr 2005 10:26:44 +0200
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <4.3.2.7.2.20050402204713.06196f10@mail.comcast.net>
Message-ID: <20050403082649.0E67284D39@che.dreamhost.com>

For the record, I changed my "whining" strategy just yesterday by getting
and installing 2.0-beta. I guess if I like IronPython (which is beta), than
why not the software/framework it depends on?!

Thanks for listening, though.

Reginald 

-----Original Message-----
From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of J.
Merrill
Sent: zondag 3 april 2005 3:47
To: Discussion of IronPython
Subject: RE: [IronPython] Renaming IronPythonConsole

I don't know why you're whining about it anyway.  2.0 is faster and better,
and (unlike previous technologies inflicted upon us by MS) it won't cause
any trouble to have both 2.0 and earlier versions on the same machine at the
same time.

At 05:04 PM 4/1/2005, R.R. Sprinkhuizen wrote

>> If you liked it better with the old license and old requirements, fork
the old one.
>
>If I had that kind of programming capabilities, I wouldn't be here whining
about 2.0, now would I?
>
>Cheers!
>Reginald


J. Merrill / Analytical Software Corp

_______________________________________________
users-ironpython.com mailing list
users-ironpython.com at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com







From mahs at telcopartners.com  Sun Apr  3 22:39:14 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Sun, 03 Apr 2005 13:39:14 -0700
Subject: [IronPython] NotGotDotNet
Message-ID: <42505472.1080803@telcopartners.com>

1330 PST

IronPython Workspace Home
http://workspaces.gotdotnet.com/ironpython is down*:

although, IronPython bugtracker at:
http://www.gotdotnet.com/workspaces/bugtracker/home.aspx?id=ad7acff7-ab1e-4bcb-99c0-57ac5a3a9742
and messages at:
http://www.gotdotnet.com/workspaces/messageboard/home.aspx?id=ad7acff7-ab1e-4bcb-99c0-57ac5a3a9742

are available



*error msg:


GotDotNet

If you see this page, it is because you have completed an action that threw an 
  error in the GotDotNet system. We apologize for the inconvenience, and ask you 
  to help our team understand why the system threw the error.

Additional details:

Passport logged in user
UA: Firefox1.0 (also same result with IE6.0)





From martmaly at exchange.microsoft.com  Mon Apr  4 00:44:55 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Sun, 3 Apr 2005 15:44:55 -0700
Subject: [IronPython] NotGotDotNet
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7CD8@df-chewy-msg.exchange.corp.microsoft.com>

Yep, I am seeing that too. I'll talk to GotDotNet admins to try to find
out what went wrong.

Martin

> On Sunday, April 03, 2005 1:39 PM Michael Spencer wrote:
> 
> 1330 PST
> 
> IronPython Workspace Home
> http://workspaces.gotdotnet.com/ironpython is down*:
> 
> although, IronPython bugtracker at:
>
http://www.gotdotnet.com/workspaces/bugtracker/home.aspx?id=ad7acff7-ab1
e-
> 4bcb-99c0-57ac5a3a9742
> and messages at:
>
http://www.gotdotnet.com/workspaces/messageboard/home.aspx?id=ad7acff7-
> ab1e-4bcb-99c0-57ac5a3a9742
> 
> are available
> 
> 
> 
> *error msg:
> 
> 
> GotDotNet
> 
> If you see this page, it is because you have completed an action that
> threw an
>   error in the GotDotNet system. We apologize for the inconvenience,
and
> ask you
>   to help our team understand why the system threw the error.
> 
> Additional details:
> 
> Passport logged in user
> UA: Firefox1.0 (also same result with IE6.0)
> 
> 
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From mahs at telcopartners.com  Mon Apr  4 08:42:03 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Sun, 03 Apr 2005 23:42:03 -0700
Subject: [IronPython] CPython's test_builtin results summary
Message-ID: <d2qnii$h90$2@sea.gmane.org>

First cut result at a hacked version of cpython's test_builtin.  Some changes 
required to this and unittest to import successfully.
Below you will find results summary.  Results detail, then the test module 
itself will follow in subsequent posts


G:\CABS\Python\FePy\IronPython-0.7.1\bin>IronPythonConsole
IronPython 0.7.1 on .NET 2.0.40607.42
Copyright (c) Microsoft Corporation. All rights reserved.
 >>> import test_builtincpython1 as T
 >>> res = T.fepytest()
test_abs Failed
test_apply Failed
test_callable Failed
test_chr Failed
test_cmp Failed
test_coerce Failed
test_compile Failed
test_delattr Failed
test_dir Failed
test_divmod Failed
test_eval Failed
test_execfile Failed
test_filter Failed
test_filter_subclasses Failed
test_float Succeeded
test_general_eval Failed
test_getattr Failed
test_hasattr Failed
test_hash Failed
test_hex Failed
test_id Succeeded
test_import Failed
test_input_and_raw_input Failed
test_int Failed
test_intern Failed
test_isinstance Failed
test_issubclass Failed
test_iter Failed
test_len Succeeded
test_list Failed
test_long Failed
test_map Failed
test_max Failed
test_min Failed
test_oct Failed
test_open Failed
test_ord Failed
test_pow Failed
test_range Failed
test_reduce Failed
test_reload Failed
test_repr Failed
test_round Succeeded
test_setattr Failed
test_str Failed
test_sum Failed
test_tuple Succeeded
test_type Succeeded
test_unichr Succeeded
test_vars Failed



From kfarmer at thuban.org  Mon Apr  4 11:16:28 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Mon, 4 Apr 2005 02:16:28 -0700
Subject: [IronPython] (no subject)
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C13697A@nostromo.circle-cross.home>

Has someone made binaries of the lastest mono for win32, with 2.0
preview on, to run IronPython with?

----------
Keith J. Farmer
kfarmer at thuban.org
http://www.thuban.org


From mailinglist.account at gmail.com  Mon Apr  4 12:12:05 2005
From: mailinglist.account at gmail.com (Anthony Tarlano)
Date: Mon, 4 Apr 2005 12:12:05 +0200
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <20050403082649.0E67284D39@che.dreamhost.com>
References: <4.3.2.7.2.20050402204713.06196f10@mail.comcast.net>
	<20050403082649.0E67284D39@che.dreamhost.com>
Message-ID: <f2b57319050404031265f8472@mail.gmail.com>

Another thought is just name it python.net and be done with this iron stuff..

Anthony

On Apr 3, 2005 10:26 AM, R.R. Sprinkhuizen <reginald at rare-it.com> wrote:
> For the record, I changed my "whining" strategy just yesterday by getting
> and installing 2.0-beta. I guess if I like IronPython (which is beta), than
> why not the software/framework it depends on?!
> 
> Thanks for listening, though.
> 
> Reginald
> 
> -----Original Message-----
> From: users-ironpython.com-bounces at lists.ironpython.com
> [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of J.
> Merrill
> Sent: zondag 3 april 2005 3:47
> To: Discussion of IronPython
> Subject: RE: [IronPython] Renaming IronPythonConsole
> 
> I don't know why you're whining about it anyway.  2.0 is faster and better,
> and (unlike previous technologies inflicted upon us by MS) it won't cause
> any trouble to have both 2.0 and earlier versions on the same machine at the
> same time.
> 
> At 05:04 PM 4/1/2005, R.R. Sprinkhuizen wrote
> 
> >> If you liked it better with the old license and old requirements, fork
> the old one.
> >
> >If I had that kind of programming capabilities, I wouldn't be here whining
> about 2.0, now would I?
> >
> >Cheers!
> >Reginald
> 
> J. Merrill / Analytical Software Corp
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From kfarmer at thuban.org  Mon Apr  4 12:22:45 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Mon, 4 Apr 2005 03:22:45 -0700
Subject: [IronPython] Renaming IronPythonConsole
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C13697B@nostromo.circle-cross.home>

Already taken 


----------
Keith J. Farmer
kfarmer at thuban.org
http://www.thuban.org

-----Original Message-----
From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Anthony Tarlano
Sent: Monday, April 04, 2005 3:12 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Renaming IronPythonConsole

Another thought is just name it python.net and be done with this iron
stuff..


From hchrholm at online.no  Mon Apr  4 12:36:34 2005
From: hchrholm at online.no (Hans-Christian Holm)
Date: Mon, 4 Apr 2005 12:36:34 +0200
Subject: [IronPython] Zope/Plone on IronPython?
Message-ID: <006f01c53902$2d16bd70$0b00a8c0@HC6>

What are the prospects for running Zope on IronPython?

Having Zope run on .NET could open up some quite interesting possibilities, esp. for Plone, the popular content management system (CMS) for Zope. I usually work with .NET, but for some CMS stuff I did I chose Plone. I liked that a lot better than the current most popular open source .NET CMS, DotNetNuke, which didn't give me that pleasant open source feeling that Plone gives and seemed a lot more clumsy in many respects.

Zope.NET could be a killer app if it could be tightly integrated with ASP.NET and the rest of the .NET infrastructure. Right now I can't really imagine all the possibilities you would get, but just to have a nice object database and a good CMS on top of that would make .NET a much more interesting choice than all those PHP and Java alternatives for web publishing. Can it be done?!

Hans-Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050404/f7570ab4/attachment.html>

From nicolas.lehuen at gmail.com  Mon Apr  4 12:46:29 2005
From: nicolas.lehuen at gmail.com (Nicolas Lehuen)
Date: Mon, 4 Apr 2005 12:46:29 +0200
Subject: [IronPython] Zope/Plone on IronPython?
In-Reply-To: <006f01c53902$2d16bd70$0b00a8c0@HC6>
References: <006f01c53902$2d16bd70$0b00a8c0@HC6>
Message-ID: <c298f2d70504040346278af0fe@mail.gmail.com>

Hi,

As far as I know, there is a bunch of Python module written in C at
the core of Zope. They implement the core capacities of the object
broker and the object database engine :

Acquisition.pyd
Btree.pyd
ComputedAttribute.pyd
ExtensionClass.pyd
IIBtree.pyd
initgroup.pyd
intSet.pyd
IOBTree.pyd
MethodObject.pyd
Missing.pyd
MultiMapping.pyd
OIBtree.pyd
Record.pyd
ThreadLock.pyd

Judging from this list, a port to IronPython seems highly doubtful.
Everything would have to be reimplemented, which looks like a titan's
work.

Regards,
Nicolas


On Apr 4, 2005 12:36 PM, Hans-Christian Holm <hchrholm at online.no> wrote:
>  
> What are the prospects for running Zope on IronPython? 
>   
> Having Zope run on .NET could open up some quite interesting possibilities,
> esp. for Plone, the popular content management system (CMS) for Zope. I
> usually work with .NET, but for some CMS stuff I did I chose Plone. I liked
> that a lot better than the current most popular open source .NET CMS,
> DotNetNuke, which didn't give me that pleasant open source feeling that
> Plone gives and seemed a lot more clumsy in many respects. 
>   
> Zope.NET could be a killer app if it could be tightly integrated with
> ASP.NET and the rest of the .NET infrastructure. Right now I can't really
> imagine all the possibilities you would get, but just to have a nice object
> database and a good CMS on top of that would make .NET a much more
> interesting choice than all those PHP and Java alternatives for web
> publishing. Can it be done?! 
>   
> Hans-Christian 
>   
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> 
>


From nicolas.lehuen at gmail.com  Mon Apr  4 12:50:12 2005
From: nicolas.lehuen at gmail.com (Nicolas Lehuen)
Date: Mon, 4 Apr 2005 12:50:12 +0200
Subject: [IronPython] Zope/Plone on IronPython?
In-Reply-To: <c298f2d70504040346278af0fe@mail.gmail.com>
References: <006f01c53902$2d16bd70$0b00a8c0@HC6>
	<c298f2d70504040346278af0fe@mail.gmail.com>
Message-ID: <c298f2d70504040350352582c4@mail.gmail.com>

BTW, this module list is far from exhaustive... There are many others,
not speaking about the dependencies on core python modules (for
example, the medusa async I/O HTTP Server)  which are not implemented
yet. And Plone adds another layer of dependencies on native code and
Python modules.

I guess I'd be faster are more beneficial to build a new CMS from
scratch rather than port Zope / Plone.

Regards,
Nicolas

On Apr 4, 2005 12:46 PM, Nicolas Lehuen <nicolas.lehuen at gmail.com> wrote:
> Hi,
> 
> As far as I know, there is a bunch of Python module written in C at
> the core of Zope. They implement the core capacities of the object
> broker and the object database engine :
> 
> Acquisition.pyd
> Btree.pyd
> ComputedAttribute.pyd
> ExtensionClass.pyd
> IIBtree.pyd
> initgroup.pyd
> intSet.pyd
> IOBTree.pyd
> MethodObject.pyd
> Missing.pyd
> MultiMapping.pyd
> OIBtree.pyd
> Record.pyd
> ThreadLock.pyd
> 
> Judging from this list, a port to IronPython seems highly doubtful.
> Everything would have to be reimplemented, which looks like a titan's
> work.
> 
> Regards,
> Nicolas
> 
> 
> On Apr 4, 2005 12:36 PM, Hans-Christian Holm <hchrholm at online.no> wrote:
> >
> > What are the prospects for running Zope on IronPython?
> >
> > Having Zope run on .NET could open up some quite interesting possibilities,
> > esp. for Plone, the popular content management system (CMS) for Zope. I
> > usually work with .NET, but for some CMS stuff I did I chose Plone. I liked
> > that a lot better than the current most popular open source .NET CMS,
> > DotNetNuke, which didn't give me that pleasant open source feeling that
> > Plone gives and seemed a lot more clumsy in many respects.
> >
> > Zope.NET could be a killer app if it could be tightly integrated with
> > ASP.NET and the rest of the .NET infrastructure. Right now I can't really
> > imagine all the possibilities you would get, but just to have a nice object
> > database and a good CMS on top of that would make .NET a much more
> > interesting choice than all those PHP and Java alternatives for web
> > publishing. Can it be done?!
> >
> > Hans-Christian
> >
> > _______________________________________________
> > users-ironpython.com mailing list
> > users-ironpython.com at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> >
> >
>


From firemoth at gmail.com  Mon Apr  4 17:33:37 2005
From: firemoth at gmail.com (Timothy Fitz)
Date: Mon, 4 Apr 2005 08:33:37 -0700
Subject: [IronPython] Zope/Plone on IronPython?
In-Reply-To: <c298f2d70504040350352582c4@mail.gmail.com>
References: <006f01c53902$2d16bd70$0b00a8c0@HC6>
	<c298f2d70504040346278af0fe@mail.gmail.com>
	<c298f2d70504040350352582c4@mail.gmail.com>
Message-ID: <972ec5bd05040408331c7521c6@mail.gmail.com>

On Apr 4, 2005 3:50 AM, Nicolas Lehuen <nicolas.lehuen at gmail.com> wrote:
> BTW, this module list is far from exhaustive... There are many others,
> not speaking about the dependencies on core python modules (for
> example, the medusa async I/O HTTP Server)  which are not implemented
> yet. And Plone adds another layer of dependencies on native code and
> Python modules.

It would not be much work to get WSGI working ontop of IronPython
(Ontop of whatever, in this instance ASP.NET) which would handle most
of the request hassles, and probably cut out a large portion of C
code.

However, that still won't bring us anywhere near running Zope on
IronPython. A better route might be to take these C modules and write
thin managed C++ wrappers around them.

And while we're talking about improbabilities, pyds are just dlls on
windows, and the DllImport attribute (horribly named for fonts like
mine where l and I are the same) allows easy C calls from .NET.
Unfortunately the C code will depend on CPython internals and
structure, making it a beast to call from managed code, it's still
theoretically possible to write python wrappers that could make it all
work.

> I guess I'd be faster are more beneficial to build a new CMS from
> scratch rather than port Zope / Plone.

You're probably right; however, there is no need to start from
scratch. Zope has many many components, such as the templating systems
(pick any two) that could be useful.


From miuler at gmail.com  Mon Apr  4 21:32:08 2005
From: miuler at gmail.com (Hector Miuler Malpica Gallegos)
Date: Mon, 04 Apr 2005 14:32:08 -0500
Subject: [IronPython] IronPython + Npgsql
Message-ID: <1112643128.21083.5.camel@localhost>

Hello friends, I am using Npgsql, from IronPython functions, but I do
not be able optener data of the results, some idea of as I can do it?  


Conn = Npgsql.NpgsqlConnection("Server=127.0.0.1;Port=5432;User
Id=miuler;Password=miuler;Database=basecsd;")
Conn.Open()
		
Cmd = Npgsql.NpgsqlCommand("select version()", Conn)
Resultado = Cmd.ExecuteScalar()
print Resultado	
Cmd = Npgsql.NpgsqlCommand("select * from clientes;", Conn)
Resultado = Cmd.ExecuteReader()
while (Resultado.Read()):
	print Resultado
	#~ print Resultado[1] # <-- error
Conn.Close()

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050404/05452ddc/attachment.html>

From miuler at gmail.com  Tue Apr  5 00:06:42 2005
From: miuler at gmail.com (Hector Miuler Malpica Gallegos)
Date: Mon, 04 Apr 2005 17:06:42 -0500
Subject: [IronPython] Error in float
Message-ID: <1112652402.21083.7.camel@localhost>

IronPython 0.6

>>> type (1e-1)
<type 'float'>
>>> type (0.1)
<type 'float'>
>>> 1e-1
0,1
>>> 0.1
1
>>> 1e-1*2
0,2
>>> 0.1*2
2
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050404/6779894c/attachment.html>

From martmaly at exchange.microsoft.com  Tue Apr  5 00:19:41 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Mon, 4 Apr 2005 15:19:41 -0700
Subject: [IronPython] Error in float
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7F36@df-chewy-msg.exchange.corp.microsoft.com>

There were issues with float point parsing in IronPython 0.6. You can
use the newest available release 0.7.1 which has these issues fixed (I
just ran your commands on the newest release)

 

The newest IronPython 0.7.1 can be downloaded from:

 

http://workspaces.gotdotnet.com/ironpython

 

Martin

 

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Hector Miuler Malpica Gallegos
Sent: Monday, April 04, 2005 3:07 PM
To: users-ironpython.com at lists.ironpython.com
Subject: [IronPython] Error in float

 

IronPython 0.6

>>> type (1e-1)
<type 'float'>
>>> type (0.1)
<type 'float'>
>>> 1e-1
0,1
>>> 0.1
1
>>> 1e-1*2
0,2
>>> 0.1*2
2
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050404/4f6e47d0/attachment.html>

From martmaly at exchange.microsoft.com  Tue Apr  5 00:28:59 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Mon, 4 Apr 2005 15:28:59 -0700
Subject: [IronPython] CPython's test_builtin results summary
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7F43@df-chewy-msg.exchange.corp.microsoft.com>

Hi Michael,

Thank you for taking the time and running the test suite. It is not
surprising that there are so many failures since much of the development
effort went into getting basic functionality and interoperability with
.Net framework and there are many cases (some are common, some less)
that IronPython does not handle well as of now.

Before we release IronPython 1.0 we need to be running the Python
regression tests with very good success rates. As I said in the earlier
email, we are working on getting broad-scale regression tests to pass
and each new release will get us much closer to that goal. There is
undisputable value in getting the entire test suite to pass, however we
do not require the community to duplicate the efforts that we have
already under way.

At this early stage there are still many useful programs that people can
build with IronPython 0.7. These are newly written programs using .NET
libraries rather than existing Python programs. Right now we're most
interested in capturing the problems from these early users both to
understand issues with .NET integration and to fix blocking issues as
quickly as possible so they can get on with writing code. This is a new
set of issues where we need to build experience and can't rely on the
existing test suites to cover us as we push towards 1.0.

Thanks and keep in touch,
The IronPython Team

> -----Original Message-----
> From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-
> ironpython.com-bounces at lists.ironpython.com] On Behalf Of Michael
Spencer
> Sent: Sunday, April 03, 2005 11:42 PM
> To: users-ironpython.com at lists.ironpython.com
> Subject: [IronPython] CPython's test_builtin results summary
> 
> First cut result at a hacked version of cpython's test_builtin.  Some
> changes
> required to this and unittest to import successfully.
> Below you will find results summary.  Results detail, then the test
module
> itself will follow in subsequent posts
> 
> 
> G:\CABS\Python\FePy\IronPython-0.7.1\bin>IronPythonConsole
> IronPython 0.7.1 on .NET 2.0.40607.42
> Copyright (c) Microsoft Corporation. All rights reserved.
>  >>> import test_builtincpython1 as T
>  >>> res = T.fepytest()
> test_abs Failed
> test_apply Failed
> test_callable Failed
> test_chr Failed
> test_cmp Failed
> test_coerce Failed
> test_compile Failed
> test_delattr Failed
> test_dir Failed
> test_divmod Failed
> test_eval Failed
> test_execfile Failed
> test_filter Failed
> test_filter_subclasses Failed
> test_float Succeeded
> test_general_eval Failed
> test_getattr Failed
> test_hasattr Failed
> test_hash Failed
> test_hex Failed
> test_id Succeeded
> test_import Failed
> test_input_and_raw_input Failed
> test_int Failed
> test_intern Failed
> test_isinstance Failed
> test_issubclass Failed
> test_iter Failed
> test_len Succeeded
> test_list Failed
> test_long Failed
> test_map Failed
> test_max Failed
> test_min Failed
> test_oct Failed
> test_open Failed
> test_ord Failed
> test_pow Failed
> test_range Failed
> test_reduce Failed
> test_reload Failed
> test_repr Failed
> test_round Succeeded
> test_setattr Failed
> test_str Failed
> test_sum Failed
> test_tuple Succeeded
> test_type Succeeded
> test_unichr Succeeded
> test_vars Failed
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From kfarmer at thuban.org  Tue Apr  5 00:39:10 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Mon, 4 Apr 2005 15:39:10 -0700
Subject: [IronPython] Tests, and plans
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C13697F@nostromo.circle-cross.home>

Well, since these tests will be viewed by many to be the standard, do
the tests planned include a superset of these, at least?

I was making a haphazard estimate of the timing for 1.0, figuring a
two-week cycle, going no further than 0.0.x, would give up to 60 weeks
for 1.0 release.  I'm guessing y'all are planning for much sooner than
that?

Are plans for IDE integration on the list somewhere?

----------
Keith J. Farmer
kfarmer at thuban.org
http://www.thuban.org

-----Original Message-----
From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Martin Maly
Sent: Monday, April 04, 2005 3:29 PM
To: Discussion of IronPython
Subject: RE: [IronPython] CPython's test_builtin results summary

that goal. There is undisputable value in getting the entire test suite
to pass, however we do not require the community to duplicate the
efforts that we have already under way.


From martmaly at exchange.microsoft.com  Tue Apr  5 00:44:08 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Mon, 4 Apr 2005 15:44:08 -0700
Subject: [IronPython] IronPython + Npgsql
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7F58@df-chewy-msg.exchange.corp.microsoft.com>

There is known issue with indexing where IronPython may have trouble finding the right indexer.
This may be what you are hitting. I am not familiar with Npgsql, but on .Net classes there is
often property that you can access directly and bypass the access by index.

Martin

> On Monday, April 04, 2005 12:32 PM Hector Miuler Malpica Gallegos Wrote:
> Sent: Monday, April 04, 2005 12:32 PM
> To: users-ironpython.com at lists.ironpython.com
> Subject: [IronPython] IronPython + Npgsql

> Hello friends, I am using Npgsql, from IronPython functions, but I do not be able
> optener data of the results, some idea of as I can do it?? 


> Conn = Npgsql.NpgsqlConnection("Server=127.0.0.1;Port=5432;User Id=miuler;Password=miuler;Database=basecsd;")
> Conn.Open()

> Cmd = Npgsql.NpgsqlCommand("select version()", Conn)
> Resultado = Cmd.ExecuteScalar()
> print Resultado 
> Cmd = Npgsql.NpgsqlCommand("select * from clientes;", Conn)
> Resultado = Cmd.ExecuteReader()
> while (Resultado.Read()):
> print Resultado
> #~ print Resultado[1] # <-- error
> Conn.Close()



From mahs at telcopartners.com  Tue Apr  5 00:55:10 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Mon, 04 Apr 2005 15:55:10 -0700
Subject: [IronPython] Re: CPython's test_builtin results summary
In-Reply-To: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7F43@df-chewy-msg.exchange.corp.microsoft.com>
References: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7F43@df-chewy-msg.exchange.corp.microsoft.com>
Message-ID: <d2sgip$p1q$1@sea.gmane.org>

Martin Maly wrote:
> Hi Michael,
> 
> Thank you for taking the time and running the test suite. It is not
> surprising that there are so many failures since much of the development
> effort went into getting basic functionality and interoperability with
> .Net framework and there are many cases (some are common, some less)
> that IronPython does not handle well as of now.
> 
...

Hi Martin

My point was not to emphasize the test failures but rather to share the 
techniques required to get the tests to run, which I thought might be of 
interest to other users.  Unfortunately, my two additional posts which contain 
the detail results and the code are being held by the mailserver pending 
moderator approval to exceed 40K.  Especially in the absence of these posts, it 
may appear that I am being critical, which is not the case at all.

You have requested bug reports from the community, without spcifying what sort 
of bugs you want to focus on.  For reasons of my own, I have chosen to focus 
systematically on built-ins, and have shared my approach and findings, in case 
they are of any use/interest to others.  In particular, there are probably 30-50 
specific bug reports that can be extracted from these tests.  Do you want me to 
file them?

Cheers
Michael





From caetano at gmail.com  Fri Apr  1 01:15:09 2005
From: caetano at gmail.com (Richard Caetano)
Date: Thu, 31 Mar 2005 15:15:09 -0800
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <20050331224632.E32E284D49@che.dreamhost.com>
References: <21f1e270050331143932137355@mail.gmail.com>
	<20050331224632.E32E284D49@che.dreamhost.com>
Message-ID: <6c60e8e6050331151520e00aec@mail.gmail.com>

+1 for ironpy


On Fri, 1 Apr 2005 00:46:35 +0200, R.R. Sprinkhuizen
<reginald at rare-it.com> wrote:
>  
> 
> > Personally, I like ironpy.  I too was a little late in voting ;-)
> 
> Count me in. I don't like fepy.
> 
> > I'm happy we're getting new releases at all, frankly.
> 
> Me too, but very unhappy that it needs 2.0. Can't there be a 1.1 and a 2.0
> version?
> 
> Cheers!
> Reginald
> 
>  
>  ________________________________
>  
> SwitchBL8's gebazel 
> 
> 
> 
>  
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> 
>


From mahs at telcopartners.com  Mon Apr  4 08:43:50 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Sun, 03 Apr 2005 23:43:50 -0700
Subject: [IronPython] CPython's test_builtin Failure details
Message-ID: <d2qnlu$h90$3@sea.gmane.org>

Results Detail

 >>> T.formatfepyfailures(res)
14 Tests failed:

<test_builtincpython1.BuiltinTest testMethod=test_chr>
IronPython.Objects.PythonAssertionError: ValueError
    at IronPython.Objects.Ops.Raise(Object type, Object value, Object traceback)
    at unittest.failUnlessRaises$f172(Object self, Object excClass, Object callab
leObj, Object args, Object kwargs) in G:\CABS\Python\FePy\IronPython-0.7.1\bin\u
nittest.py:line 231
    at unittest.failUnlessRaises$f172(Object[] args)
    at IronPython.Objects.FunctionX.Call(Object[] args)
    at IronPython.Objects.FunctionN.Call(Object arg0, Object arg1, Object arg2, O
bject arg3)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2, Object arg3)
    at IronPython.Objects.Method.Call(Object arg0, Object arg1, Object arg2)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2)
    at test_builtincpython1.test_chr$f20(Object self) in G:\CABS\Python\FePy\Iron
Python-0.7.1\bin\test_builtincpython1.py:line 192
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_dir>
IronPython.Objects.PythonAssertionError
    at IronPython.Objects.Ops.Raise(Object type, Object value, Object traceback)
    at unittest.failUnless$f171(Object self, Object expr, Object msg) in G:\CABS\
Python\FePy\IronPython-0.7.1\bin\unittest.py:line 212
    at IronPython.Objects.Function3.Call(Object arg0, Object arg1)
    at IronPython.Objects.Method.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at test_builtincpython1.test_dir$f26(Object self) in G:\CABS\Python\FePy\Iron
Python-0.7.1\bin\test_builtincpython1.py:line 241
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_divmod>
IronPython.Objects.PythonAssertionError: (-1, -5) != (-2, 2)
    at IronPython.Objects.Ops.Raise(Object type, Object value, Object traceback)
    at unittest.failUnlessEqual$f173(Object self, Object first, Object second, Ob
ject msg) in G:\CABS\Python\FePy\IronPython-0.7.1\bin\unittest.py:line 240
    at IronPython.Objects.Function4.Call(Object arg0, Object arg1, Object arg2)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2)
    at IronPython.Objects.Method.Call(Object arg0, Object arg1)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1)
    at test_builtincpython1.test_divmod$f27(Object self) in G:\CABS\Python\FePy\I
ronPython-0.7.1\bin\test_builtincpython1.py:line 248
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_eval>
IronPython.Objects.PythonAssertionError: 2 != 200
    at IronPython.Objects.Ops.Raise(Object type, Object value, Object traceback)
    at unittest.failUnlessEqual$f173(Object self, Object first, Object second, Ob
ject msg) in G:\CABS\Python\FePy\IronPython-0.7.1\bin\unittest.py:line 240
    at IronPython.Objects.Function4.Call(Object arg0, Object arg1, Object arg2)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2)
    at IronPython.Objects.Method.Call(Object arg0, Object arg1)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1)
    at test_builtincpython1.test_eval$f28(Object self) in G:\CABS\Python\FePy\Iro
nPython-0.7.1\bin\test_builtincpython1.py:line 279
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_filter>
IronPython.Objects.PythonAssertionError: ['e', 'l', 'l', 'o', 'o', 'r', 'l', 'd'
] != 'elloorld'
    at IronPython.Objects.Ops.Raise(Object type, Object value, Object traceback)
    at unittest.failUnlessEqual$f173(Object self, Object first, Object second, Ob
ject msg) in G:\CABS\Python\FePy\IronPython-0.7.1\bin\unittest.py:line 240
    at IronPython.Objects.Function4.Call(Object arg0, Object arg1, Object arg2)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2)
    at IronPython.Objects.Method.Call(Object arg0, Object arg1)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1)
    at test_builtincpython1.test_filter$f42(Object self) in G:\CABS\Python\FePy\I
ronPython-0.7.1\bin\test_builtincpython1.py:line 414
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_filter_subclasses>
IronPython.Objects.PythonAssertionError: [] != ()
    at IronPython.Objects.Ops.Raise(Object type, Object value, Object traceback)
    at unittest.failUnlessEqual$f173(Object self, Object first, Object second, Ob
ject msg) in G:\CABS\Python\FePy\IronPython-0.7.1\bin\unittest.py:line 240
    at IronPython.Objects.Function4.Call(Object arg0, Object arg1, Object arg2)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2)
    at IronPython.Objects.Method.Call(Object arg0, Object arg1)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1)
    at test_builtincpython1.test_filter_subclasses$f68(Object self) in G:\CABS\Py
thon\FePy\IronPython-0.7.1\bin\test_builtincpython1.py:line 521
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_hex>
IronPython.Objects.PythonAssertionError: '0xfffffff0' != '-0x10'
    at IronPython.Objects.Ops.Raise(Object type, Object value, Object traceback)
    at unittest.failUnlessEqual$f173(Object self, Object first, Object second, Ob
ject msg) in G:\CABS\Python\FePy\IronPython-0.7.1\bin\unittest.py:line 240
    at IronPython.Objects.Function4.Call(Object arg0, Object arg1, Object arg2)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2)
    at IronPython.Objects.Method.Call(Object arg0, Object arg1)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1)
    at test_builtincpython1.test_hex$f78(Object self) in G:\CABS\Python\FePy\Iron
Python-0.7.1\bin\test_builtincpython1.py:line 563
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_iter>
IronPython.Objects.PythonAssertionError: TypeError
    at IronPython.Objects.Ops.Raise(Object type, Object value, Object traceback)
    at unittest.failUnlessRaises$f172(Object self, Object excClass, Object callab
leObj, Object args, Object kwargs) in G:\CABS\Python\FePy\IronPython-0.7.1\bin\u
nittest.py:line 231
    at unittest.failUnlessRaises$f172(Object[] args)
    at IronPython.Objects.FunctionX.Call(Object[] args)
    at IronPython.Objects.Ops.Call(Object func, Object[] args)
    at IronPython.Objects.Method.Call(Object arg0, Object arg1, Object arg2, Obje
ct arg3)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2, Object arg3)
    at test_builtincpython1.test_iter$f83(Object self) in G:\CABS\Python\FePy\Iro
nPython-0.7.1\bin\test_builtincpython1.py:line 664
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_list>
IronPython.Objects.PythonAssertionError
    at IronPython.Objects.Ops.Raise(Object type, Object value, Object traceback)
    at unittest.failUnless$f171(Object self, Object expr, Object msg) in G:\CABS\
Python\FePy\IronPython-0.7.1\bin\unittest.py:line 212
    at IronPython.Objects.Function3.Call(Object arg0, Object arg1)
    at IronPython.Objects.Method.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at test_builtincpython1.test_list$f88(Object self) in G:\CABS\Python\FePy\Iro
nPython-0.7.1\bin\test_builtincpython1.py:line 726
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_map>
IronPython.Objects.PythonAssertionError: [('a', 'e'), ('b', 'f'), ('c', 'g')] !=
  [('a', 'e'), ('b', 'f'), ('c', 'g'), ('d', None)]
    at IronPython.Objects.Ops.Raise(Object type, Object value, Object traceback)
    at unittest.failUnlessEqual$f173(Object self, Object first, Object second, Ob
ject msg) in G:\CABS\Python\FePy\IronPython-0.7.1\bin\unittest.py:line 240
    at IronPython.Objects.Function4.Call(Object arg0, Object arg1, Object arg2)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2)
    at IronPython.Objects.Method.Call(Object arg0, Object arg1)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1)
    at test_builtincpython1.test_map$f90(Object self) in G:\CABS\Python\FePy\Iron
Python-0.7.1\bin\test_builtincpython1.py:line 803
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_max>
IronPython.Objects.PythonAssertionError: '123123' != '3'
    at IronPython.Objects.Ops.Raise(Object type, Object value, Object traceback)
    at unittest.failUnlessEqual$f173(Object self, Object first, Object second, Ob
ject msg) in G:\CABS\Python\FePy\IronPython-0.7.1\bin\unittest.py:line 240
    at IronPython.Objects.Function4.Call(Object arg0, Object arg1, Object arg2)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2)
    at IronPython.Objects.Method.Call(Object arg0, Object arg1)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1)
    at test_builtincpython1.test_max$f99(Object self) in G:\CABS\Python\FePy\Iron
Python-0.7.1\bin\test_builtincpython1.py:line 870
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_oct>
IronPython.Objects.PythonAssertionError: '0-144' != '-0144'
    at IronPython.Objects.Ops.Raise(Object type, Object value, Object traceback)
    at unittest.failUnlessEqual$f173(Object self, Object first, Object second, Ob
ject msg) in G:\CABS\Python\FePy\IronPython-0.7.1\bin\unittest.py:line 240
    at IronPython.Objects.Function4.Call(Object arg0, Object arg1, Object arg2)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2)
    at IronPython.Objects.Method.Call(Object arg0, Object arg1)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1)
    at test_builtincpython1.test_oct$f103(Object self) in G:\CABS\Python\FePy\Iro
nPython-0.7.1\bin\test_builtincpython1.py:line 904
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_ord>
IronPython.Objects.PythonAssertionError: TypeError
    at IronPython.Objects.Ops.Raise(Object type, Object value, Object traceback)
    at unittest.failUnlessRaises$f172(Object self, Object excClass, Object callab
leObj, Object args, Object kwargs) in G:\CABS\Python\FePy\IronPython-0.7.1\bin\u
nittest.py:line 231
    at unittest.failUnlessRaises$f172(Object[] args)
    at IronPython.Objects.FunctionX.Call(Object[] args)
    at IronPython.Objects.FunctionN.Call(Object arg0, Object arg1, Object arg2, O
bject arg3)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2, Object arg3)
    at IronPython.Objects.Method.Call(Object arg0, Object arg1, Object arg2)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2)
    at test_builtincpython1.test_ord$f106(Object self) in G:\CABS\Python\FePy\Iro
nPython-0.7.1\bin\test_builtincpython1.py:line 943
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_sum>
IronPython.Objects.PythonAssertionError: TypeError
    at IronPython.Objects.Ops.Raise(Object type, Object value, Object traceback)
    at unittest.failUnlessRaises$f172(Object self, Object excClass, Object callab
leObj, Object args, Object kwargs) in G:\CABS\Python\FePy\IronPython-0.7.1\bin\u
nittest.py:line 231
    at unittest.failUnlessRaises$f172(Object[] args)
    at IronPython.Objects.FunctionX.Call(Object[] args)
    at IronPython.Objects.Ops.Call(Object func, Object[] args)
    at IronPython.Objects.Method.Call(Object arg0, Object arg1, Object arg2, Obje
ct arg3)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2, Object arg3)
    at test_builtincpython1.test_sum$f124(Object self) in G:\CABS\Python\FePy\Iro
nPython-0.7.1\bin\test_builtincpython1.py:line 1214
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

29 Exceptions

<test_builtincpython1.BuiltinTest testMethod=test_abs>
IronPython.Objects.PythonAttributeError: 'str' object has no attribute '__abs__'

    at IronPython.Objects.DynamicType.GetAttr(Object self, String name)
    at IronPython.Objects.Ops.GetAttr(Object o, String name)
    at IronPython.Modules.__builtin__.abs(Object o)
    at ReflectOpt.IronPython.Modules.__builtin__.abs(Object )
    at IronPython.Objects.BuiltinFunction.Call(Object arg0)
    at IronPython.Objects.BuiltinFunction.Call(Object[] args)
    at IronPython.Objects.Ops.Call(Object func, Object[] args)
    at IronPython.Objects.Ops.CallWithArgsTuple(Object func, Object[] args, Objec
t argsTuple)
    at unittest.failUnlessRaises$f172(Object self, Object excClass, Object callab
leObj, Object args, Object kwargs) in G:\CABS\Python\FePy\IronPython-0.7.1\bin\u
nittest.py:line 227
    at unittest.failUnlessRaises$f172(Object[] args)
    at IronPython.Objects.FunctionX.Call(Object[] args)
    at IronPython.Objects.FunctionN.Call(Object arg0, Object arg1, Object arg2, O
bject arg3)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2, Object arg3)
    at IronPython.Objects.Method.Call(Object arg0, Object arg1, Object arg2)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2)
    at test_builtincpython1.test_abs$f10(Object self) in G:\CABS\Python\FePy\Iron
Python-0.7.1\bin\test_builtincpython1.py:line 143
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_apply>
IronPython.Objects.PythonNameError: name 'self' not defined
    at IronPython.Objects.Ops.CheckInitialized(Object o)
    at test_builtincpython1.f0$f12(Object args) in G:\CABS\Python\FePy\IronPython
-0.7.1\bin\test_builtincpython1.py:line 147
    at test_builtincpython1.f0$f12(Object[] args)
    at IronPython.Objects.FunctionX.Call(Object[] args)
    at IronPython.Objects.Ops.Call(Object func, Object[] args)
    at IronPython.Objects.Ops.CallWithArgsTuple(Object func, Object[] args, Objec
t argsTuple)
    at IronPython.Modules.__builtin__.apply(Object func, Object args)
    at ReflectOpt.IronPython.Modules.__builtin__.apply(Object , Object )
    at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1)
    at test_builtincpython1.test_apply$f11(Object self) in G:\CABS\Python\FePy\Ir
onPython-0.7.1\bin\test_builtincpython1.py:line 157
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_callable>
IronPython.Objects.PythonNameError: name 'callable' not defined
    at IronPython.Objects.Ops.CheckInitialized(Object o)
    at test_builtincpython1.test_callable$f16(Object self) in G:\CABS\Python\FePy
\IronPython-0.7.1\bin\test_builtincpython1.py:line 172
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_cmp>
IronPython.Objects.PythonImportError: can't load UserList
    at IronPython.Objects.module.Import(String fullName, Boolean keepTop)
    at IronPython.Objects.Ops.ImportFromAs(module mod, String fullName, String[]
names, String[] asNames)
    at test_builtincpython1.test_cmp$f21(Object self) in G:\CABS\Python\FePy\Iron
Python-0.7.1\bin\test_builtincpython1.py:line 202
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_coerce>
IronPython.Objects.PythonNameError: name 'coerce' not defined
    at IronPython.Objects.Ops.CheckInitialized(Object o)
    at test_builtincpython1.test_coerce$f22(Object self) in G:\CABS\Python\FePy\I
ronPython-0.7.1\bin\test_builtincpython1.py:line 213
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_compile>
IronPython.Objects.PythonSyntaxError: unexpected token bad character '?' at <str
ing>:1
    at IronPython.AST.Parser.parsePrimary()
    at IronPython.AST.Parser.parsePower()
    at IronPython.AST.Parser.parseFactor()
    at IronPython.AST.Parser.parseExpr(Int32 precedence)
    at IronPython.AST.Parser.parseComparison()
    at IronPython.AST.Parser.parseNotTest()
    at IronPython.AST.Parser.parseAndTest()
    at IronPython.AST.Parser.parseTest()
    at IronPython.AST.Parser.parseTestList(Boolean& trailingComma)
    at IronPython.AST.Parser.parseTestListAsExpr()
    at IronPython.AST.Parser.parseExprStmt()
    at IronPython.AST.Parser.parseSmallStmt()
    at IronPython.AST.Parser.parseSimpleStmt()
    at IronPython.AST.Parser.parseStmt()
    at IronPython.Modules.__builtin__.compile(String source, String filename, Str
ing kind)
    at ReflectOpt.IronPython.Modules.__builtin__.compile(Object , Object , Object
  )
    at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1, Object a
rg2)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2)
    at test_builtincpython1.test_compile$f24(Object self) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\test_builtincpython1.py:line 226
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_delattr>
IronPython.Objects.PythonTypeError: can't set attributes of built-in/extension t
ype 'IronPython.Modules.sys'
    at IronPython.Objects.ReflectedType.RawSetSlot(String name, Object value)
    at IronPython.Objects.PythonType.__setattr__(String name, Object value)
    at IronPython.Objects.Ops.SetAttr(Object o, String name, Object value)
    at IronPython.Objects.Ops.SetAttrStackHelper(Object value, Object o, String n
ame)
    at test_builtincpython1.test_delattr$f25(Object self) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\test_builtincpython1.py:line 235
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_execfile>
IronPython.Objects.PythonAttributeError: type object 'BuiltinTest' has no attrib
ute 'z'
    at IronPython.Objects.Ops.GetAttr(Object o, String name)
    at test_builtincpython1.test_execfile$f38(Object self) in G:\CABS\Python\FePy
\IronPython-0.7.1\bin\test_builtincpython1.py:line 380
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_general_eval>
IronPython.Objects.PythonTypeError: Object <test_builtincpython1.M instance at 0
x00BB8560> is not of type System.Collections.IDictionary
    at ReflectOpt.IronPython.Modules.__builtin__.eval(Object , Object , Object )
    at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1, Object a
rg2)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2)
    at test_builtincpython1.test_general_eval$f29(Object self) in G:\CABS\Python\
FePy\IronPython-0.7.1\bin\test_builtincpython1.py:line 312
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_getattr>
IronPython.Objects.PythonAttributeError: type object 'IronPython.Modules.sys' ha
s no attribute 'maxunicode'
    at IronPython.Objects.Ops.GetAttr(Object o, String name)
    at test_builtincpython1.test_getattr$f74(Object self) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\test_builtincpython1.py:line 539
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_hasattr>
IronPython.Objects.PythonAttributeError: type object 'IronPython.Modules.sys' ha
s no attribute 'maxunicode'
    at IronPython.Objects.Ops.GetAttr(Object o, String name)
    at test_builtincpython1.test_hasattr$f75(Object self) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\test_builtincpython1.py:line 546
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_hash>
System.NullReferenceException: Object reference not set to an instance of an obj
ect.
    at IronPython.Objects.Ops.Hash(Object o)
    at IronPython.Modules.__builtin__.hash(Object o)
    at ReflectOpt.IronPython.Modules.__builtin__.hash(Object )
    at IronPython.Objects.BuiltinFunction.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at test_builtincpython1.test_hash$f76(Object self) in G:\CABS\Python\FePy\Iro
nPython-0.7.1\bin\test_builtincpython1.py:line 549
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_import>
IronPython.Objects.PythonNameError: name '__import__' not defined
    at IronPython.Objects.Ops.CheckInitialized(Object o)
    at test_builtincpython1.test_import$f9(Object self) in G:\CABS\Python\FePy\Ir
onPython-0.7.1\bin\test_builtincpython1.py:line 123
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_input_and_raw_input>
IronPython.Objects.PythonAttributeError: type object 'IronPython.Modules.sys' ha
s no attribute 'stdin'
    at IronPython.Objects.Ops.GetAttr(Object o, String name)
    at test_builtincpython1.test_input_and_raw_input$f109(Object self) in G:\CABS
\Python\FePy\IronPython-0.7.1\bin\test_builtincpython1.py:line 1064
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_int>
System.NotSupportedException: bad char for hex value:
    at IronPython.Objects.LiteralParser.HexValue(Char ch)
    at IronPython.Objects.LiteralParser.ParseInt(String text, Int32 b)
    at IronPython.Objects.LiteralParser.ParseInteger(String text, Int32 b)
    at IronPython.Objects.IntOps.Make(Object o)
    at ReflectOpt.System.Int32.Make(Object )
    at IronPython.Objects.BuiltinFunction.Call(Object arg0)
    at IronPython.Objects.BuiltinFunction.Call(Object[] args)
    at IronPython.Objects.ReflectedType.Call(Object[] args)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at test_builtincpython1.test_int$f80(Object self) in G:\CABS\Python\FePy\Iron
Python-0.7.1\bin\test_builtincpython1.py:line 604
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_intern>
IronPython.Objects.PythonTypeError: Object abc is not of type System.String
    at ReflectOpt.IronPython.Modules.__builtin__.setattr(Object , Object , Object
  )
    at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1, Object a
rg2)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2)
    at test_builtincpython1.test_intern$f81(Object self) in G:\CABS\Python\FePy\I
ronPython-0.7.1\bin\test_builtincpython1.py:line 659
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_isinstance>
System.NotImplementedException: The method or operation is not implemented.
    at IronPython.Modules.__builtin__.isinstance(Object o, Object typeinfo)
    at ReflectOpt.IronPython.Modules.__builtin__.isinstance(Object , Object )
    at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1)
    at test_builtincpython1.test_isinstance$f84(Object self) in G:\CABS\Python\Fe
Py\IronPython-0.7.1\bin\test_builtincpython1.py:line 684
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_issubclass>
System.NotImplementedException: The method or operation is not implemented.
    at IronPython.Objects.DynamicType.IsSubclassOf(Object other)
    at IronPython.Modules.__builtin__.issubclass(DynamicType c, Object typeinfo)
    at ReflectOpt.IronPython.Modules.__builtin__.issubclass(Object , Object )
    at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1)
    at test_builtincpython1.test_issubclass$f85(Object self) in G:\CABS\Python\Fe
Py\IronPython-0.7.1\bin\test_builtincpython1.py:line 702
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_long>
System.NotImplementedException: The method or operation is not implemented.
    at IronPython.Objects.LongOps.Make(Object o)
    at ReflectOpt.IronMath.integer.Make(Object )
    at IronPython.Objects.BuiltinFunction.Call(Object arg0)
    at IronPython.Objects.BuiltinFunction.Call(Object[] args)
    at IronPython.Objects.ReflectedType.Call(Object[] args)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at test_builtincpython1.test_long$f89(Object self) in G:\CABS\Python\FePy\Iro
nPython-0.7.1\bin\test_builtincpython1.py:line 756
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_min>
IronPython.Objects.PythonTypeError: min() takes exactly 0 argument (3 given)
    at IronPython.Objects.Function.badArgCount(Int32 count)
    at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1, Object a
rg2)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2)
    at test_builtincpython1.test_min$f100(Object self) in G:\CABS\Python\FePy\Iro
nPython-0.7.1\bin\test_builtincpython1.py:line 881
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_open>
System.IO.IOException: The process can not access the file 'G:\CABS\Python\FePy\
IronPython-0.7.1\bin\@test' because it is being used by another process.
    at System.IO.__Error.WinIOError(Int32 errorCode, String str)
    at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, F
ileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAt
trs, String msgPath, Boolean bFromProxy)
    at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access,
FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean
bFromProxy)
    at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access,
FileShare share)
    at IronPython.Objects.PythonFile.Make(String filename, String mode, Int32 buf
size)
    at IronPython.Modules.__builtin__.open(String filename, String mode)
    at ReflectOpt.IronPython.Modules.__builtin__.open(Object , Object )
    at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1)
    at test_builtincpython1.write_testfile$f104(Object self) in G:\CABS\Python\Fe
Py\IronPython-0.7.1\bin\test_builtincpython1.py:line 910
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at test_builtincpython1.test_open$f105(Object self) in G:\CABS\Python\FePy\Ir
onPython-0.7.1\bin\test_builtincpython1.py:line 923
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_pow>
IronPython.Objects.PythonTypeError: unsupported operand type(s) for **: 'long' a
nd 'int'
    at IronPython.Objects.Ops.Power(Object x, Object y)
    at IronPython.Modules.__builtin__.pow(Object x, Object y)
    at ReflectOpt.IronPython.Modules.__builtin__.pow(Object , Object )
    at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1)
    at test_builtincpython1.test_pow$f107(Object self) in G:\CABS\Python\FePy\Iro
nPython-0.7.1\bin\test_builtincpython1.py:line 962
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_range>
System.OverflowException: integer won't fit in int
    at IronMath.integer.ToInt32()
    at IronPython.Objects.Ops.object2int(Object value)
    at ReflectOpt.IronPython.Modules.__builtin__.range(Object )
    at IronPython.Objects.BuiltinFunction.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at test_builtincpython1.test_range$f108(Object self) in G:\CABS\Python\FePy\I
ronPython-0.7.1\bin\test_builtincpython1.py:line 1019
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_reduce>
IronPython.Objects.PythonAttributeError: 'int' object has no attribute '__call__
'
    at IronPython.Objects.DynamicType.GetAttr(Object self, String name)
    at IronPython.Objects.Ops.GetAttr(Object o, String name)
    at IronPython.Objects.Ops.Call(Object func, Object[] args)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1)
    at IronPython.Modules.__builtin__.reduce(Object func, Object seq)
    at ReflectOpt.IronPython.Modules.__builtin__.reduce(Object , Object )
    at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1)
    at IronPython.Objects.BuiltinFunction.Call(Object[] args)
    at IronPython.Objects.Ops.Call(Object func, Object[] args)
    at IronPython.Objects.Ops.CallWithArgsTuple(Object func, Object[] args, Objec
t argsTuple)
    at unittest.failUnlessRaises$f172(Object self, Object excClass, Object callab
leObj, Object args, Object kwargs) in G:\CABS\Python\FePy\IronPython-0.7.1\bin\u
nittest.py:line 227
    at unittest.failUnlessRaises$f172(Object[] args)
    at IronPython.Objects.FunctionX.Call(Object[] args)
    at IronPython.Objects.Ops.Call(Object func, Object[] args)
    at IronPython.Objects.Method.Call(Object arg0, Object arg1, Object arg2, Obje
ct arg3)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2, Object arg3)
    at test_builtincpython1.test_reduce$f110(Object self) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\test_builtincpython1.py:line 1121
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_reload>
IronPython.Objects.PythonImportError: can't load marshal
    at IronPython.Objects.module.Import(String fullName, Boolean keepTop)
    at IronPython.Objects.Ops.Import(module mod, String fullName)
    at test_builtincpython1.test_reload$f119(Object self) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\test_builtincpython1.py:line 1129
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_repr>
System.StackOverflowException: Exception of type 'System.StackOverflowException'
  was thrown.

<test_builtincpython1.BuiltinTest testMethod=test_setattr>
IronPython.Objects.PythonTypeError: can't set attributes of built-in/extension t
ype 'IronPython.Modules.sys'
    at IronPython.Objects.ReflectedType.RawSetSlot(String name, Object value)
    at IronPython.Objects.PythonType.__setattr__(String name, Object value)
    at IronPython.Objects.Ops.SetAttr(Object o, String name, Object value)
    at IronPython.Modules.__builtin__.setattr(Object o, String name, Object val)
    at ReflectOpt.IronPython.Modules.__builtin__.setattr(Object , Object , Object
  )
    at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1, Object a
rg2)
    at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object
arg2)
    at test_builtincpython1.test_setattr$f122(Object self) in G:\CABS\Python\FePy
\IronPython-0.7.1\bin\test_builtincpython1.py:line 1184
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

<test_builtincpython1.BuiltinTest testMethod=test_str>
System.StackOverflowException: Exception of type 'System.StackOverflowException'
  was thrown.

<test_builtincpython1.BuiltinTest testMethod=test_vars>
IronPython.Objects.PythonNameError: name 'set' not defined
    at IronPython.Objects.Ops.CheckInitialized(Object o)
    at test_builtincpython1.test_vars$f131(Object self) in G:\CABS\Python\FePy\Ir
onPython-0.7.1\bin\test_builtincpython1.py:line 1263
    at IronPython.Objects.Function1.Call(Object arg0)
    at IronPython.Objects.Ops.Call(Object func, Object arg0)
    at IronPython.Objects.Method.Call()
    at IronPython.Objects.Ops.Call(Object func)
    at unittest.__call__$f166(Object self, Object result) in G:\CABS\Python\FePy\
IronPython-0.7.1\bin\unittest.py:line 162

 >>>



From mahs at telcopartners.com  Mon Apr  4 08:46:48 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Sun, 03 Apr 2005 23:46:48 -0700
Subject: [IronPython] CPython test_builtin hacked module
Message-ID: <d2qnrf$h90$4@sea.gmane.org>

Test Module (a couple of hacks to CPython test_builtin to enable it to import 
and run on fepy 0.7.1)

# Python test set -- built-in functions << this is line 1 of the source

#import test.test_support, unittest
#from test.test_support import fcmp, have_unicode, TESTFN, unlink
have_unicode = False
import unittest
import sys

def unlink(fileobj): pass

TESTFN = '@test'

FUZZ = 1e-6

def fcmp(x, y): # fuzzy comparison function
     if type(x) == type(0.0) or type(y) == type(0.0):
         try:
             x, y = coerce(x, y)
             fuzz = (abs(x) + abs(y)) * FUZZ
             if abs(x-y) <= fuzz:
                 return 0
         except:
             pass
     elif type(x) == type(y) and type(x) in (type(()), type([])):
         for i in range(min(len(x), len(y))):
             outcome = fcmp(x[i], y[i])
             if outcome != 0:
                 return outcome
         return cmp(len(x), len(y))
     return cmp(x, y)



# import warnings, cStringIO, random, UserDict
##warnings.filterwarnings("ignore", "hex../oct.. of negative int",
##                        FutureWarning, __name__)
##warnings.filterwarnings("ignore", "integer argument expected",
##                        DeprecationWarning, "unittest")

class Squares:

     def __init__(self, max):
         self.max = max
         self.sofar = []

     def __len__(self): return len(self.sofar)

     def __getitem__(self, i):
         if not 0 <= i < self.max: raise IndexError
         n = len(self.sofar)
         while n <= i:
             self.sofar.append(n*n)
             n += 1
         return self.sofar[i]

class StrSquares:

     def __init__(self, max):
         self.max = max
         self.sofar = []

     def __len__(self):
         return len(self.sofar)

     def __getitem__(self, i):
         if not 0 <= i < self.max:
             raise IndexError
         n = len(self.sofar)
         while n <= i:
             self.sofar.append(str(n*n))
             n += 1
         return self.sofar[i]

class BitBucket:
     def write(self, line):
         pass

L = [
         ('0', 0),
         ('1', 1),
         ('9', 9),
         ('10', 10),
         ('99', 99),
         ('100', 100),
         ('314', 314),
         (' 314', 314),
         ('314 ', 314),
         ('  \t\t  314  \t\t  ', 314),
         (repr(sys.maxint), sys.maxint),
         ('  1x', ValueError),
         ('  1  ', 1),
         ('  1\02  ', ValueError),
         ('', ValueError),
         (' ', ValueError),
         ('  \t\t  ', ValueError)
]
if have_unicode:
     L += [
         (unicode('0'), 0),
         (unicode('1'), 1),
         (unicode('9'), 9),
         (unicode('10'), 10),
         (unicode('99'), 99),
         (unicode('100'), 100),
         (unicode('314'), 314),
         (unicode(' 314'), 314),
         (unicode('\u0663\u0661\u0664 ','raw-unicode-escape'), 314),
         (unicode('  \t\t  314  \t\t  '), 314),
         (unicode('  1x'), ValueError),
         (unicode('  1  '), 1),
         (unicode('  1\02  '), ValueError),
         (unicode(''), ValueError),
         (unicode(' '), ValueError),
         (unicode('  \t\t  '), ValueError),
         (unichr(0x200), ValueError),
]

class BuiltinTest(unittest.TestCase):

     __module__ = "test_builtincpython1"

     def test_import(self):
         __import__('sys')
         __import__('time')
         __import__('string')
         self.assertRaises(ImportError, __import__, 'spamspam')
         self.assertRaises(TypeError, __import__, 1, 2, 3, 4)

     def test_abs(self):
         # int
         self.assertEqual(abs(0), 0)
         self.assertEqual(abs(1234), 1234)
         self.assertEqual(abs(-1234), 1234)
         # float
         self.assertEqual(abs(0.0), 0.0)
         self.assertEqual(abs(3.14), 3.14)
         self.assertEqual(abs(-3.14), 3.14)
         # long
         self.assertEqual(abs(0L), 0L)
         self.assertEqual(abs(1234L), 1234L)
         self.assertEqual(abs(-1234L), 1234L)
         # str
         self.assertRaises(TypeError, abs, 'a')

     def test_apply(self):
         def f0(*args):
             self.assertEqual(args, ())
         def f1(a1):
             self.assertEqual(a1, 1)
         def f2(a1, a2):
             self.assertEqual(a1, 1)
             self.assertEqual(a2, 2)
         def f3(a1, a2, a3):
             self.assertEqual(a1, 1)
             self.assertEqual(a2, 2)
             self.assertEqual(a3, 3)
         apply(f0, ())
         apply(f1, (1,))
         apply(f2, (1, 2))
         apply(f3, (1, 2, 3))

         # A PyCFunction that takes only positional parameters should allow an
         # empty keyword dictionary to pass without a complaint, but raise a
         # TypeError if the dictionary is non-empty.
         apply(id, (1,), {})
         self.assertRaises(TypeError, apply, id, (1,), {"foo": 1})
         self.assertRaises(TypeError, apply)
         self.assertRaises(TypeError, apply, id, 42)
         self.assertRaises(TypeError, apply, id, (42,), 42)

     def test_callable(self):
         self.assert_(callable(len))
         def f(): pass
         self.assert_(callable(f))
         class C:
             def meth(self): pass
         self.assert_(callable(C))
         x = C()
         self.assert_(callable(x.meth))
         self.assert_(not callable(x))
         class D(C):
             def __call__(self): pass
         y = D()
         self.assert_(callable(y))
         y()

     def test_chr(self):
         self.assertEqual(chr(32), ' ')
         self.assertEqual(chr(65), 'A')
         self.assertEqual(chr(97), 'a')
         self.assertEqual(chr(0xff), '\xff')
         self.assertRaises(ValueError, chr, 256)
         self.assertRaises(TypeError, chr)

     def test_cmp(self):
         self.assertEqual(cmp(-1, 1), -1)
         self.assertEqual(cmp(1, -1), 1)
         self.assertEqual(cmp(1, 1), 0)
         # verify that circular objects are not handled
         a = []; a.append(a)
         b = []; b.append(b)
         from UserList import UserList
         c = UserList(); c.append(c)
         self.assertRaises(RuntimeError, cmp, a, b)
         self.assertRaises(RuntimeError, cmp, b, c)
         self.assertRaises(RuntimeError, cmp, c, a)
         self.assertRaises(RuntimeError, cmp, a, c)
        # okay, now break the cycles
         a.pop(); b.pop(); c.pop()
         self.assertRaises(TypeError, cmp)

     def test_coerce(self):
         self.assert_(not fcmp(coerce(1, 1.1), (1.0, 1.1)))
         self.assertEqual(coerce(1, 1L), (1L, 1L))
         self.assert_(not fcmp(coerce(1L, 1.1), (1.0, 1.1)))
         self.assertRaises(TypeError, coerce)
         class BadNumber:
             def __coerce__(self, other):
                 raise ValueError
         self.assertRaises(ValueError, coerce, 42, BadNumber())
         self.assertRaises(OverflowError, coerce, 0.5, int("12345" * 1000))

     def test_compile(self):
         compile('print 1\n', '', 'exec')
         bom = '\xef\xbb\xbf'
         compile(bom + 'print 1\n', '', 'exec')
         self.assertRaises(TypeError, compile)
         self.assertRaises(ValueError, compile, 'print 42\n', '<string>', 'badmode')
         self.assertRaises(ValueError, compile, 'print 42\n', '<string>', 
'single', 0xff)
         if have_unicode:
             compile(unicode('print u"\xc3\xa5"\n', 'utf8'), '', 'exec')

     def test_delattr(self):
         import sys
         sys.spam = 1
         delattr(sys, 'spam')
         self.assertRaises(TypeError, delattr)

     def test_dir(self):
         x = 1
         self.assert_('x' in dir())
         import sys
         self.assert_('modules' in dir(sys))
         self.assertRaises(TypeError, dir, 42, 42)

     def test_divmod(self):
         self.assertEqual(divmod(12, 7), (1, 5))
         self.assertEqual(divmod(-12, 7), (-2, 2))
         self.assertEqual(divmod(12, -7), (-2, -2))
         self.assertEqual(divmod(-12, -7), (1, -5))

         self.assertEqual(divmod(12L, 7L), (1L, 5L))
         self.assertEqual(divmod(-12L, 7L), (-2L, 2L))
         self.assertEqual(divmod(12L, -7L), (-2L, -2L))
         self.assertEqual(divmod(-12L, -7L), (1L, -5L))

         self.assertEqual(divmod(12, 7L), (1, 5L))
         self.assertEqual(divmod(-12, 7L), (-2, 2L))
         self.assertEqual(divmod(12L, -7), (-2L, -2))
         self.assertEqual(divmod(-12L, -7), (1L, -5))

         self.assertEqual(divmod(-sys.maxint-1, -1),
                          (sys.maxint+1, 0))

         self.assert_(not fcmp(divmod(3.25, 1.0), (3.0, 0.25)))
         self.assert_(not fcmp(divmod(-3.25, 1.0), (-4.0, 0.75)))
         self.assert_(not fcmp(divmod(3.25, -1.0), (-4.0, -0.75)))
         self.assert_(not fcmp(divmod(-3.25, -1.0), (3.0, -0.25)))

         self.assertRaises(TypeError, divmod)

     def test_eval(self):
         self.assertEqual(eval('1+1'), 2)
         self.assertEqual(eval(' 1+1\n'), 2)
         globals = {'a': 1, 'b': 2}
         locals = {'b': 200, 'c': 300}
         self.assertEqual(eval('a', globals) , 1)
         self.assertEqual(eval('a', globals, locals), 1)
         self.assertEqual(eval('b', globals, locals), 200)
         self.assertEqual(eval('c', globals, locals), 300)
         if have_unicode:
             self.assertEqual(eval(unicode('1+1')), 2)
             self.assertEqual(eval(unicode(' 1+1\n')), 2)
         globals = {'a': 1, 'b': 2}
         locals = {'b': 200, 'c': 300}
         if have_unicode:
             self.assertEqual(eval(unicode('a'), globals), 1)
             self.assertEqual(eval(unicode('a'), globals, locals), 1)
             self.assertEqual(eval(unicode('b'), globals, locals), 200)
             self.assertEqual(eval(unicode('c'), globals, locals), 300)
             bom = '\xef\xbb\xbf'
             self.assertEqual(eval(bom + 'a', globals, locals), 1)
             self.assertEqual(eval(unicode('u"\xc3\xa5"', 'utf8'), globals),
                              unicode('\xc3\xa5', 'utf8'))
         self.assertRaises(TypeError, eval)
         self.assertRaises(TypeError, eval, ())

     def test_general_eval(self):
         # Tests that general mappings can be used for the locals argument

         class M:
             "Test mapping interface versus possible calls from eval()."
             def __getitem__(self, key):
                 if key == 'a':
                     return 12
                 raise KeyError
             def keys(self):
                 return list('xyz')

         m = M()
         g = globals()
         self.assertEqual(eval('a', g, m), 12)
         self.assertRaises(NameError, eval, 'b', g, m)
         self.assertEqual(eval('dir()', g, m), list('xyz'))
         self.assertEqual(eval('globals()', g, m), g)
         self.assertEqual(eval('locals()', g, m), m)
         self.assertRaises(TypeError, eval, 'a', m)
         class A:
             "Non-mapping"
             pass
         m = A()
         self.assertRaises(TypeError, eval, 'a', g, m)

         # Verify that dict subclasses work as well
         class D(dict):
             def __getitem__(self, key):
                 if key == 'a':
                     return 12
                 return dict.__getitem__(self, key)
             def keys(self):
                 return list('xyz')

         d = D()
         self.assertEqual(eval('a', g, d), 12)
         self.assertRaises(NameError, eval, 'b', g, d)
         self.assertEqual(eval('dir()', g, d), list('xyz'))
         self.assertEqual(eval('globals()', g, d), g)
         self.assertEqual(eval('locals()', g, d), d)

         # Verify locals stores (used by list comps)
         eval('[locals() for i in (2,3)]', g, d)
         eval('[locals() for i in (2,3)]', g, UserDict.UserDict())

         class SpreadSheet:
             "Sample application showing nested, calculated lookups."
             _cells = {}
             def __setitem__(self, key, formula):
                 self._cells[key] = formula
             def __getitem__(self, key ):
                 return eval(self._cells[key], globals(), self)

         ss = SpreadSheet()
         ss['a1'] = '5'
         ss['a2'] = 'a1*6'
         ss['a3'] = 'a2*7'
         self.assertEqual(ss['a3'], 210)

         # Verify that dir() catches a non-list returned by eval
         # SF bug #1004669
         class C:
             def __getitem__(self, item):
                 raise KeyError(item)
             def keys(self):
                 return 'a'
         self.assertRaises(TypeError, eval, 'dir()', globals(), C())

     # Done outside of the method test_z to get the correct scope
# fepy barfs
##    z = 0
##    f = open(TESTFN, 'w')
##    f.write('z = z+1\n')
##    f.write('z = z*2\n')
##    f.close()
##    execfile(TESTFN)

     def test_execfile(self):
         globals = {'a': 1, 'b': 2}
         locals = {'b': 200, 'c': 300}

         self.assertEqual(self.__class__.z, 2)
         globals['z'] = 0
         execfile(TESTFN, globals)
         self.assertEqual(globals['z'], 2)
         locals['z'] = 0
         execfile(TESTFN, globals, locals)
         self.assertEqual(locals['z'], 2)

         class M:
             "Test mapping interface versus possible calls from execfile()."
             def __init__(self):
                 self.z = 10
             def __getitem__(self, key):
                 if key == 'z':
                     return self.z
                 raise KeyError
             def __setitem__(self, key, value):
                 if key == 'z':
                     self.z = value
                     return
                 raise KeyError

         locals = M()
         locals['z'] = 0
         execfile(TESTFN, globals, locals)
         self.assertEqual(locals['z'], 2)

         unlink(TESTFN)
         self.assertRaises(TypeError, execfile)
         import os
         self.assertRaises(IOError, execfile, os.curdir)
         self.assertRaises(IOError, execfile, "I_dont_exist")

     def test_filter(self):
         self.assertEqual(filter(lambda c: 'a' <= c <= 'z', 'Hello World'), 
'elloorld')
         self.assertEqual(filter(None, [1, 'hello', [], [3], '', None, 9, 0]), 
[1, 'hello', [3], 9])
         self.assertEqual(filter(lambda x: x > 0, [1, -3, 9, 0, 2]), [1, 9, 2])
         self.assertEqual(filter(None, Squares(10)), [1, 4, 9, 16, 25, 36, 49, 
64, 81])
         self.assertEqual(filter(lambda x: x%2, Squares(10)), [1, 9, 25, 49, 81])
         def identity(item):
             return 1
         filter(identity, Squares(5))
         self.assertRaises(TypeError, filter)
         class BadSeq(object):
             def __getitem__(self, index):
                 if index<4:
                     return 42
                 raise ValueError
         self.assertRaises(ValueError, filter, lambda x: x, BadSeq())
         def badfunc():
             pass
         self.assertRaises(TypeError, filter, badfunc, range(5))

         # test bltinmodule.c::filtertuple()
         self.assertEqual(filter(None, (1, 2)), (1, 2))
         self.assertEqual(filter(lambda x: x>=3, (1, 2, 3, 4)), (3, 4))
         self.assertRaises(TypeError, filter, 42, (1, 2))

         # test bltinmodule.c::filterstring()
         self.assertEqual(filter(None, "12"), "12")
         self.assertEqual(filter(lambda x: x>="3", "1234"), "34")
         self.assertRaises(TypeError, filter, 42, "12")
         class badstr(str):
             def __getitem__(self, index):
                 raise ValueError
         self.assertRaises(ValueError, filter, lambda x: x >="3", badstr("1234"))

         class badstr2(str):
             def __getitem__(self, index):
                 return 42
         self.assertRaises(TypeError, filter, lambda x: x >=42, badstr2("1234"))

         class weirdstr(str):
             def __getitem__(self, index):
                 return weirdstr(2*str.__getitem__(self, index))
         self.assertEqual(filter(lambda x: x>="33", weirdstr("1234")), "3344")

         class shiftstr(str):
             def __getitem__(self, index):
                 return chr(ord(str.__getitem__(self, index))+1)
         self.assertEqual(filter(lambda x: x>="3", shiftstr("1234")), "345")

         if have_unicode:
             # test bltinmodule.c::filterunicode()
             self.assertEqual(filter(None, unicode("12")), unicode("12"))
             self.assertEqual(filter(lambda x: x>="3", unicode("1234")), 
unicode("34"))
             self.assertRaises(TypeError, filter, 42, unicode("12"))
             self.assertRaises(ValueError, filter, lambda x: x >="3", 
badstr(unicode("1234")))

             class badunicode(unicode):
                 def __getitem__(self, index):
                     return 42
             self.assertRaises(TypeError, filter, lambda x: x >=42, 
badunicode("1234"))

             class weirdunicode(unicode):
                 def __getitem__(self, index):
                     return weirdunicode(2*unicode.__getitem__(self, index))
             self.assertEqual(
                 filter(lambda x: x>=unicode("33"), weirdunicode("1234")), 
unicode("3344"))

             class shiftunicode(unicode):
                 def __getitem__(self, index):
                     return unichr(ord(unicode.__getitem__(self, index))+1)
             self.assertEqual(
                 filter(lambda x: x>=unicode("3"), shiftunicode("1234")),
                 unicode("345")
             )

     def test_filter_subclasses(self):
         # test that filter() never returns tuple, str or unicode subclasses
         # and that the result always goes through __getitem__
         funcs = (None, bool, lambda x: True)
         class tuple2(tuple):
             def __getitem__(self, index):
                 return 2*tuple.__getitem__(self, index)
         class str2(str):
             def __getitem__(self, index):
                 return 2*str.__getitem__(self, index)
         inputs = {
             tuple2: {(): (), (1, 2, 3): (2, 4, 6)},
             str2:   {"": "", "123": "112233"}
         }
         if have_unicode:
             class unicode2(unicode):
                 def __getitem__(self, index):
                     return 2*unicode.__getitem__(self, index)
             inputs[unicode2] = {
                 unicode(): unicode(),
                 unicode("123"): unicode("112233")
             }

         for (cls, inps) in inputs.iteritems():
             for (inp, exp) in inps.iteritems():
                 # make sure the output goes through __getitem__
                 # even if func is None
                 self.assertEqual(
                     filter(funcs[0], cls(inp)),
                     filter(funcs[1], cls(inp))
                 )
                 for func in funcs:
                     outp = filter(func, cls(inp))
                     self.assertEqual(outp, exp)
                     self.assert_(not isinstance(outp, cls))

     def test_float(self):
         self.assertEqual(float(3.14), 3.14)
         self.assertEqual(float(314), 314.0)
         self.assertEqual(float(314L), 314.0)
         self.assertEqual(float("  3.14  "), 3.14)
         if have_unicode:
             self.assertEqual(float(unicode("  3.14  ")), 3.14)
             self.assertEqual(float(unicode("  \u0663.\u0661\u0664 
",'raw-unicode-escape')), 3.14)

     def test_getattr(self):
         import sys
         self.assert_(getattr(sys, 'stdout') is sys.stdout)
         self.assertRaises(TypeError, getattr, sys, 1)
         self.assertRaises(TypeError, getattr, sys, 1, "foo")
         self.assertRaises(TypeError, getattr)
         self.assertRaises(UnicodeError, getattr, sys, unichr(sys.maxunicode))

     def test_hasattr(self):
         import sys
         self.assert_(hasattr(sys, 'stdout'))
         self.assertRaises(TypeError, hasattr, sys, 1)
         self.assertRaises(TypeError, hasattr)
         self.assertRaises(UnicodeError, hasattr, sys, unichr(sys.maxunicode))

     def test_hash(self):
         hash(None)
         self.assertEqual(hash(1), hash(1L))
         self.assertEqual(hash(1), hash(1.0))
         hash('spam')
         if have_unicode:
             self.assertEqual(hash('spam'), hash(unicode('spam')))
         hash((0,1,2,3))
         def f(): pass
         self.assertRaises(TypeError, hash, [])
         self.assertRaises(TypeError, hash, {})

     def test_hex(self):
         self.assertEqual(hex(16), '0x10')
         self.assertEqual(hex(16L), '0x10L')
         self.assertEqual(hex(-16), '-0x10')
         self.assertEqual(hex(-16L), '-0x10L')
         self.assertRaises(TypeError, hex, {})

     def test_id(self):
         id(None)
         id(1)
         id(1L)
         id(1.0)
         id('spam')
         id((0,1,2,3))
         id([0,1,2,3])
         id({'spam': 1, 'eggs': 2, 'ham': 3})

     # Test input() later, together with raw_input

     def test_int(self):
         self.assertEqual(int(314), 314)
         self.assertEqual(int(3.14), 3)
         self.assertEqual(int(314L), 314)
         # Check that conversion from float truncates towards zero
         self.assertEqual(int(-3.14), -3)
         self.assertEqual(int(3.9), 3)
         self.assertEqual(int(-3.9), -3)
         self.assertEqual(int(3.5), 3)
         self.assertEqual(int(-3.5), -3)
         # Different base:
         self.assertEqual(int("10",16), 16L)
         if have_unicode:
             self.assertEqual(int(unicode("10"),16), 16L)
         # Test conversion from strings and various anomalies
         for s, v in L:
             for sign in "", "+", "-":
                 for prefix in "", " ", "\t", "  \t\t  ":
                     ss = prefix + sign + s
                     vv = v
                     if sign == "-" and v is not ValueError:
                         vv = -v
                     try:
                         self.assertEqual(int(ss), vv)
                     except v:
                         pass

         s = repr(-1-sys.maxint)
         self.assertEqual(int(s)+1, -sys.maxint)
         # should return long
         int(s[1:])

         # should return long
         x = int(1e100)
         self.assert_(isinstance(x, long))
         x = int(-1e100)
         self.assert_(isinstance(x, long))


         # SF bug 434186:  0x80000000/2 != 0x80000000>>1.
         # Worked by accident in Windows release build, but failed in debug build.
         # Failed in all Linux builds.
         x = -1-sys.maxint
         self.assertEqual(x >> 1, x//2)

         self.assertRaises(ValueError, int, '123\0')
         self.assertRaises(ValueError, int, '53', 40)

         x = int('1' * 600)
         self.assert_(isinstance(x, long))

         if have_unicode:
             x = int(unichr(0x661) * 600)
             self.assert_(isinstance(x, long))

         self.assertRaises(TypeError, int, 1, 12)

         self.assertEqual(int('0123', 0), 83)

     def test_intern(self):
         self.assertRaises(TypeError, intern)
         s = "never interned before"
         self.assert_(intern(s) is s)
         s2 = s.swapcase().swapcase()
         self.assert_(intern(s2) is s)

         # Subclasses of string can't be interned, because they
         # provide too much opportunity for insane things to happen.
         # We don't want them in the interned dict and if they aren't
         # actually interned, we don't want to create the appearance
         # that they are by allowing intern() to succeeed.
         class S(str):
             def __hash__(self):
                 return 123

         self.assertRaises(TypeError, intern, S("abc"))

         # It's still safe to pass these strings to routines that
         # call intern internally, e.g. PyObject_SetAttr().
         s = S("abc")
         setattr(s, s, s)
         self.assertEqual(getattr(s, s), s)

     def test_iter(self):
         self.assertRaises(TypeError, iter)
         self.assertRaises(TypeError, iter, 42, 42)
         lists = [("1", "2"), ["1", "2"], "12"]
         if have_unicode:
             lists.append(unicode("12"))
         for l in lists:
             i = iter(l)
             self.assertEqual(i.next(), '1')
             self.assertEqual(i.next(), '2')
             self.assertRaises(StopIteration, i.next)

     def test_isinstance(self):
         class C:
             pass
         class D(C):
             pass
         class E:
             pass
         c = C()
         d = D()
         e = E()
         self.assert_(isinstance(c, C))
         self.assert_(isinstance(d, C))
         self.assert_(not isinstance(e, C))
         self.assert_(not isinstance(c, D))
         self.assert_(not isinstance('foo', E))
         self.assertRaises(TypeError, isinstance, E, 'foo')
         self.assertRaises(TypeError, isinstance)

     def test_issubclass(self):
         class C:
             pass
         class D(C):
             pass
         class E:
             pass
         c = C()
         d = D()
         e = E()
         self.assert_(issubclass(D, C))
         self.assert_(issubclass(C, C))
         self.assert_(not issubclass(C, D))
         self.assertRaises(TypeError, issubclass, 'foo', E)
         self.assertRaises(TypeError, issubclass, E, 'foo')
         self.assertRaises(TypeError, issubclass)

     def test_len(self):
         self.assertEqual(len('123'), 3)
         self.assertEqual(len(()), 0)
         self.assertEqual(len((1, 2, 3, 4)), 4)
         self.assertEqual(len([1, 2, 3, 4]), 4)
         self.assertEqual(len({}), 0)
         self.assertEqual(len({'a':1, 'b': 2}), 2)
         class BadSeq:
             def __len__(self):
                 raise ValueError
         self.assertRaises(ValueError, len, BadSeq())

     def test_list(self):
         self.assertEqual(list([]), [])
         l0_3 = [0, 1, 2, 3]
         l0_3_bis = list(l0_3)
         self.assertEqual(l0_3, l0_3_bis)
         self.assert_(l0_3 is not l0_3_bis)
         self.assertEqual(list(()), [])
         self.assertEqual(list((0, 1, 2, 3)), [0, 1, 2, 3])
         self.assertEqual(list(''), [])
         self.assertEqual(list('spam'), ['s', 'p', 'a', 'm'])

         if sys.maxint == 0x7fffffff:
             # This test can currently only work on 32-bit machines.
             # XXX If/when PySequence_Length() returns a ssize_t, it should be
             # XXX re-enabled.
             # Verify clearing of bug #556025.
             # This assumes that the max data size (sys.maxint) == max
             # address size this also assumes that the address size is at
             # least 4 bytes with 8 byte addresses, the bug is not well
             # tested
             #
             # Note: This test is expected to SEGV under Cygwin 1.3.12 or
             # earlier due to a newlib bug.  See the following mailing list
             # thread for the details:

             #     http://sources.redhat.com/ml/newlib/2002/msg00369.html
             self.assertRaises(MemoryError, list, xrange(sys.maxint // 2))

         # This code used to segfault in Py2.4a3
##        x = []
##        x.extend(-y for y in x)
##        self.assertEqual(x, [])

     def test_long(self):
         self.assertEqual(long(314), 314L)
         self.assertEqual(long(3.14), 3L)
         self.assertEqual(long(314L), 314L)
         # Check that conversion from float truncates towards zero
         self.assertEqual(long(-3.14), -3L)
         self.assertEqual(long(3.9), 3L)
         self.assertEqual(long(-3.9), -3L)
         self.assertEqual(long(3.5), 3L)
         self.assertEqual(long(-3.5), -3L)
         self.assertEqual(long("-3"), -3L)
         if have_unicode:
             self.assertEqual(long(unicode("-3")), -3L)
         # Different base:
         self.assertEqual(long("10",16), 16L)
         if have_unicode:
             self.assertEqual(long(unicode("10"),16), 16L)
         # Check conversions from string (same test set as for int(), and then some)
         LL = [
                 ('1' + '0'*20, 10L**20),
                 ('1' + '0'*100, 10L**100)
         ]
         L2 = L[:]
         if have_unicode:
             L2 += [
                 (unicode('1') + unicode('0')*20, 10L**20),
                 (unicode('1') + unicode('0')*100, 10L**100),
         ]
         for s, v in L2 + LL:
             for sign in "", "+", "-":
                 for prefix in "", " ", "\t", "  \t\t  ":
                     ss = prefix + sign + s
                     vv = v
                     if sign == "-" and v is not ValueError:
                         vv = -v
                     try:
                         self.assertEqual(long(ss), long(vv))
                     except v:
                         pass

         self.assertRaises(ValueError, long, '123\0')
         self.assertRaises(ValueError, long, '53', 40)
         self.assertRaises(TypeError, long, 1, 12)

     def test_map(self):
         self.assertEqual(
             map(None, 'hello world'),
             ['h','e','l','l','o',' ','w','o','r','l','d']
         )
         self.assertEqual(
             map(None, 'abcd', 'efg'),
             [('a', 'e'), ('b', 'f'), ('c', 'g'), ('d', None)]
         )
         self.assertEqual(
             map(None, range(10)),
             [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
         )
         self.assertEqual(
             map(lambda x: x*x, range(1,4)),
             [1, 4, 9]
         )
         try:
             from math import sqrt
         except ImportError:
             def sqrt(x):
                 return pow(x, 0.5)
         self.assertEqual(
             map(lambda x: map(sqrt,x), [[16, 4], [81, 9]]),
             [[4.0, 2.0], [9.0, 3.0]]
         )
         self.assertEqual(
             map(lambda x, y: x+y, [1,3,2], [9,1,4]),
             [10, 4, 6]
         )

         def plus(*v):
             accu = 0
             for i in v: accu = accu + i
             return accu
         self.assertEqual(
             map(plus, [1, 3, 7]),
             [1, 3, 7]
         )
         self.assertEqual(
             map(plus, [1, 3, 7], [4, 9, 2]),
             [1+4, 3+9, 7+2]
         )
         self.assertEqual(
             map(plus, [1, 3, 7], [4, 9, 2], [1, 1, 0]),
             [1+4+1, 3+9+1, 7+2+0]
         )
         self.assertEqual(
             map(None, Squares(10)),
             [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
         )
         self.assertEqual(
             map(int, Squares(10)),
             [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
         )
         self.assertEqual(
             map(None, Squares(3), Squares(2)),
             [(0,0), (1,1), (4,None)]
         )
         self.assertEqual(
             map(max, Squares(3), Squares(2)),
             [0, 1, 4]
         )
         self.assertRaises(TypeError, map)
         self.assertRaises(TypeError, map, lambda x: x, 42)
         self.assertEqual(map(None, [42]), [42])
         class BadSeq:
             def __getitem__(self, index):
                 raise ValueError
         self.assertRaises(ValueError, map, lambda x: x, BadSeq())

     def test_max(self):
         self.assertEqual(max('123123'), '3')
         self.assertEqual(max(1, 2, 3), 3)
         self.assertEqual(max((1, 2, 3, 1, 2, 3)), 3)
         self.assertEqual(max([1, 2, 3, 1, 2, 3]), 3)

         self.assertEqual(max(1, 2L, 3.0), 3.0)
         self.assertEqual(max(1L, 2.0, 3), 3)
         self.assertEqual(max(1.0, 2, 3L), 3L)

     def test_min(self):
         self.assertEqual(min('123123'), '1')
         self.assertEqual(min(1, 2, 3), 1)
         self.assertEqual(min((1, 2, 3, 1, 2, 3)), 1)
         self.assertEqual(min([1, 2, 3, 1, 2, 3]), 1)

         self.assertEqual(min(1, 2L, 3.0), 1)
         self.assertEqual(min(1L, 2.0, 3), 1L)
         self.assertEqual(min(1.0, 2, 3L), 1.0)

         self.assertRaises(TypeError, min)
         self.assertRaises(TypeError, min, 42)
         self.assertRaises(ValueError, min, ())
         class BadSeq:
             def __getitem__(self, index):
                 raise ValueError
         self.assertRaises(ValueError, min, BadSeq())
         class BadNumber:
             def __cmp__(self, other):
                 raise ValueError
         self.assertRaises(ValueError, min, (42, BadNumber()))

     def test_oct(self):
         self.assertEqual(oct(100), '0144')
         self.assertEqual(oct(100L), '0144L')
         self.assertEqual(oct(-100), '-0144')
         self.assertEqual(oct(-100L), '-0144L')
         self.assertRaises(TypeError, oct, ())

     def write_testfile(self):
         # NB the first 4 lines are also used to test input and raw_input, below
         fp = open(TESTFN, 'w')
         try:
             fp.write('1+1\n')
             fp.write('1+1\n')
             fp.write('The quick brown fox jumps over the lazy dog')
             fp.write('.\n')
             fp.write('Dear John\n')
             fp.write('XXX'*100)
             fp.write('YYY'*100)
         finally:
             fp.close()

     def test_open(self):
         self.write_testfile()
         fp = open(TESTFN, 'r')
         try:
             self.assertEqual(fp.readline(4), '1+1\n')
             self.assertEqual(fp.readline(4), '1+1\n')
             self.assertEqual(fp.readline(), 'The quick brown fox jumps over the 
lazy dog.\n')
             self.assertEqual(fp.readline(4), 'Dear')
             self.assertEqual(fp.readline(100), ' John\n')
             self.assertEqual(fp.read(300), 'XXX'*100)
             self.assertEqual(fp.read(1000), 'YYY'*100)
         finally:
             fp.close()
         unlink(TESTFN)

     def test_ord(self):
         self.assertEqual(ord(' '), 32)
         self.assertEqual(ord('A'), 65)
         self.assertEqual(ord('a'), 97)
         if have_unicode:
             self.assertEqual(ord(unichr(sys.maxunicode)), sys.maxunicode)
         self.assertRaises(TypeError, ord, 42)
         self.assertRaises(TypeError, ord, unicode("12"))

     def test_pow(self):
         self.assertEqual(pow(0,0), 1)
         self.assertEqual(pow(0,1), 0)
         self.assertEqual(pow(1,0), 1)
         self.assertEqual(pow(1,1), 1)

         self.assertEqual(pow(2,0), 1)
         self.assertEqual(pow(2,10), 1024)
         self.assertEqual(pow(2,20), 1024*1024)
         self.assertEqual(pow(2,30), 1024*1024*1024)

         self.assertEqual(pow(-2,0), 1)
         self.assertEqual(pow(-2,1), -2)
         self.assertEqual(pow(-2,2), 4)
         self.assertEqual(pow(-2,3), -8)

         self.assertEqual(pow(0L,0), 1)
         self.assertEqual(pow(0L,1), 0)
         self.assertEqual(pow(1L,0), 1)
         self.assertEqual(pow(1L,1), 1)

         self.assertEqual(pow(2L,0), 1)
         self.assertEqual(pow(2L,10), 1024)
         self.assertEqual(pow(2L,20), 1024*1024)
         self.assertEqual(pow(2L,30), 1024*1024*1024)

         self.assertEqual(pow(-2L,0), 1)
         self.assertEqual(pow(-2L,1), -2)
         self.assertEqual(pow(-2L,2), 4)
         self.assertEqual(pow(-2L,3), -8)

         self.assertAlmostEqual(pow(0.,0), 1.)
         self.assertAlmostEqual(pow(0.,1), 0.)
         self.assertAlmostEqual(pow(1.,0), 1.)
         self.assertAlmostEqual(pow(1.,1), 1.)

         self.assertAlmostEqual(pow(2.,0), 1.)
         self.assertAlmostEqual(pow(2.,10), 1024.)
         self.assertAlmostEqual(pow(2.,20), 1024.*1024.)
         self.assertAlmostEqual(pow(2.,30), 1024.*1024.*1024.)

         self.assertAlmostEqual(pow(-2.,0), 1.)
         self.assertAlmostEqual(pow(-2.,1), -2.)
         self.assertAlmostEqual(pow(-2.,2), 4.)
         self.assertAlmostEqual(pow(-2.,3), -8.)

         for x in 2, 2L, 2.0:
             for y in 10, 10L, 10.0:
                 for z in 1000, 1000L, 1000.0:
                     if isinstance(x, float) or \
                        isinstance(y, float) or \
                        isinstance(z, float):
                         self.assertRaises(TypeError, pow, x, y, z)
                     else:
                         self.assertAlmostEqual(pow(x, y, z), 24.0)

         self.assertRaises(TypeError, pow, -1, -2, 3)
         self.assertRaises(ValueError, pow, 1, 2, 0)
         self.assertRaises(TypeError, pow, -1L, -2L, 3L)
         self.assertRaises(ValueError, pow, 1L, 2L, 0L)
         self.assertRaises(ValueError, pow, -342.43, 0.234)

         self.assertRaises(TypeError, pow)

     def test_range(self):
         self.assertEqual(range(3), [0, 1, 2])
         self.assertEqual(range(1, 5), [1, 2, 3, 4])
         self.assertEqual(range(0), [])
         self.assertEqual(range(-3), [])
         self.assertEqual(range(1, 10, 3), [1, 4, 7])
         self.assertEqual(range(5, -5, -3), [5, 2, -1, -4])

         # Now test range() with longs
         self.assertEqual(range(-2**100), [])
         self.assertEqual(range(0, -2**100), [])
         self.assertEqual(range(0, 2**100, -1), [])
         self.assertEqual(range(0, 2**100, -1), [])

         a = long(10 * sys.maxint)
         b = long(100 * sys.maxint)
         c = long(50 * sys.maxint)

         self.assertEqual(range(a, a+2), [a, a+1])
         self.assertEqual(range(a+2, a, -1L), [a+2, a+1])
         self.assertEqual(range(a+4, a, -2), [a+4, a+2])

         seq = range(a, b, c)
         self.assert_(a in seq)
         self.assert_(b not in seq)
         self.assertEqual(len(seq), 2)

         seq = range(b, a, -c)
         self.assert_(b in seq)
         self.assert_(a not in seq)
         self.assertEqual(len(seq), 2)

         seq = range(-a, -b, -c)
         self.assert_(-a in seq)
         self.assert_(-b not in seq)
         self.assertEqual(len(seq), 2)

         self.assertRaises(TypeError, range)
         self.assertRaises(TypeError, range, 1, 2, 3, 4)
         self.assertRaises(ValueError, range, 1, 2, 0)

         # Reject floats when it would require PyLongs to represent.
         # (smaller floats still accepted, but deprecated)
         self.assertRaises(TypeError, range, 1e100, 1e101, 1e101)

         self.assertRaises(TypeError, range, 0, "spam")
         self.assertRaises(TypeError, range, 0, 42, "spam")

         self.assertRaises(OverflowError, range, -sys.maxint, sys.maxint)
         self.assertRaises(OverflowError, range, 0, 2*sys.maxint)

     def test_input_and_raw_input(self):
         self.write_testfile()
         fp = open(TESTFN, 'r')
         savestdin = sys.stdin
         savestdout = sys.stdout # Eats the echo
         try:
             sys.stdin = fp
             sys.stdout = BitBucket()
             self.assertEqual(input(), 2)
             self.assertEqual(input('testing\n'), 2)
             self.assertEqual(raw_input(), 'The quick brown fox jumps over the 
lazy dog.')
             self.assertEqual(raw_input('testing\n'), 'Dear John')
             sys.stdin = cStringIO.StringIO("NULL\0")
             self.assertRaises(TypeError, input, 42, 42)
             sys.stdin = cStringIO.StringIO("    'whitespace'")
             self.assertEqual(input(), 'whitespace')
             sys.stdin = cStringIO.StringIO()
             self.assertRaises(EOFError, input)

             # SF 876178: make sure input() respect future options.
             sys.stdin = cStringIO.StringIO('1/2')
             sys.stdout = cStringIO.StringIO()
             exec compile('print input()', 'test_builtin_tmp', 'exec')
             sys.stdin.seek(0, 0)
             exec compile('from __future__ import division;print input()',
                          'test_builtin_tmp', 'exec')
             sys.stdin.seek(0, 0)
             exec compile('print input()', 'test_builtin_tmp', 'exec')
             self.assertEqual(sys.stdout.getvalue().splitlines(),
                              ['0', '0.5', '0'])

             del sys.stdout
             self.assertRaises(RuntimeError, input, 'prompt')
             del sys.stdin
             self.assertRaises(RuntimeError, input, 'prompt')
         finally:
             sys.stdin = savestdin
             sys.stdout = savestdout
             fp.close()
             unlink(TESTFN)

     def test_reduce(self):
         self.assertEqual(reduce(lambda x, y: x+y, ['a', 'b', 'c'], ''), 'abc')
         self.assertEqual(
             reduce(lambda x, y: x+y, [['a', 'c'], [], ['d', 'w']], []),
             ['a','c','d','w']
         )
         self.assertEqual(reduce(lambda x, y: x*y, range(2,8), 1), 5040)
         self.assertEqual(
             reduce(lambda x, y: x*y, range(2,21), 1L),
             2432902008176640000L
         )
         self.assertEqual(reduce(lambda x, y: x+y, Squares(10)), 285)
         self.assertEqual(reduce(lambda x, y: x+y, Squares(10), 0), 285)
         self.assertEqual(reduce(lambda x, y: x+y, Squares(0), 0), 0)
         self.assertRaises(TypeError, reduce)
         self.assertRaises(TypeError, reduce, 42, 42)
         self.assertRaises(TypeError, reduce, 42, 42, 42)
         self.assertEqual(reduce(42, "1"), "1") # func is never called with one item
         self.assertEqual(reduce(42, "", "1"), "1") # func is never called with 
one item
         self.assertRaises(TypeError, reduce, 42, (42, 42))

         class BadSeq:
             def __getitem__(self, index):
                 raise ValueError
         self.assertRaises(ValueError, reduce, 42, BadSeq())

     def test_reload(self):
         import marshal
         reload(marshal)
         import string
         reload(string)
         ## import sys
         ## self.assertRaises(ImportError, reload, sys)

     def test_repr(self):
         self.assertEqual(repr(''), '\'\'')
         self.assertEqual(repr(0), '0')
         self.assertEqual(repr(0L), '0L')
         self.assertEqual(repr(()), '()')
         self.assertEqual(repr([]), '[]')
         self.assertEqual(repr({}), '{}')
         a = []
         a.append(a)
         self.assertEqual(repr(a), '[[...]]')
         a = {}
         a[0] = a
         self.assertEqual(repr(a), '{0: {...}}')

     def test_round(self):
         self.assertEqual(round(0.0), 0.0)
         self.assertEqual(round(1.0), 1.0)
         self.assertEqual(round(10.0), 10.0)
         self.assertEqual(round(1000000000.0), 1000000000.0)
         self.assertEqual(round(1e20), 1e20)

         self.assertEqual(round(-1.0), -1.0)
         self.assertEqual(round(-10.0), -10.0)
         self.assertEqual(round(-1000000000.0), -1000000000.0)
         self.assertEqual(round(-1e20), -1e20)

         self.assertEqual(round(0.1), 0.0)
         self.assertEqual(round(1.1), 1.0)
         self.assertEqual(round(10.1), 10.0)
         self.assertEqual(round(1000000000.1), 1000000000.0)

         self.assertEqual(round(-1.1), -1.0)
         self.assertEqual(round(-10.1), -10.0)
         self.assertEqual(round(-1000000000.1), -1000000000.0)

         self.assertEqual(round(0.9), 1.0)
         self.assertEqual(round(9.9), 10.0)
         self.assertEqual(round(999999999.9), 1000000000.0)

         self.assertEqual(round(-0.9), -1.0)
         self.assertEqual(round(-9.9), -10.0)
         self.assertEqual(round(-999999999.9), -1000000000.0)

         self.assertEqual(round(-8.0, -1), -10.0)

         self.assertRaises(TypeError, round)

     def test_setattr(self):
         setattr(sys, 'spam', 1)
         self.assertEqual(sys.spam, 1)
         self.assertRaises(TypeError, setattr, sys, 1, 'spam')
         self.assertRaises(TypeError, setattr)

     def test_str(self):
         self.assertEqual(str(''), '')
         self.assertEqual(str(0), '0')
         self.assertEqual(str(0L), '0')
         self.assertEqual(str(()), '()')
         self.assertEqual(str([]), '[]')
         self.assertEqual(str({}), '{}')
         a = []
         a.append(a)
         self.assertEqual(str(a), '[[...]]')
         a = {}
         a[0] = a
         self.assertEqual(str(a), '{0: {...}}')

     def test_sum(self):
         self.assertEqual(sum([]), 0)
         self.assertEqual(sum(range(2,8)), 27)
         self.assertEqual(sum(iter(range(2,8))), 27)
         self.assertEqual(sum(Squares(10)), 285)
         self.assertEqual(sum(iter(Squares(10))), 285)
         self.assertEqual(sum([[1], [2], [3]], []), [1, 2, 3])

         self.assertRaises(TypeError, sum)
         self.assertRaises(TypeError, sum, 42)
         self.assertRaises(TypeError, sum, ['a', 'b', 'c'])
         self.assertRaises(TypeError, sum, ['a', 'b', 'c'], '')
         self.assertRaises(TypeError, sum, [[1], [2], [3]])
         self.assertRaises(TypeError, sum, [{2:3}])
         self.assertRaises(TypeError, sum, [{2:3}]*2, {2:3})

         class BadSeq:
             def __getitem__(self, index):
                 raise ValueError
         self.assertRaises(ValueError, sum, BadSeq())

     def test_tuple(self):
         self.assertEqual(tuple(()), ())
         t0_3 = (0, 1, 2, 3)
         t0_3_bis = tuple(t0_3)
         self.assert_(t0_3 is t0_3_bis)
         self.assertEqual(tuple([]), ())
         self.assertEqual(tuple([0, 1, 2, 3]), (0, 1, 2, 3))
         self.assertEqual(tuple(''), ())
         self.assertEqual(tuple('spam'), ('s', 'p', 'a', 'm'))

     def test_type(self):
         self.assertEqual(type(''),  type('123'))
         self.assertNotEqual(type(''), type(()))

     def test_unichr(self):
         if have_unicode:
             self.assertEqual(unichr(32), unicode(' '))
             self.assertEqual(unichr(65), unicode('A'))
             self.assertEqual(unichr(97), unicode('a'))
             self.assertEqual(
                 unichr(sys.maxunicode),
                 unicode('\\U%08x' % (sys.maxunicode), 'unicode-escape')
             )
             self.assertRaises(ValueError, unichr, sys.maxunicode+1)
             self.assertRaises(TypeError, unichr)

     def get_vars_f0():
         return vars()
     # we don't want self in vars(), so use staticmethod
     get_vars_f0 = staticmethod(get_vars_f0)

     def get_vars_f2():
         BuiltinTest.get_vars_f0()
         a = 1
         b = 2
         return vars()
     get_vars_f2 = staticmethod(get_vars_f2)

     def test_vars(self):
         self.assertEqual(set(vars()), set(dir()))
         import sys
         self.assertEqual(set(vars(sys)), set(dir(sys)))
         self.assertEqual(self.get_vars_f0(), {})
         self.assertEqual(self.get_vars_f2(), {'a': 1, 'b': 2})
         self.assertRaises(TypeError, vars, 42, 42)
         self.assertRaises(TypeError, vars, 42)

     def test_zip(self):
         a = (1, 2, 3)
         b = (4, 5, 6)
         t = [(1, 4), (2, 5), (3, 6)]
         self.assertEqual(zip(a, b), t)
         b = [4, 5, 6]
         self.assertEqual(zip(a, b), t)
         b = (4, 5, 6, 7)
         self.assertEqual(zip(a, b), t)
         class I:
             def __getitem__(self, i):
                 if i < 0 or i > 2: raise IndexError
                 return i + 4
         self.assertEqual(zip(a, I()), t)
         self.assertEqual(zip(), [])
         self.assertEqual(zip(*[]), [])
         self.assertRaises(TypeError, zip, None)
         class G:
             pass
         self.assertRaises(TypeError, zip, a, G())

         # Make sure zip doesn't try to allocate a billion elements for the
         # result list when one of its arguments doesn't say how long it is.
         # A MemoryError is the most likely failure mode.
         class SequenceWithoutALength:
             def __getitem__(self, i):
                 if i == 5:
                     raise IndexError
                 else:
                     return i
         self.assertEqual(
             zip(SequenceWithoutALength(), xrange(2**30)),
             list(enumerate(range(5)))
         )

         class BadSeq:
             def __getitem__(self, i):
                 if i == 5:
                     raise ValueError
                 else:
                     return i
         self.assertRaises(ValueError, zip, BadSeq(), BadSeq())

class TestSorted(unittest.TestCase):

     def test_basic(self):
         data = range(100)
         copy = data[:]
         random.shuffle(copy)
         self.assertEqual(data, sorted(copy))
         self.assertNotEqual(data, copy)

         data.reverse()
         random.shuffle(copy)
         self.assertEqual(data, sorted(copy, cmp=lambda x, y: cmp(y,x)))
         self.assertNotEqual(data, copy)
         random.shuffle(copy)
         self.assertEqual(data, sorted(copy, key=lambda x: -x))
         self.assertNotEqual(data, copy)
         random.shuffle(copy)
         self.assertEqual(data, sorted(copy, reverse=1))
         self.assertNotEqual(data, copy)

     def test_inputtypes(self):
         s = 'abracadabra'
         for T in [unicode, list, tuple]:
             self.assertEqual(sorted(s), sorted(T(s)))

         s = ''.join(dict.fromkeys(s).keys())  # unique letters only
         for T in [unicode, set, frozenset, list, tuple, dict.fromkeys]:
             self.assertEqual(sorted(s), sorted(T(s)))

     def test_baddecorator(self):
         data = 'The quick Brown fox Jumped over The lazy Dog'.split()
         self.assertRaises(TypeError, sorted, data, None, lambda x,y: 0)

def test_main():
     test.test_support.run_unittest(BuiltinTest, TestSorted)

if __name__ == "__main__":
     test_main()

def fepytest():
     methods = ['test_abs', 'test_apply', 'test_callable', 'test_chr',
     'test_cmp', 'test_coerce', 'test_compile', 'test_delattr',
     'test_dir', 'test_divmod', 'test_eval', 'test_execfile',
     'test_filter', 'test_filter_subclasses', 'test_float',
     'test_general_eval', 'test_getattr', 'test_hasattr', 'test_hash',
     'test_hex', 'test_id', 'test_import', 'test_input_and_raw_input',
     'test_int', 'test_intern', 'test_isinstance', 'test_issubclass',
     'test_iter', 'test_len', 'test_list', 'test_long', 'test_map',
     'test_max', 'test_min', 'test_oct', 'test_open', 'test_ord',
     'test_pow', 'test_range', 'test_reduce', 'test_reload',
     'test_repr', 'test_round', 'test_setattr', 'test_str', 'test_sum',
     'test_tuple', 'test_type', 'test_unichr', 'test_vars'] #, 'test_zip']

     result = unittest.TestResult()
     for meth in methods:
         test = BuiltinTest(meth)
         test(result)
         print meth, ["Failed", "Succeeded"][result.last_succeeded]

     return result

def formatfepyfailures(result):
     print "%s Tests failed:\n" % len(result.failures)
     for meth, failure in result.failures:
         print repr(meth)
         print failure
         print
     print "%s Exceptions\n" % len(result.errors)
     for exc, failure in result.errors:
         print repr(exc)
         print failure
         print



From jimhug at microsoft.com  Tue Apr  5 01:17:25 2005
From: jimhug at microsoft.com (Jim Hugunin)
Date: Mon, 4 Apr 2005 16:17:25 -0700
Subject: [IronPython] More discussion of the IronPython license
Message-ID: <695D7C410F74A644B5335E47FB73E17E038996BA@RED-MSG-52.redmond.corp.microsoft.com>

I know that I've been very quiet with answering questions about the
license used for IronPython.  This is primarily because I'm not the
right person to be addressing these questions.  Jason Matusow, MS's
director of shared source, has been blogging about this license over the
past week and now has some more answers to common questions about the
license being used for IronPython up here:

http://blogs.msdn.com/jasonmatusow/archive/2005/04/04/405346.aspx

If you have concerns or questions about the license, you should take a
look at what Jason has to say and feel free to send him your comments as
well.

Thanks - Jim


From kfarmer at thuban.org  Tue Apr  5 01:24:13 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Mon, 4 Apr 2005 16:24:13 -0700
Subject: [IronPython] Sample project idea
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C136980@nostromo.circle-cross.home>

A few years ago, I created an AppBar by merging wxPython, what became
PyCrust, and the win32 extensions.  I just realized how much easier
it'll be to re-create that (and how much more likely it'll be to work
correctly).  The old project is here: 
 
    http://www.thuban.org:8080/projects/PyAppBar
 
Is IronPythonConsole going to have a WinForms control available to wrap
it?  Personally, I've thought that having an InterpreterControl class
with configurable styling and event handling would be interesting for
such things as Python, but designing such a thing is outside of my
experience.
 
I think it'd make an interesting (and potentially useful) sample
project.  Perhaps it would drive the WinForms team to package
ApplicationToolbar and BandObject classes?
 
----------
Keith J. Farmer
kfarmer at thuban.org
http://www.thuban.org
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050404/146f4597/attachment.html>

From martmaly at exchange.microsoft.com  Tue Apr  5 01:26:01 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Mon, 4 Apr 2005 16:26:01 -0700
Subject: [IronPython] Re: CPython's test_builtin results summary
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7FAA@df-chewy-msg.exchange.corp.microsoft.com>

Hi Michael,

I did not perceive your original email as critical or emphasizing
failures and I am really glad that you took the effort to run the tests.
I also realize that the original request for bug reports was not very
clear and that is why I used this opportunity to clarify that we are
working on running the whole test suite and we expect to find lot of
problems along the way.

I can see your emails just came through... Since you have spent the time
and modified the tests so that they can readily run on IronPython,
filing the actual bugs is not necessary because we can simply run your
modified test and fix whatever the test indicates failure on. It will
save you the time needed to file the bugs and it will save us the time
having to deal with the bugs one by one rather than just run long repro
and proceed as tests fail.



> Michael Spencer Wrote:
> 
> Hi Martin
> 
> My point was not to emphasize the test failures but rather to share
the
> techniques required to get the tests to run, which I thought might be
of
> interest to other users.  Unfortunately, my two additional posts which
> contain
> the detail results and the code are being held by the mailserver
pending
> moderator approval to exceed 40K.  Especially in the absence of these
> posts, it
> may appear that I am being critical, which is not the case at all.
> 
> You have requested bug reports from the community, without spcifying
what
> sort
> of bugs you want to focus on.  For reasons of my own, I have chosen to
> focus
> systematically on built-ins, and have shared my approach and findings,
in
> case
> they are of any use/interest to others.  In particular, there are
probably
> 30-50
> specific bug reports that can be extracted from these tests.  Do you
want
> me to
> file them?
> 
> Cheers
> Michael


From martmaly at exchange.microsoft.com  Tue Apr  5 01:33:04 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Mon, 4 Apr 2005 16:33:04 -0700
Subject: [IronPython] Tests, and plans
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7FB3@df-chewy-msg.exchange.corp.microsoft.com>

> Keith J. Farmer Wrote:
> Well, since these tests will be viewed by many to be the standard, do
> the tests planned include a superset of these, at least?

Yes.

> I was making a haphazard estimate of the timing for 1.0, figuring a
> two-week cycle, going no further than 0.0.x, would give up to 60 weeks
> for 1.0 release.  I'm guessing y'all are planning for much sooner than
> that?

Yes, we are.

Martin


From Dave at Cold-Mountain.com  Tue Apr  5 02:52:37 2005
From: Dave at Cold-Mountain.com (Dave Gustafson)
Date: Mon, 4 Apr 2005 18:52:37 -0600
Subject: [IronPython] More discussion of the IronPython license
In-Reply-To: <695D7C410F74A644B5335E47FB73E17E038996BA@RED-MSG-52.redmond.corp.microsoft.com>
Message-ID: <20050405005241.D1FF284D39@che.dreamhost.com>

> from: Jim Hugunin
> 
> I know that I've been very quiet with answering questions 
> about the license used for IronPython.  This is primarily 
> because I'm not the right person to be addressing these 
> questions.  Jason Matusow, MS's director of shared source, 
> has been blogging about this license over the past week and 
> now has some more answers to common questions about the 
> license being used for IronPython up here:
> 
> http://blogs.msdn.com/jasonmatusow/archive/2005/04/04/405346.aspx
> 
> If you have concerns or questions about the license, you 
> should take a look at what Jason has to say and feel free to 
> send him your comments as well.

Just so that this sentiment doesn't get lost in the noise, let me say a loud
*THANK YOU* both to Jim and to Microsoft for first making this possible at
all, and for continuing to support the effort on a noble cause.  I've
studied many open source licenses, and personally I'm thankful that not
everyone marches to the GPL drum.

Dave G.




From mahs at telcopartners.com  Tue Apr  5 03:51:48 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Mon, 04 Apr 2005 18:51:48 -0700
Subject: [IronPython] Re: CPython's test_builtin results summary
In-Reply-To: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7FAA@df-chewy-msg.exchange.corp.microsoft.com>
References: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7FAA@df-chewy-msg.exchange.corp.microsoft.com>
Message-ID: <d2sqts$lsv$1@sea.gmane.org>

Martin Maly wrote:
> Hi Michael,
> 
...
> 
> I can see your emails just came through... Since you have spent the time
> and modified the tests so that they can readily run on IronPython,
> filing the actual bugs is not necessary because we can simply run your
> modified test and fix whatever the test indicates failure on. It will
> save you the time needed to file the bugs and it will save us the time
> having to deal with the bugs one by one rather than just run long repro
> and proceed as tests fail.
> 
Thanks, that's what I hoped you would say ;-)

FWIW, I started out by trying to run some existing algorithmic modules (i.e., 
not dependent on external modules), and quickly ran into various problems with 
builtins.  That was one of my reasons for taking the tack I did.


> At this early stage there are still many useful programs that people can
> build with IronPython 0.7. These are newly written programs using .NET
> libraries rather than existing Python programs. Right now we're most
> interested in capturing the problems from these early users both to
> understand issues with .NET integration and to fix blocking issues as
> quickly as possible so they can get on with writing code. This is a new
> set of issues where we need to build experience and can't rely on the
> existing test suites to cover us as we push towards 1.0.

OK

Michael










From mahs at telcopartners.com  Tue Apr  5 03:52:06 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Mon, 04 Apr 2005 18:52:06 -0700
Subject: [IronPython] Re: CPython's test_builtin results summary
In-Reply-To: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7FAA@df-chewy-msg.exchange.corp.microsoft.com>
References: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7FAA@df-chewy-msg.exchange.corp.microsoft.com>
Message-ID: <d2sque$lua$1@sea.gmane.org>

Martin Maly wrote:
> Hi Michael,
> 
...
> 
> I can see your emails just came through... Since you have spent the time
> and modified the tests so that they can readily run on IronPython,
> filing the actual bugs is not necessary because we can simply run your
> modified test and fix whatever the test indicates failure on. It will
> save you the time needed to file the bugs and it will save us the time
> having to deal with the bugs one by one rather than just run long repro
> and proceed as tests fail.
> 
Thanks, that's what I hoped you would say ;-)

FWIW, I started out by trying to run some existing algorithmic modules (i.e., 
not dependent on external modules), and quickly ran into various problems with 
builtins.  That was one of my reasons for taking the tack I did.


> At this early stage there are still many useful programs that people can
> build with IronPython 0.7. These are newly written programs using .NET
> libraries rather than existing Python programs. Right now we're most
> interested in capturing the problems from these early users both to
> understand issues with .NET integration and to fix blocking issues as
> quickly as possible so they can get on with writing code. This is a new
> set of issues where we need to build experience and can't rely on the
> existing test suites to cover us as we push towards 1.0.

OK

Michael










From trilokgk at gmail.com  Tue Apr  5 09:30:29 2005
From: trilokgk at gmail.com (Trilok Khairnar)
Date: Tue, 5 Apr 2005 13:00:29 +0530
Subject: [IronPython] Renaming IronPythonConsole
In-Reply-To: <6c60e8e6050331151520e00aec@mail.gmail.com>
References: <21f1e270050331143932137355@mail.gmail.com>
	<20050331224632.E32E284D49@che.dreamhost.com>
	<6c60e8e6050331151520e00aec@mail.gmail.com>
Message-ID: <18593812050405003059787ad1@mail.gmail.com>

+1 for fepy

I think it would be good to have a web-based poll (using NSurvey :-) )
and close this topic.


On Apr 1, 2005 4:45 AM, Richard Caetano <caetano at gmail.com> wrote:
> +1 for ironpy
> 
> On Fri, 1 Apr 2005 00:46:35 +0200, R.R. Sprinkhuizen
> <reginald at rare-it.com> wrote:
> >
> >
> > > Personally, I like ironpy.  I too was a little late in voting ;-)
> >
> > Count me in. I don't like fepy.
> >
> > > I'm happy we're getting new releases at all, frankly.
> >
> > Me too, but very unhappy that it needs 2.0. Can't there be a 1.1 and a 2.0
> > version?
> >
> > Cheers!
> > Reginald
> >
> >
> >  ________________________________
> >
> > SwitchBL8's gebazel
> >
> >
> >
> >
> > _______________________________________________
> > users-ironpython.com mailing list
> > users-ironpython.com at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> >
> >
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From indigo at bitglue.com  Tue Apr  5 14:03:31 2005
From: indigo at bitglue.com (Phil Frost)
Date: Tue, 5 Apr 2005 08:03:31 -0400
Subject: [IronPython] More discussion of the IronPython license
In-Reply-To: <695D7C410F74A644B5335E47FB73E17E038996BA@RED-MSG-52.redmond.corp.microsoft.com>
References: <695D7C410F74A644B5335E47FB73E17E038996BA@RED-MSG-52.redmond.corp.microsoft.com>
Message-ID: <20050405120331.GA7332@unununium.org>

On Mon, Apr 04, 2005 at 04:17:25PM -0700, Jim Hugunin wrote:
> I know that I've been very quiet with answering questions about the
> license used for IronPython.  This is primarily because I'm not the
> right person to be addressing these questions.  Jason Matusow, MS's
> director of shared source, has been blogging about this license over the
> past week and now has some more answers to common questions about the
> license being used for IronPython up here:
> 
> http://blogs.msdn.com/jasonmatusow/archive/2005/04/04/405346.aspx
> 
> If you have concerns or questions about the license, you should take a
> look at what Jason has to say and feel free to send him your comments as
> well.
> 
> Thanks - Jim

"We apologize, but an unknown error has occured in the forums.

This error has been logged."

wooo unknown errors!


From innesm at gmail.com  Tue Apr  5 16:54:38 2005
From: innesm at gmail.com (Innes MacKenzie)
Date: Tue, 5 Apr 2005 15:54:38 +0100
Subject: [IronPython] More discussion of the IronPython license
In-Reply-To: <20050405120331.GA7332@unununium.org>
References: <695D7C410F74A644B5335E47FB73E17E038996BA@RED-MSG-52.redmond.corp.microsoft.com>
	<20050405120331.GA7332@unununium.org>
Message-ID: <db7def6705040507547f81d06d@mail.gmail.com>

On Apr 5, 2005 1:03 PM, Phil Frost <indigo at bitglue.com> wrote:
> On Mon, Apr 04, 2005 at 04:17:25PM -0700, Jim Hugunin wrote:
> > http://blogs.msdn.com/jasonmatusow/archive/2005/04/04/405346.aspx

> "We apologize, but an unknown error has occured in the forums.
> 
> This error has been logged."
> 
> wooo unknown errors!

http://blogs.msdn.com/jasonmatusow/


From miuler at gmail.com  Wed Apr  6 07:01:21 2005
From: miuler at gmail.com (Hector Miuler Malpica Gallegos)
Date: Wed, 06 Apr 2005 00:01:21 -0500
Subject: [IronPython] IronPython + Npgsql
In-Reply-To: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7F58@df-chewy-msg.exchange.corp.microsoft.com>
References: <1E1FC9DA1767ED44872F4E17AC17E8F7019D7F58@df-chewy-msg.exchange.corp.microsoft.com>
Message-ID: <1112763681.9837.0.camel@localhost>

thanks, just the problem in indexing, in C# Resultado[1], in python I
have not been able,  solution:
Resultado.GetValue(1)

On lun, 2005-04-04 at 15:44 -0700, Martin Maly wrote:
> There is known issue with indexing where IronPython may have trouble finding the right indexer.
> This may be what you are hitting. I am not familiar with Npgsql, but on .Net classes there is
> often property that you can access directly and bypass the access by index.
> 
> Martin
> 
> > On Monday, April 04, 2005 12:32 PM Hector Miuler Malpica Gallegos Wrote:
> > Sent: Monday, April 04, 2005 12:32 PM
> > To: users-ironpython.com at lists.ironpython.com
> > Subject: [IronPython] IronPython + Npgsql
> 
> > Hello friends, I am using Npgsql, from IronPython functions, but I do not be able
> > optener data of the results, some idea of as I can do it?  
> 
> 
> > Conn = Npgsql.NpgsqlConnection("Server=127.0.0.1;Port=5432;User Id=miuler;Password=miuler;Database=basecsd;")
> > Conn.Open()
> 
> > Cmd = Npgsql.NpgsqlCommand("select version()", Conn)
> > Resultado = Cmd.ExecuteScalar()
> > print Resultado 
> > Cmd = Npgsql.NpgsqlCommand("select * from clientes;", Conn)
> > Resultado = Cmd.ExecuteReader()
> > while (Resultado.Read()):
> > print Resultado
> > #~ print Resultado[1] # <-- error
> > Conn.Close()
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From mailinglist.account at gmail.com  Wed Apr  6 12:06:50 2005
From: mailinglist.account at gmail.com (Anthony Tarlano)
Date: Wed, 6 Apr 2005 12:06:50 +0200
Subject: [IronPython] Converting an script to exe or dll
Message-ID: <f2b57319050406030615723403@mail.gmail.com>

Hello,

Does anyone know how I can use IronPython to convert a .py script to a
PE (exe or dll) assembly?

Thanks,

Anthony


From sriramk at gmail.com  Wed Apr  6 14:23:57 2005
From: sriramk at gmail.com (Sriram Krishnan)
Date: Wed, 6 Apr 2005 17:53:57 +0530
Subject: [IronPython] Converting an script to exe or dll
In-Reply-To: <f2b57319050406030615723403@mail.gmail.com>
Message-ID: <4253d4e2.40f5a4f3.4de1.ffff8b35@mx.gmail.com>

Anthony Tarlano wrote:
> Hello,
> 
> Does anyone know how I can use IronPython to convert a .py script to
> a PE (exe or dll) assembly? 
> 

I don't think you can do that in the current version of IronPython. But I
remember Jim saying that a compiler was on the todo list

Sriram



From zanesdad at bellsouth.net  Wed Apr  6 18:57:15 2005
From: zanesdad at bellsouth.net (Jeremy Jones)
Date: Wed, 06 Apr 2005 12:57:15 -0400
Subject: [IronPython] Converting an script to exe or dll
In-Reply-To: <4253d4e2.40f5a4f3.4de1.ffff8b35@mx.gmail.com>
References: <4253d4e2.40f5a4f3.4de1.ffff8b35@mx.gmail.com>
Message-ID: <425414EB.6060805@bellsouth.net>

Sriram Krishnan wrote:

>Anthony Tarlano wrote:
>  
>
>>Hello,
>>
>>Does anyone know how I can use IronPython to convert a .py script to
>>a PE (exe or dll) assembly? 
>>
>>    
>>
>
>I don't think you can do that in the current version of IronPython. But I
>remember Jim saying that a compiler was on the todo list
>
>Sriram
>
>_______________________________________________
>users-ironpython.com mailing list
>users-ironpython.com at lists.ironpython.com
>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>  
>
Had to download FePy 0.7.1 and the .NET framework for my XP machine, but 
it *will* compile a script down to a .exe.  You just have to run the 
IronPythonConsole on it.  I put a simple script in my IronPython\bin 
directory ran, IronPythonConsole.exe on it, and ran the resulting 
__main__.exe directly:

C:\downloads\fepy\IronPython-0.7.1\bin>dir
 Volume in drive C has no label.
 Volume Serial Number is 3CCB-1F43

 Directory of C:\downloads\fepy\IronPython-0.7.1\bin

04/06/2005  12:53 PM    <DIR>          .
04/06/2005  12:53 PM    <DIR>          ..
04/06/2005  09:35 AM                48 hello.py
04/01/2005  10:46 PM            24,576 IronMath.dll
04/01/2005  10:46 PM           233,472 IronPython.dll
04/01/2005  10:46 PM            16,384 IronPythonConsole.exe
04/01/2005  01:07 PM               249 IronPythonConsole.exe.config
               5 File(s)        274,729 bytes
               2 Dir(s)  31,647,444,992 bytes free

C:\downloads\fepy\IronPython-0.7.1\bin>type hello.py
#!/usr/bin/env python


print "Hello from FePy"
C:\downloads\fepy\IronPython-0.7.1\bin>IronPythonConsole.exe hello.py
Hello from FePy

C:\downloads\fepy\IronPython-0.7.1\bin>dir
 Volume in drive C has no label.
 Volume Serial Number is 3CCB-1F43

 Directory of C:\downloads\fepy\IronPython-0.7.1\bin

04/06/2005  12:54 PM    <DIR>          .
04/06/2005  12:54 PM    <DIR>          ..
04/06/2005  09:35 AM                48 hello.py
04/01/2005  10:46 PM            24,576 IronMath.dll
04/01/2005  10:46 PM           233,472 IronPython.dll
04/01/2005  10:46 PM            16,384 IronPythonConsole.exe
04/01/2005  01:07 PM               249 IronPythonConsole.exe.config
04/06/2005  12:54 PM             3,584 snippets.dll
04/06/2005  12:54 PM            13,824 snippets.pdb
04/06/2005  12:54 PM             2,048 __main__.exe
04/06/2005  12:54 PM            11,776 __main__.pdb
               9 File(s)        305,961 bytes
               2 Dir(s)  31,647,404,032 bytes free
C:\downloads\fepy\IronPython-0.7.1\bin>__main__.exe
Hello from FePy

C:\downloads\fepy\IronPython-0.7.1\bin>

Jeremy Jones
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050406/05e60fdb/attachment.html>

From sriramk at gmail.com  Wed Apr  6 19:01:50 2005
From: sriramk at gmail.com (Sriram Krishnan)
Date: Wed, 6 Apr 2005 22:31:50 +0530
Subject: [IronPython] Converting an script to exe or dll
In-Reply-To: <425414EB.6060805@bellsouth.net>
Message-ID: <42541604.4ced4c7b.0ba2.ffffdb6d@mx.gmail.com>

 >Had to download FePy 0.7.1 and the .NET framework for my XP machine, but
it *will* compile a script down to a .exe.  
>You just have to run the IronPythonConsole on it.  I put a simple script in
my IronPython\bin directory ran, 
>IronPythonConsole.exe on it, and ran the resulting __main__.exe directly:

Didn't notice this. Cool!

Sriram



From scott.hatfield at usis.com  Wed Apr  6 19:10:17 2005
From: scott.hatfield at usis.com (Scott Hatfield)
Date: Wed, 6 Apr 2005 13:10:17 -0400
Subject: [IronPython] Converting an script to exe or dll
Message-ID: <6B82D5384051654B8FF6336B126BB7F407F91D13@gcexc2.usiscentral.com>

That's great!

Now can you have it run without a console?

Scott

-----Original Message-----
From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Sriram Krishnan
Sent: Wednesday, April 06, 2005 1:02 PM
To: 'Discussion of IronPython'
Subject: RE: [IronPython] Converting an script to exe or dll

 >Had to download FePy 0.7.1 and the .NET framework for my XP machine,
but
it *will* compile a script down to a .exe.  
>You just have to run the IronPythonConsole on it.  I put a simple
script in
my IronPython\bin directory ran, 
>IronPythonConsole.exe on it, and ran the resulting __main__.exe
directly:

Didn't notice this. Cool!

Sriram

_______________________________________________
users-ironpython.com mailing list
users-ironpython.com at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com




From zanesdad at bellsouth.net  Wed Apr  6 19:32:45 2005
From: zanesdad at bellsouth.net (Jeremy Jones)
Date: Wed, 06 Apr 2005 13:32:45 -0400
Subject: [IronPython] Converting an script to exe or dll
In-Reply-To: <6B82D5384051654B8FF6336B126BB7F407F91D13@gcexc2.usiscentral.com>
References: <6B82D5384051654B8FF6336B126BB7F407F91D13@gcexc2.usiscentral.com>
Message-ID: <42541D3D.40205@bellsouth.net>

Scott Hatfield wrote:

>That's great!
>
>Now can you have it run without a console?
>  
>

How do you mean?  I put a sleep(5) in there so that I could see the 
output when I double clicked on __main__.exe from Windows Explorer, but 
a console still popped up.  I think there are probably ways to disable 
this, but I'm by no means a Windows expert.  I'm really looking forward 
to Mono being able to fully support FePy > 0.7.

Jeremy


From jimhug at microsoft.com  Wed Apr  6 19:43:35 2005
From: jimhug at microsoft.com (Jim Hugunin)
Date: Wed, 6 Apr 2005 10:43:35 -0700
Subject: [IronPython] IronPython + Npgsql
Message-ID: <695D7C410F74A644B5335E47FB73E17E038D4C7F@RED-MSG-52.redmond.corp.microsoft.com>

Hector Miuler Malpica Gallegos wrote:
> thanks, just the problem in indexing, in C# Resultado[1], in python I
> have not been able,  solution:
> Resultado.GetValue(1)

This should work as easily in IronPython as in C#.  In general, if
things are more awkward in IronPython than in C# you should first assume
that it's a bug in IronPython and let us know.  Solutions like
Resultado.GetValue are useful workarounds and good to share with users
but not our end goal.

I know that IronPython 0.6 didn't handle index overloading correctly;
however, we fixed most of these cases in 0.7 and later.  Are you using
IronPython 0.7 or later?

If you are using 0.7, then could you add this test to your sample code
to see what Properties are on your Resultado object?

from System import Type
resultadoType = type(Resultado) #Could also import this type directly
for p in Type.GetProperties(resultadoType):
    print p

This will print all of the CLR properties on your Resultado object.  I'd
be very interested in the results of this to see if there's a hole in
our indexing code.

Thanks - Jim


From jimhug at microsoft.com  Wed Apr  6 19:53:42 2005
From: jimhug at microsoft.com (Jim Hugunin)
Date: Wed, 6 Apr 2005 10:53:42 -0700
Subject: [IronPython] Converting an script to exe or dll
Message-ID: <695D7C410F74A644B5335E47FB73E17E038D4CA6@RED-MSG-52.redmond.corp.microsoft.com>

Jeremy Jones wrote:
> Scott Hatfield wrote:
> 
> >That's great!
> >
> >Now can you have it run without a console?
> >
> How do you mean?  I put a sleep(5) in there so that I could see the
> output when I double clicked on __main__.exe from Windows Explorer,
but
> a console still popped up.  I think there are probably ways to disable

I'm glad people like the ability to run __main__; however, I should let
you know about a few <wink>minor limitations</wink>.

1. This only works for Python programs that fit into a single file (huge
limitation).
2. The binding to IronPython.dll can be a little fragile.
3. You can only get programs with a console.
4. The libraries produced aren't easily used from other CLR languages.
5. Your exe can only be called __main__ (although rename will work just
fine)

The plan is to remove all of these limitations by 1.0.

The console issue should be fixed both here and we should provide a
version of IronPythonConsole (whatever it's final name is) that doesn't
launch a console just like pythonw does.  This isn't a priority right
now because of the early alpha status of the project.  I like to always
have a console around when developing/debugging Python code because at
the very least it's a good place for unhandled exceptions to be shown.
Removing the console to me is part of the final polish of an application
and I don't think that IronPython is ready for that final polish stage
yet.

If you're finding the console to be the major blocker to using
IronPython today, please file a bug (or email ironpy at microsoft.com) and
we can think about raising the priority of this task. 

Thanks - Jim 


From miuler at gmail.com  Wed Apr  6 22:47:10 2005
From: miuler at gmail.com (Hector Miuler Malpica Gallegos)
Date: Wed, 06 Apr 2005 15:47:10 -0500
Subject: [IronPython] IronPython/Gtk#/TreeView ??
Message-ID: <1112820430.9837.11.camel@localhost>

Hi, how I can use TreeView in IronPython?

C#
TreeStore  StoreReportesDiario = new TreeStore (typeof (string), typeof
(string));

Python??
StoreReportesDiario = Gtk.TreeStore()
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050406/0b3311af/attachment.html>

From miuler at gmail.com  Wed Apr  6 23:29:58 2005
From: miuler at gmail.com (Hector Miuler Malpica Gallegos)
Date: Wed, 06 Apr 2005 16:29:58 -0500
Subject: [IronPython] IronPython + Npgsql
In-Reply-To: <695D7C410F74A644B5335E47FB73E17E038D4C7F@RED-MSG-52.redmond.corp.microsoft.com>
References: <695D7C410F74A644B5335E47FB73E17E038D4C7F@RED-MSG-52.redmond.corp.microsoft.com>
Message-ID: <1112822998.9837.17.camel@localhost>

Functions in IronPython 0.6?  

I will have to wait for that IronPython0.7 function with monkey


>>> for p in Type.GetProperties(type("string")):
...  print p
...
System.Exception: bad args to this method <method# GetProperties on
System.Type>
in <0x0019c> IronPython.Objects.ReflectedMethodBase:Call (object[])
in <0x001ef> IronPython.Objects.Ops:Call (object,object)
in <0x0009b> input_25:Run (IronPython.Objects.Frame)
in <0x001c5> IronPythonConsole.IronPython:DoInteractive ()



On mi?, 2005-04-06 at 10:43 -0700, Jim Hugunin wrote:

> Hector Miuler Malpica Gallegos wrote:
> > thanks, just the problem in indexing, in C# Resultado[1], in python I
> > have not been able,  solution:
> > Resultado.GetValue(1)
> 
> This should work as easily in IronPython as in C#.  In general, if
> things are more awkward in IronPython than in C# you should first assume
> that it's a bug in IronPython and let us know.  Solutions like
> Resultado.GetValue are useful workarounds and good to share with users
> but not our end goal.
> 
> I know that IronPython 0.6 didn't handle index overloading correctly;
> however, we fixed most of these cases in 0.7 and later.  Are you using
> IronPython 0.7 or later?
> 
> If you are using 0.7, then could you add this test to your sample code
> to see what Properties are on your Resultado object?
> 
> from System import Type
> resultadoType = type(Resultado) #Could also import this type directly
> for p in Type.GetProperties(resultadoType):
>     print p
> 
> This will print all of the CLR properties on your Resultado object.  I'd
> be very interested in the results of this to see if there's a hole in
> our indexing code.
> 
> Thanks - Jim
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050406/a61fa8aa/attachment.html>

From jimhug at microsoft.com  Thu Apr  7 01:49:03 2005
From: jimhug at microsoft.com (Jim Hugunin)
Date: Wed, 6 Apr 2005 16:49:03 -0700
Subject: [IronPython] CPython access
Message-ID: <695D7C410F74A644B5335E47FB73E17E0391096E@RED-MSG-52.redmond.corp.microsoft.com>

Timothy Fitz wrote:
> Where there be any plans for allowing IronPython to work with an
> instance of CPython directly? There are quite a few instances where
> this would be extremely handy (SWIG-wrapped libraries such as
> wxPython, or tightly optimized pieces that deal directly with
> operating system concepts such as Twisted reactors where rewriting in
> IronPython or converting may not be trivial enough)

There are several options for supporting existing C-based Python
modules.

1. Rewrite the modules in C# using .NET libraries. This will produce the
smallest and best integrated modules at the end of the day, but requires
substantial work per module. This is what has been done for Jython.  For
modules with deep integration with the runtime, like __builtins__, sys,
gc, thread there isn't any other good answer.  Other modules like
socket, re, xml, etc. have close counterparts in the .NET space and it's
very tempting to provide these as small adapters over the existing
libraries. For the large external libraries like wxPython, opengl, etc.
there is often a .NET wrapper already provided that could make it simple
once again to provide a small adapter to match the Python module's API. 

2. Build a bridge like you suggest using the existing CPython dll.
There's a substantial amount of upfront work involved in writing the
bridge, but once it was done it should be easy (no work at all
hopefully) to bring in existing Python modules to IronPython.  This
would be great from the perspective of making tons of existing Python
modules just work in IronPython, but there are some significant
drawbacks.

The bridge would need to translate between CPython and IronPython
objects and this would never be a completely seamless translation.
There would be a considerable per-call performance overhead so that this
would probably be a poor choice for APIs with small functions that get
called a lot where perf matters, Numeric comes to mind.  The fact that
you now have two separate memory managers means you can wind up with
uncollectible cycles, but that might be rare in practice.  The bridge
would also give up the advantages of a unified cross-language debugger,
the ability to have purely managed verifiable .NET assemblies to run in
secure contexts, and some other benefits of tight integration with the
platform.  On the CPython side, modules that used deep engine features
would be hard/impossible to bridge so there would be a group of modules
that couldn't work here.

3. A crazy idea is to arrange to port the modules to managed C++
combined with a fake set of include files that makes the modules really
link with IronPython rather than CPython. In theory, this could let the
modules work well with IronPython with only a recompile required. This
could be really cool if it worked out, but I'm the least confident that
this option is truly possible.

Thanks - Jim


From jimhug at microsoft.com  Thu Apr  7 01:54:29 2005
From: jimhug at microsoft.com (Jim Hugunin)
Date: Wed, 6 Apr 2005 16:54:29 -0700
Subject: [IronPython] Generics support in IronPython
Message-ID: <695D7C410F74A644B5335E47FB73E17E0391097E@RED-MSG-52.redmond.corp.microsoft.com>

The declaration of Python classes with generic type parameters is not supported today, and is not currently on my todo list for 1.0.  I see generic types as vitally important in static languages like C#, but much less important for dynamic languages like Python.  It's important for IronPython to be able to use these types, and even create new concrete instances like shown below, to interoperate as well as possible with .NET libraries.  If I saw a strong case for why Python programmers should want to create new generic types then we might look into this sooner.

-Jim

________________________________________
From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer
Sent: Friday, April 01, 2005 6:39 PM
To: Discussion of IronPython
Subject: RE: [IronPython] Generics support in IronPython

So that shows consumption -- is creation supported?
?
Very cool

________________________________________
From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Jim Hugunin
Sent: Fri 4/1/2005 5:17 PM
To: Martin Smith; users-ironpython.com at lists.ironpython.com
Subject: RE: [IronPython] Generics support in IronPython
Martin Smith wrote:
> Will IronPython support generics?

Here's the short answer to your question:

>>> from System.Collections.Generic import *
>>> l = List[str]()
>>> l.Add('hi')
>>> list(l)
['hi']
>>> l.Add(42)
System.Exception: bad args to this method <method# Add on
<snip>


From brian at zope.com  Thu Apr  7 02:44:01 2005
From: brian at zope.com (Brian Lloyd)
Date: Wed, 6 Apr 2005 20:44:01 -0400
Subject: [IronPython] CPython access
In-Reply-To: <695D7C410F74A644B5335E47FB73E17E0391096E@RED-MSG-52.redmond.corp.microsoft.com>
Message-ID: <20050407004403.B73373B8038@smtp.zope.com>

> 3. A crazy idea is to arrange to port the modules to managed C++
> combined with a fake set of include files that makes the 
> modules really
> link with IronPython rather than CPython. In theory, this 
> could let the
> modules work well with IronPython with only a recompile required. This
> could be really cool if it worked out, but I'm the least 
> confident that this option is truly possible.

I'll see your crazy idea, and raise you a ridiculously insane 
idea ;) Having done some of them, I now have a fair amount of 
respect for the crazy things that you _can_ do with the CLR ;)

At a purely theoretical technical level, it _is_ possible to 
implement a 'python2X.dll' and provide unmanaged exports, where 
the implementation would work with the IP runtime.

Of course, you would need to implement all of the CPython API 
on top of the IP runtime in a sane way for unmanaged consumers, 
but I think in the end the question is one of practicality, not 
technical possibility...

not-volunteering-by-the-way 'ly,

Brian Lloyd        brian at zope.com
V.P. Engineering   540.361.1716              
Zope Corporation   http://www.zope.com 
  



From swaroopch at gmail.com  Thu Apr  7 05:07:42 2005
From: swaroopch at gmail.com (Swaroop C H)
Date: Thu, 7 Apr 2005 08:37:42 +0530
Subject: [IronPython] IronPython/Gtk#/TreeView ??
In-Reply-To: <1112820430.9837.11.camel@localhost>
References: <1112820430.9837.11.camel@localhost>
Message-ID: <351e887105040620076a10a231@mail.gmail.com>

On Apr 7, 2005 2:17 AM, Hector Miuler Malpica Gallegos <miuler at gmail.com> wrote:
>  Hi, how I can use TreeView in IronPython?
>  C#
>  TreeStore  StoreReportesDiario = new TreeStore (typeof (string), typeof
> (string));
>  Python??
>  StoreReportesDiario = Gtk.TreeStore() 

I don't have an answer to your question, but there is an example
application in C# if anybody wants to help out Hector:
http://www.gotmono.com/docs/gnome/bindings/gtk-sharp/treeview.html


-- 
Swaroop C H
Blog: http://www.swaroopch.info
Book: http://www.byteofpython.info


From abubakarm at gmail.com  Thu Apr  7 07:47:42 2005
From: abubakarm at gmail.com (Muhammad Abubakar)
Date: Thu, 7 Apr 2005 10:47:42 +0500
Subject: [IronPython] IronPython/Gtk#/TreeView ??
In-Reply-To: <351e887105040620076a10a231@mail.gmail.com>
References: <1112820430.9837.11.camel@localhost>
	<351e887105040620076a10a231@mail.gmail.com>
Message-ID: <c40f6d350504062247b2710b8@mail.gmail.com>

Hi,
I'm not using the ipython right now, but I did see some win forms
example in the example directory which is the following. Doesnt this
help u?

<code>
#####################################################################################
#  
#  Copyright (c) Microsoft Corporation. All rights reserved.
# 
#  This source code is subject to terms and conditions of the Shared
Source License
#  for IronPython. A copy of the license can be found in the License.html file
#  at the root of this distribution. If you can not locate the Shared
Source License
#  for IronPython, please send an email to ironpy at microsoft.com.
#  By using this source code in any fashion, you are agreeing to be bound by
#  the terms of the Shared Source License for IronPython.
# 
#  You must not remove this notice, or any other, from this software.
# 
######################################################################################

import sys
sys.LoadAssemblyByName("System.Drawing")
sys.LoadAssemblyByName("System.Windows.Forms")

from System.Windows.Forms import *
from System.Drawing import *

f = Form(Text="Windows fun with IronPython", HelpButton=True,
         MinimizeBox=False, MaximizeBox=False)

f.FormBorderStyle = FormBorderStyle.FixedDialog
f.StartPosition = FormStartPosition.CenterScreen

b1 = Button(Text="Say Something", Location=Point(30,30), Size=Size(200,30))

def push(data, event):
    l = Label(Text="IronPython Lives!", ForeColor=Color.Red)
    l.Location = Point(30, 50+f.Controls.Count*25)
    f.Controls.Add(l)

b1.Click += push

f.Controls.Add(b1)
f.ShowDialog()

</code>
Ab. 

On Apr 7, 2005 8:07 AM, Swaroop C H <swaroopch at gmail.com> wrote:
> On Apr 7, 2005 2:17 AM, Hector Miuler Malpica Gallegos <miuler at gmail.com> wrote:
> >  Hi, how I can use TreeView in IronPython?
> >  C#
> >  TreeStore  StoreReportesDiario = new TreeStore (typeof (string), typeof
> > (string));
> >  Python??
> >  StoreReportesDiario = Gtk.TreeStore()
> 
> I don't have an answer to your question, but there is an example
> application in C# if anybody wants to help out Hector:
> http://www.gotmono.com/docs/gnome/bindings/gtk-sharp/treeview.html
> 
> --
> Swaroop C H
> Blog: http://www.swaroopch.info
> Book: http://www.byteofpython.info
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From scott.hatfield at usis.com  Thu Apr  7 15:29:22 2005
From: scott.hatfield at usis.com (Scott Hatfield)
Date: Thu, 7 Apr 2005 09:29:22 -0400
Subject: [IronPython] IronPython/Gtk#/TreeView ??
Message-ID: <6B82D5384051654B8FF6336B126BB7F407F91D1A@gcexc2.usiscentral.com>

# Here's a trivial example 

 

import sys

sys.LoadAssemblyByName("System.Drawing")

sys.LoadAssemblyByName("System.Windows.Forms")

 

from System.Windows.Forms import *

from System.Drawing import *

 

f = Form(Text="Trivial TreeView Example")

f.FormBorderStyle = FormBorderStyle.FixedDialog

f.StartPosition = FormStartPosition.CenterScreen

 

treeView = TreeView(Location=Point(30,30), Size=Size(200,200))

 

node = TreeNode("root")

node.Nodes.Add(TreeNode("child1"))

node.Nodes.Add(TreeNode("child2"))

node.Nodes.Add(TreeNode("child3"))

 

treeView.Nodes.Insert(0,node)

 

f.Controls.Add(treeView)

f.ShowDialog()

 

  _____  

From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Hector Miuler Malpica Gallegos
Sent: Wednesday, April 06, 2005 4:47 PM
To: users-ironpython.com at lists.ironpython.com
Subject: [IronPython] IronPython/Gtk#/TreeView ??

 

Hi, how I can use TreeView in IronPython?

C#
TreeStore  StoreReportesDiario = new TreeStore (typeof (string), typeof
(string));

Python??
StoreReportesDiario = Gtk.TreeStore() 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050407/d7624ca9/attachment.html>

From jonnyyu at online.sh.cn  Thu Apr  7 17:10:16 2005
From: jonnyyu at online.sh.cn (Ying-Shen)
Date: Thu, 07 Apr 2005 23:10:16 +0800
Subject: [IronPython] Bug Report
Message-ID: <42554D58.3080507@online.sh.cn>

Hi,

I knew GDN bug tracker maybe the right place for this issue, but 
unfortunatelly due to some limitations, I don't have access to that 
site, so I apologize to post it here.

I was playing with IronPython 0.7.1 and want to generate a method list 
for string, basically I'm using the code snippet like below:
 >>> obj = "aaa"
 >>> typeList = [ getattr(obj, method ) for method in dir(obj) ]
the above code works as expected in my python 2.3.3 but fails with error 
msg: System.Reflection.TargetParameterCountException: Parameter count 
mismatch.
<exception stacktrace omitted>

Anyone could verify it and help me submit to GDN, thanks!

Ying-Shen Yu






From martmaly at exchange.microsoft.com  Thu Apr  7 17:33:46 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Thu, 7 Apr 2005 08:33:46 -0700
Subject: [IronPython] Bug Report
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701A6AE93@df-chewy-msg.exchange.corp.microsoft.com>

Hi Ying-Shen,

Reporting the bug like this is completely sufficient. GDN is good place
to enter bugs, but sending email is just as good. Thanks for the report!

Thanks and keep in touch
Martin

> Ying-Shen wrote:
> Subject: [IronPython] Bug Report
> 
> Hi,
> 
> I knew GDN bug tracker maybe the right place for this issue, but
> unfortunatelly due to some limitations, I don't have access to that
> site, so I apologize to post it here.
> 
> I was playing with IronPython 0.7.1 and want to generate a method list
> for string, basically I'm using the code snippet like below:
>  >>> obj = "aaa"
>  >>> typeList = [ getattr(obj, method ) for method in dir(obj) ]
> the above code works as expected in my python 2.3.3 but fails with
error
> msg: System.Reflection.TargetParameterCountException: Parameter count
> mismatch.
> <exception stacktrace omitted>
> 
> Anyone could verify it and help me submit to GDN, thanks!
> 
> Ying-Shen Yu


From alleykat at gmail.com  Thu Apr  7 18:44:53 2005
From: alleykat at gmail.com (Travis Watkins)
Date: Thu, 7 Apr 2005 11:44:53 -0500
Subject: [IronPython] IronPython/Gtk#/TreeView ??
In-Reply-To: <6B82D5384051654B8FF6336B126BB7F407F91D1A@gcexc2.usiscentral.com>
References: <6B82D5384051654B8FF6336B126BB7F407F91D1A@gcexc2.usiscentral.com>
Message-ID: <adca365a0504070944551af647@mail.gmail.com>

I think he was talking about GTK#'s TreeView widget.

On Apr 7, 2005 8:29 AM, Scott Hatfield <scott.hatfield at usis.com> wrote:
>  
>  
> 
> # Here's a trivial example 
> 
>   
> 
> import sys 
> 
> sys.LoadAssemblyByName("System.Drawing") 
> 
> sys.LoadAssemblyByName("System.Windows.Forms") 
> 
>   
> 
> from System.Windows.Forms import * 
> 
> from System.Drawing import * 
> 
>   
> 
> f = Form(Text="Trivial TreeView Example") 
> 
> f.FormBorderStyle = FormBorderStyle.FixedDialog 
> 
> f.StartPosition = FormStartPosition.CenterScreen 
> 
>   
> 
> treeView = TreeView(Location=Point(30,30), Size=Size(200,200)) 
> 
>   
> 
> node = TreeNode("root") 
> 
> node.Nodes.Add(TreeNode("child1")) 
> 
> node.Nodes.Add(TreeNode("child2")) 
> 
> node.Nodes.Add(TreeNode("child3")) 
> 
>   
> 
> treeView.Nodes.Insert(0,node) 
> 
>   
> 
> f.Controls.Add(treeView) 
> 
> f.ShowDialog() 
> 
>   
>  
>  ________________________________
>  
> 
> From: users-ironpython.com-bounces at lists.ironpython.com
> [mailto:users-ironpython.com-bounces at lists.ironpython.com]
> On Behalf Of Hector Miuler Malpica Gallegos
>  Sent: Wednesday, April 06, 2005 4:47 PM
>  To: users-ironpython.com at lists.ironpython.com
>  Subject: [IronPython] IronPython/Gtk#/TreeView ?? 
> 
>   
> 
> Hi, how I can use TreeView in IronPython?
>  
>  C#
>  TreeStore  StoreReportesDiario = new TreeStore (typeof (string), typeof
> (string));
>  
>  Python??
>  StoreReportesDiario = Gtk.TreeStore() 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> 
> 


-- 
--
Travis Watkins
http://www.realistanew.com


From kfarmer at thuban.org  Sat Apr  9 07:26:17 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Fri, 8 Apr 2005 22:26:17 -0700
Subject: [IronPython] Running on Mono
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C136997@nostromo.circle-cross.home>

I'm not sure how complete it is, but I got 0.7.1 to run under Mono 1.1.4
for Win32, without making any changes.
 
IronPython 0.7.1 on .NET 2.0.40607.16
Copyright (c) Microsoft Corporation. All rights reserved.
>>> a = 4
>>> a * "Test"
'TestTestTestTest'
>>>
 
The gui example fails, with an NullReferenceException shortly after
failing to load System.Drawing.ImageFormatConverter, but that shouldn't
necessarily be a surprise.
 
I've taken the liberty of defining both a MONO_HOME and an
IRONPYTHON_HOME, and adding references to each to my PATH variable.  A
added a small batch file patterned off mono.bat:
 
 
 
 
----------
Keith J. Farmer
kfarmer at thuban.org
http://www.thuban.org
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050408/f670312c/attachment.html>

From kfarmer at thuban.org  Sat Apr  9 07:27:37 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Fri, 8 Apr 2005 22:27:37 -0700
Subject: [IronPython] RE: Running on Mono
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C136998@nostromo.circle-cross.home>

Bloody mis-sends.
 
Batch file is:
 
@ECHO OFF
SETLOCAL
mono "%IRONPYTHON_HOME%\IronPythonConsole.exe" %*
ENDLOCAL
 
----------
Keith J. Farmer
kfarmer at thuban.org
http://www.thuban.org
 


________________________________

From: Keith J. Farmer 
Sent: Friday, April 08, 2005 10:26 PM

I'm not sure how complete it is, but I got 0.7.1 to run under Mono 1.1.4
for Win32, without making any changes.
 
IronPython 0.7.1 on .NET 2.0.40607.16
Copyright (c) Microsoft Corporation. All rights reserved.
>>> a = 4
>>> a * "Test"
'TestTestTestTest'
>>>
 
The gui example fails, with an NullReferenceException shortly after
failing to load System.Drawing.ImageFormatConverter, but that shouldn't
necessarily be a surprise.
 
I've taken the liberty of defining both a MONO_HOME and an
IRONPYTHON_HOME, and adding references to each to my PATH variable.  A
added a small batch file patterned off mono.bat:
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050408/c35a9f4b/attachment.html>

From kfarmer at thuban.org  Sat Apr  9 08:10:04 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Fri, 8 Apr 2005 23:10:04 -0700
Subject: [IronPython] Running on Mono
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C136999@nostromo.circle-cross.home>

(Of course everyone realizes I'm just trying to avoid installing 2.0 on
my newly-installed system.. At least until Beta2's release.)
 
The following fails under Mono with a missing CreateDelegate method.  So
close, yet so far...
 
import sys
 
sys.LoadAssemblyByName("System.Windows.Forms")
 
from System.Windows.Forms import *
 
def handler(sender, eventArgs):
    button.Text = "Clicked"
 
f = Form(Text="Test Button Form")
f.StartPosition = FormStartPosition.CenterScreen
f.FormBorderStyle = FormBorderStyle.FixedDialog
 
button = Button(Text="Test")
button.Click += handler    # comment this line out, and you'll have a
form with a useless button
 
f.Controls.Add(button)
 
f.ShowDialog()
 
.....
 
C:\Program Files\IronPython-0.7.1\Examples>fepy testButtonForm.py
#region #line XplatUI Constructor called
 
** (C:\Program Files\IronPython-0.7.1\bin\IronPythonConsole.exe):
WARNING **: Missing method CreateDelegate in assembly C:\Program
Files\IronPython-0.7.1\bin\IronPython.dll, type DynamicMethod
System.NullReferenceException: Object reference not set to an instance
of an object
in (unmanaged) 004111C2
in <0x003e3> IronPython.Objects.Ops:GetDelegate (object,System.Type)
in <0x00024> IronPython.Objects.ReflectedEvent:__iadd__ (object)
in <0x00278> IronPython.Objects.Ops:InPlaceAdd (object,object)
in <0x00251> __main__:init ()
in <0x0007d> IronPython.Hosting.PythonEngine:RunFileInNewModule
(string,string)
in <0x00012> IronPython.Hosting.PythonEngine:RunFileInNewModule (string)
in <0x00047> IronPythonConsole.PythonCommandLine:RunFile
(IronPython.Hosting.PythonEngine,string)
 
----------
Keith J. Farmer
kfarmer at thuban.org
http://www.thuban.org
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050408/7618d93f/attachment.html>

From kfarmer at thuban.org  Sat Apr  9 08:18:00 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Fri, 8 Apr 2005 23:18:00 -0700
Subject: [IronPython] Running on Mono
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C13699A@nostromo.circle-cross.home>

I'm having too much fun...
 
Generics seem to have problems, too.  Given Python's popularity, perhaps
someone at Ximian can take this as something to target.
 
>>> from System.Collections.Generic import *
>>> l = List[str]()
>>> l.Add(0)
System.Exception: bad args to this method <method# Add on
System.Collections.Generic.List`1>
in <0x00074> IronPython.Objects.ReflectedMethodBase:Call (object[])
in <0x001c8> IronPython.Objects.Ops:Call (object,object)
in <0x0005e> input_4:Run (IronPython.Objects.Frame)
in <0x0023f> IronPython.Hosting.PythonEngine:DoOneInteractive
(IronPython.Objects.Frame)
in <0x0003f> IronPython.Hosting.PythonEngine:RunInteractive ()
 
>>> l.Add("0")
System.Reflection.TargetException: Unable to invoke an invalid target.
in (unmanaged) 0046101F
in <0x00004> (wrapper managed-to-native)
System.Reflection.MonoMethod:InternalInvoke (object,object[])
in <0x00059> System.Reflection.MonoMethod:Invoke
(object,System.Reflection.BindingFlags,System.Reflection.Binder,object[]
,System.Globalization.CultureInfo)
 
----------
Keith J. Farmer
kfarmer at thuban.org
http://www.thuban.org
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050408/544c0fd2/attachment.html>

From MichaelNedzelsky at yandex.ru  Sat Apr  9 10:07:50 2005
From: MichaelNedzelsky at yandex.ru (Michael)
Date: Sat, 9 Apr 2005 12:07:50 +0400
Subject: [IronPython] Running on Mono under Linux
In-Reply-To: <C02467D265F3F64E87DED53F9C3DE29C13699A@nostromo.circle-cross.home>
References: <C02467D265F3F64E87DED53F9C3DE29C13699A@nostromo.circle-cross.home>
Message-ID: <200504091207.50121.MichaelNedzelsky@yandex.ru>

On Saturday 09 April 2005 10:18, Keith J. Farmer wrote:
I just install mono 1.1.6 on Mandrake Linux 9.2 and try 
-------------------------------------
mono IronPythonConsole.exe
-------------------------------------

It output:
--------------------------
The assembly mscorlib.dll was not found or could not be loaded.
It should be installed in the '/usr/local/lib/mono/2.0/mscorlib.dll' 
directory.
--------------------------

I found mscorlib.dll in '/usr/local/lib/mono/1.0' and make a link to it.
ln -s /usr/local/lib/mono/1.0 /usr/local/lib/mono/2.0

And now I get:

-------------------------------------------------------
** (IronPythonConsole.exe:31454): WARNING **: Could not find assembly System, 
references from /home/michael/IronPython-0.7.1/bin/IronPython.dll 
(assemblyref_index=1)
     Major/Minor: 2,0
     Build:       3600,0
     Token:       b77a5c561934e089
System error: No such file or directory
-------------------------------------------------------

After all, I try compile from sources with makefile:

--------------------------------------------------------
IronPython/AST/AssemblyGen.cs(129) error CS0246: Cannot find type 
'DynamicMethod'
IronPython/AST/CodeGen.cs(562) error CS0246: Cannot find type 'DynamicMethod'
IronPython/AST/CodeGen.cs(574) error CS0246: Cannot find type 'DynamicMethod'
IronPython/AST/CodeGen.cs(582) error CS0246: Cannot find type 'DynamicMethod'
IronPython/AST/Namespace.cs(100) warning CS0219: The variable 'c' is assigned 
but its value is never used
IronPython/AST/SnippetMaker.cs(45) warning CS0219: The variable 'cb' is 
assigned but its value is never used
IronPython/Hosting/PythonEngine.cs(51) warning CS0219: The variable 'o' is 
assigned but its value is never used

Unhandled Exception: System.Exception:
--------------------------------------------------------

So it doesn't work or compile on Linux.

Michael



From kfarmer at thuban.org  Sat Apr  9 10:17:34 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Sat, 9 Apr 2005 01:17:34 -0700
Subject: [IronPython] Running on Mono under Linux
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C13699B@nostromo.circle-cross.home>

As I recall, I didn't try compiling IP using Mono.  I compiled using the
2.0 installation on a machine at work, then copied the assemblies to
this machine. 

----------
Keith J. Farmer
kfarmer at thuban.org
http://www.thuban.org

-----Original Message-----
From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Michael
Sent: Saturday, April 09, 2005 1:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Running on Mono under Linux

So it doesn't work or compile on Linux.


From kfarmer at thuban.org  Sat Apr  9 12:09:58 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Sat, 9 Apr 2005 03:09:58 -0700
Subject: [IronPython] Error with non-jagged array?
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C13699D@nostromo.circle-cross.home>

Caveat:  I ran this using Mono, so I'm not sure if it's really a problem
with Mono, or a bug in IronPython.  It looks like there are some
problems with arrays, but someone with a Win32 version should check
this.

The following uses Mapack, downloadable from Lutz Roeder's site.

Intended usage from C# would be:

	Matrix A = new Matrix(3, 3);
	A[0,0] = 2.0; A[0,1] = 1.0; A[0,2] = 2.0;
	A[1,0] = 1.0; A[1,1] = 4.0; A[1,2] = 0.0;
	A[2,0] = 2.0; A[2,1] = 0.0; A[2,2] = 8.0;

----------
Keith J. Farmer
kfarmer at thuban.org
http://www.thuban.org

C:\Program Files\IronPython-0.7.1\bin>mono IronPythonConsole.exe
IronPython 0.7.1 on .NET 2.0.40607.16
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import sys
>>> sys.LoadAssemblyFromFile("C:\\Documents and
Settings\\kfarmer\\Desktop\\Mapack\\Build\\Mapack.dll")
>>> from Mapack import *
>>> m = Matrix.Random(3, 3)
>>> m
0.225364771776537 0.31672962862846 0.88264873478685
0.648747126408269 0.137992081762288 0.868301292354381
0.880461812895006 0.061446850682351 0.249342372757076

>>> m.Transpose()
0.225364771776537 0.648747126408269 0.880461812895006
0.31672962862846 0.137992081762288 0.061446850682351
0.88264873478685 0.868301292354381 0.249342372757076

>>> m[0,0]
System.Reflection.TargetParameterCountException: Number of parameter
does not match expected count.
in <0x00111> System.Reflection.Binder:ConvertArgs
(System.Reflection.Binder,object[],System.Reflection.ParameterInfo[],Sys
tem.Globalization.CultureInfo)
in <0x00040> System.Reflection.MonoMethod:Invoke
(object,System.Reflection.BindingFlags,System.Reflection.Binder,object[]
,System.Globalization.CultureInfo)
in <0x00060> System.Reflection.MonoProperty:GetValue
(object,System.Reflection.BindingFlags,System.Reflection.Binder,object[]
,System.Globalization.CultureInfo)
in <0x00017> System.Reflection.PropertyInfo:GetValue (object,object[])
in <0x00070> IronPython.Objects.PythonType:__getitem__ (object,object)
in <0x002ca> IronPython.Objects.Ops:GetIndex (object,object)
in <0x000a4> input_7:Run (IronPython.Objects.Frame)
in <0x0023f> IronPython.Hosting.PythonEngine:DoOneInteractive
(IronPython.Objects.Frame)
in <0x0003f> IronPython.Hosting.PythonEngine:RunInteractive ()

>>> m[0][0]
System.Reflection.TargetParameterCountException: Number of parameter
does not match expected count.
in <0x00111> System.Reflection.Binder:ConvertArgs
(System.Reflection.Binder,object[],System.Reflection.ParameterInfo[],Sys
tem.Globalization.CultureInfo)
in <0x00040> System.Reflection.MonoMethod:Invoke
(object,System.Reflection.BindingFlags,System.Reflection.Binder,object[]
,System.Globalization.CultureInfo)
in <0x00060> System.Reflection.MonoProperty:GetValue
(object,System.Reflection.BindingFlags,System.Reflection.Binder,object[]
,System.Globalization.CultureInfo)
in <0x00017> System.Reflection.PropertyInfo:GetValue (object,object[])
in <0x00070> IronPython.Objects.PythonType:__getitem__ (object,object)
in <0x002ca> IronPython.Objects.Ops:GetIndex (object,object)
in <0x00051> input_8:Run (IronPython.Objects.Frame)
in <0x0023f> IronPython.Hosting.PythonEngine:DoOneInteractive
(IronPython.Objects.Frame)
in <0x0003f> IronPython.Hosting.PythonEngine:RunInteractive ()

>>> m.__dict__
{'Trace': <property# Trace on Matrix>, 'Submatrix': <method# Submatrix
on Mapack.Matrix>, 'GetHashCode': <method# GetHashCode on
System.Object>, 'Diagonal': <method# Diagonal on Mapack.Matrix>,
'Random': <method# Random on Mapack.Matrix>, 'IsSquare': <property#
IsSquare on Matrix>, 'Item': <property# Item on Matrix>, 'Inverse':
<property# Inverse on Matrix>, 'Norm1': <property# Norm1 on Matrix>,
'IsSymmetric': <property# IsSymmetric on Matrix>, 'InfinityNorm':
<property# InfinityNorm on Matrix>, 'Transpose': <method# Transpose on
Mapack.Matrix>, 'ToString': <method# ToString on Mapack.Matrix>, 'Rows':
<property# Rows on Matrix>, '__new__': <method Mapack.Matrix.__new__>,
'GetType': <method# GetType on System.Object>, '__repr__': <built-in
function ReprMethod>, 'FrobeniusNorm': <property# FrobeniusNorm on
Matrix>, 'Solve': <method# Solve on Mapack.Matrix>, 'Columns':
<property# Columns on Matrix>, 'Determinant': <property# Determinant on
Matrix>,'Clone': <method# Clone on Mapack.Matrix>, 'Equals': <method#
Equals on System.Object>}
>>>


From MichaelNedzelsky at yandex.ru  Sat Apr  9 14:32:35 2005
From: MichaelNedzelsky at yandex.ru (Michael)
Date: Sat, 9 Apr 2005 16:32:35 +0400
Subject: [IronPython] Error with non-jagged array?
In-Reply-To: <C02467D265F3F64E87DED53F9C3DE29C13699D@nostromo.circle-cross.home>
References: <C02467D265F3F64E87DED53F9C3DE29C13699D@nostromo.circle-cross.home>
Message-ID: <200504091632.35088.MichaelNedzelsky@yandex.ru>

I have WinXP with NET 2.0 beta 1 installed and IronPython 0.7.1, but I have no 
Matrix pack and  site http://www.aisto.com/roeder/dotnet/ just now is 
unreachable. Can you send this file as attachment (if it is not very big)?

Michael



From MichaelNedzelsky at yandex.ru  Sat Apr  9 20:13:27 2005
From: MichaelNedzelsky at yandex.ru (Michael)
Date: Sat, 9 Apr 2005 22:13:27 +0400
Subject: [IronPython] Error with non-jagged array?
In-Reply-To: <C02467D265F3F64E87DED53F9C3DE29C13699D@nostromo.circle-cross.home>
References: <C02467D265F3F64E87DED53F9C3DE29C13699D@nostromo.circle-cross.home>
Message-ID: <200504092213.27872.MichaelNedzelsky@yandex.ru>

>On Saturday 09 April 2005 14:09, Keith J. Farmer wrote:
> Caveat:  I ran this using Mono, so I'm not sure if it's really a problem
> with Mono, or a bug in IronPython.  It looks like there are some
> problems with arrays, but someone with a Win32 version should check
> this.

Using Windows XP SP2 with .NET 2.0 beta 1.

c:\User\Michael\Current\test\IronPython-0.7.1\bin>IRonPythonConsole
IronPython 0.7.1 on .NET 2.0.40607.16
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import sys
>>> sys.LoadAssemblyFromFile("Mapack.dll")
>>> from Mapack import *
>>> m = Matrix.Random(3, 3)
>>> m
0.317911618537228 0.60680240281243 0.260385566512302
0.12768023839578 0.684026812987415 0.0971812834484416
0.560014263056225 0.824561594438069 0.449464813549754

>>> m.Transpose()
0.317911618537228 0.12768023839578 0.560014263056225
0.60680240281243 0.684026812987415 0.824561594438069
0.260385566512302 0.0971812834484416 0.449464813549754

>>> m[0, 0]
System.Reflection.TargetParameterCountException: Parameter count mismatch.
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags 
invoke
Attr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.RuntimePropertyInfo.GetValue(Object obj, BindingFlags 
in
vokeAttr, Binder binder, Object[] index, CultureInfo culture)
   at System.Reflection.RuntimePropertyInfo.GetValue(Object obj, Object[] 
index)

   at IronPython.Objects.PythonType.__getitem__(Object self, Object index)
   at IronPython.Objects.Ops.GetIndex(Object o, Object index)
   at input_6.Run(Frame frame)
   at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame)
   at IronPython.Hosting.PythonEngine.RunInteractive()

Michael



From reginald at rare-it.com  Sat Apr  9 21:27:01 2005
From: reginald at rare-it.com (R.R. Sprinkhuizen)
Date: Sat, 9 Apr 2005 21:27:01 +0200
Subject: [IronPython] IronPython,  please?
In-Reply-To: <200504092213.27872.MichaelNedzelsky@yandex.ru>
Message-ID: <20050409192639.D097084D0B@che.dreamhost.com>

People,

I know we all have our preference of what to call IronPython(Console) in the
future, which is up to Jim and his team to decide. But could you all stick
to IronPython(Console) for now. The "fepy", "ironpy", "IP" and whatever
references make it hard to follow some discussions. At least, for me. You've
had your chance to say what you like, now wait until Jim has casted his
spell. This list is like "The police are thinking of changing the
speedlimit. I like 90mph/150kmh so that's how fast I will drive way ahead of
their decision. Then they'll see that's the right speed.".

Thank you for listening.

Reginald

P.S. I said the magic word!






From martmaly at exchange.microsoft.com  Sun Apr 10 03:20:15 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Sat, 9 Apr 2005 18:20:15 -0700
Subject: [IronPython] Error with non-jagged array?
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701A6B4FF@df-chewy-msg.exchange.corp.microsoft.com>

This is an IronPython bug. We only support one-dimensional indexing at
the moment.

Martin


> -----Original Message-----
> From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-
> ironpython.com-bounces at lists.ironpython.com] On Behalf Of Keith J.
Farmer
> Sent: Saturday, April 09, 2005 3:10 AM
> To: Discussion of IronPython
> Subject: [IronPython] Error with non-jagged array?
> 
> Caveat:  I ran this using Mono, so I'm not sure if it's really a
problem
> with Mono, or a bug in IronPython.  It looks like there are some
> problems with arrays, but someone with a Win32 version should check
> this.
> 
> The following uses Mapack, downloadable from Lutz Roeder's site.
> 
> Intended usage from C# would be:
> 
> 	Matrix A = new Matrix(3, 3);
> 	A[0,0] = 2.0; A[0,1] = 1.0; A[0,2] = 2.0;
> 	A[1,0] = 1.0; A[1,1] = 4.0; A[1,2] = 0.0;
> 	A[2,0] = 2.0; A[2,1] = 0.0; A[2,2] = 8.0;
> 
> ----------
> Keith J. Farmer
> kfarmer at thuban.org
> http://www.thuban.org
> 
> C:\Program Files\IronPython-0.7.1\bin>mono IronPythonConsole.exe
> IronPython 0.7.1 on .NET 2.0.40607.16
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> import sys
> >>> sys.LoadAssemblyFromFile("C:\\Documents and
> Settings\\kfarmer\\Desktop\\Mapack\\Build\\Mapack.dll")
> >>> from Mapack import *
> >>> m = Matrix.Random(3, 3)
> >>> m
> 0.225364771776537 0.31672962862846 0.88264873478685
> 0.648747126408269 0.137992081762288 0.868301292354381
> 0.880461812895006 0.061446850682351 0.249342372757076
> 
> >>> m.Transpose()
> 0.225364771776537 0.648747126408269 0.880461812895006
> 0.31672962862846 0.137992081762288 0.061446850682351
> 0.88264873478685 0.868301292354381 0.249342372757076
> 
> >>> m[0,0]
> System.Reflection.TargetParameterCountException: Number of parameter
> does not match expected count.
> in <0x00111> System.Reflection.Binder:ConvertArgs
>
(System.Reflection.Binder,object[],System.Reflection.ParameterInfo[],Sys
> tem.Globalization.CultureInfo)
> in <0x00040> System.Reflection.MonoMethod:Invoke
>
(object,System.Reflection.BindingFlags,System.Reflection.Binder,object[]
> ,System.Globalization.CultureInfo)
> in <0x00060> System.Reflection.MonoProperty:GetValue
>
(object,System.Reflection.BindingFlags,System.Reflection.Binder,object[]
> ,System.Globalization.CultureInfo)
> in <0x00017> System.Reflection.PropertyInfo:GetValue (object,object[])
> in <0x00070> IronPython.Objects.PythonType:__getitem__ (object,object)
> in <0x002ca> IronPython.Objects.Ops:GetIndex (object,object)
> in <0x000a4> input_7:Run (IronPython.Objects.Frame)
> in <0x0023f> IronPython.Hosting.PythonEngine:DoOneInteractive
> (IronPython.Objects.Frame)
> in <0x0003f> IronPython.Hosting.PythonEngine:RunInteractive ()
> 
> >>> m[0][0]
> System.Reflection.TargetParameterCountException: Number of parameter
> does not match expected count.
> in <0x00111> System.Reflection.Binder:ConvertArgs
>
(System.Reflection.Binder,object[],System.Reflection.ParameterInfo[],Sys
> tem.Globalization.CultureInfo)
> in <0x00040> System.Reflection.MonoMethod:Invoke
>
(object,System.Reflection.BindingFlags,System.Reflection.Binder,object[]
> ,System.Globalization.CultureInfo)
> in <0x00060> System.Reflection.MonoProperty:GetValue
>
(object,System.Reflection.BindingFlags,System.Reflection.Binder,object[]
> ,System.Globalization.CultureInfo)
> in <0x00017> System.Reflection.PropertyInfo:GetValue (object,object[])
> in <0x00070> IronPython.Objects.PythonType:__getitem__ (object,object)
> in <0x002ca> IronPython.Objects.Ops:GetIndex (object,object)
> in <0x00051> input_8:Run (IronPython.Objects.Frame)
> in <0x0023f> IronPython.Hosting.PythonEngine:DoOneInteractive
> (IronPython.Objects.Frame)
> in <0x0003f> IronPython.Hosting.PythonEngine:RunInteractive ()
> 
> >>> m.__dict__
> {'Trace': <property# Trace on Matrix>, 'Submatrix': <method# Submatrix
> on Mapack.Matrix>, 'GetHashCode': <method# GetHashCode on
> System.Object>, 'Diagonal': <method# Diagonal on Mapack.Matrix>,
> 'Random': <method# Random on Mapack.Matrix>, 'IsSquare': <property#
> IsSquare on Matrix>, 'Item': <property# Item on Matrix>, 'Inverse':
> <property# Inverse on Matrix>, 'Norm1': <property# Norm1 on Matrix>,
> 'IsSymmetric': <property# IsSymmetric on Matrix>, 'InfinityNorm':
> <property# InfinityNorm on Matrix>, 'Transpose': <method# Transpose on
> Mapack.Matrix>, 'ToString': <method# ToString on Mapack.Matrix>,
'Rows':
> <property# Rows on Matrix>, '__new__': <method Mapack.Matrix.__new__>,
> 'GetType': <method# GetType on System.Object>, '__repr__': <built-in
> function ReprMethod>, 'FrobeniusNorm': <property# FrobeniusNorm on
> Matrix>, 'Solve': <method# Solve on Mapack.Matrix>, 'Columns':
> <property# Columns on Matrix>, 'Determinant': <property# Determinant
on
> Matrix>,'Clone': <method# Clone on Mapack.Matrix>, 'Equals': <method#
> Equals on System.Object>}
> >>>
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From kfarmer at thuban.org  Sun Apr 10 03:36:56 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Sat, 9 Apr 2005 18:36:56 -0700
Subject: [IronPython] Error with non-jagged array?
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C13699E@nostromo.circle-cross.home>

Gotcha .. thanks 

----------
Keith J. Farmer
kfarmer at thuban.org
http://www.thuban.org

-----Original Message-----
From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Martin Maly
Sent: Saturday, April 09, 2005 6:20 PM
To: Discussion of IronPython
Subject: RE: [IronPython] Error with non-jagged array?

This is an IronPython bug. We only support one-dimensional indexing at
the moment.


From mailinglist.account at gmail.com  Sun Apr 10 12:25:11 2005
From: mailinglist.account at gmail.com (Anthony Tarlano)
Date: Sun, 10 Apr 2005 12:25:11 +0200
Subject: [IronPython] IronPython, please?
In-Reply-To: <20050409192639.D097084D0B@che.dreamhost.com>
References: <200504092213.27872.MichaelNedzelsky@yandex.ru>
	<20050409192639.D097084D0B@che.dreamhost.com>
Message-ID: <f2b573190504100325109f8209@mail.gmail.com>

Reginald,

I second your thoughts.. Let's just name the IronPython(console)
python.net.exe and be done with the madness

;-)

Anthony

On Apr 9, 2005 9:27 PM, R.R. Sprinkhuizen <reginald at rare-it.com> wrote:
> People,
> 
> I know we all have our preference of what to call IronPython(Console) in the
> future, which is up to Jim and his team to decide. But could you all stick
> to IronPython(Console) for now. The "fepy", "ironpy", "IP" and whatever
> references make it hard to follow some discussions. At least, for me. You've
> had your chance to say what you like, now wait until Jim has casted his
> spell. This list is like "The police are thinking of changing the
> speedlimit. I like 90mph/150kmh so that's how fast I will drive way ahead of
> their decision. Then they'll see that's the right speed.".
> 
> Thank you for listening.
> 
> Reginald
> 
> P.S. I said the magic word!
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From a01720 at gmail.com  Tue Apr 12 13:07:13 2005
From: a01720 at gmail.com (a p)
Date: Tue, 12 Apr 2005 07:07:13 -0400
Subject: [IronPython] change License for IronPython - or we will not use it!
Message-ID: <efcd798405041204072ceea1b4@mail.gmail.com>

My company using Python and we loved IronPython - initially.
Yesterday our lawyers invited us to company-wide meeting and
discuss if will use IronPython or not. Decision was made:

===========================================
until IronPython will not have the license approved by Open Source
community, like BSD or whatever, we cannot use it. Implication of 
this is that we will use CPython & Linux in our production environment
as oppose to other option: IronPython, Windows and .NET
===========================================

I know other 2 companies in MA and 3 in CA which will do the same.

ap, a01720 at gmail.com

I also posted it on Jason Matusow's blog:
http://blogs.msdn.com/jasonmatusow/archive/2005/03/28/402992.aspx#407528


From martmaly at exchange.microsoft.com  Wed Apr 13 02:04:57 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Tue, 12 Apr 2005 17:04:57 -0700
Subject: [IronPython] IronPython 0.7.2 Released
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701A6BBDF@df-chewy-msg.exchange.corp.microsoft.com>


We are excited to announce the release of IronPython 0.7.2. The
improvements over the recent 0.7.1 release are:

* Indexing .Net arrays, both single- and multi-dimensional
* Correct exception thrown on division by zero (ZeroDivisionError)
* string constant parsing fixed to handle unrecognized escape sequences
correctly
* Complex slicing scenarios fixed
* issubclass(class, instance) fixed to raise correct exception
* chr(x) raises ValueError on invalid values
* callable() implemented
* object.__delattr__ implemented
* Exception.args can now be accessed from Python code (this relates to
the .Net array access)
* str(None) is now handled correctly
* Call with keyword args is fixed
* Invoking .Net properties with parameters (indexers) is now supported
* .Net classes with static constructor can now be subclassed
* max() and min() fixed to work on lists and support correct arguments
* open file overloads are now implemented
* complex() second argument is optional fixed
* Implementation of long integer division. This enables us to run
Parrotbench again.
* A new example to demonstrate the use of .Net delegates with IronPython

Our thanks go to the following members of the community who reported the
bugs:

Tarlano, luismg, spencermah, jdh2358, Wakk, Nick_Jacobson, Keith J.
Farmer

Thanks and keep in touch,
The IronPython Team

http://workspaces.gotdotnet.com/ironpython
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
http://www.microsoft.com/downloads/details.aspx?FamilyID=ca016ff4-dae8-4
007-8018-4f201003c9dc&displaylang=en



From martmaly at exchange.microsoft.com  Wed Apr 13 02:23:05 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Tue, 12 Apr 2005 17:23:05 -0700
Subject: [IronPython] IronPython 0.7.2 Released
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701A6BBFB@df-chewy-msg.exchange.corp.microsoft.com>


We are excited to announce the release of IronPython 0.7.2. The
improvements over the recent 0.7.1 release are:

* Indexing .Net arrays, both single- and multi-dimensional
* Correct exception thrown on division by zero (ZeroDivisionError)
* string constant parsing fixed to handle unrecognized escape sequences
correctly
* Complex slicing scenarios fixed
* issubclass(class, instance) fixed to raise correct exception
* chr(x) raises ValueError on invalid values
* callable() implemented
* object.__delattr__ implemented
* Exception.args can now be accessed from Python code (this relates to
the .Net array access)
* str(None) is now handled correctly
* Call with keyword args is fixed
* Invoking .Net properties with parameters (indexers) is now supported
* .Net classes with static constructor can now be subclassed
* max() and min() fixed to work on lists and support correct arguments
* open file overloads are now implemented
* complex() second argument is optional fixed
* Implementation of long integer division. This enables us to run
Parrotbench again.
* A new example to demonstrate the use of .Net delegates with IronPython

Our thanks go to the following members of the community who reported the
bugs:

Tarlano, luismg, spencermah, jdh2358, Wakk, Nick_Jacobson, Keith J.
Farmer

Thanks and keep in touch,
The IronPython Team

http://workspaces.gotdotnet.com/ironpython
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
http://www.microsoft.com/downloads/details.aspx?FamilyID=ca016ff4-dae8-4
007-8018-4f201003c9dc&displaylang=en


From kfarmer at thuban.org  Wed Apr 13 04:09:21 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Tue, 12 Apr 2005 19:09:21 -0700
Subject: [IronPython] IronPython 0.7.2 Released
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F89@nostromo.circle-cross.home>

Kinda makes you feel all warm and fuzzy inside...

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Martin Maly
Sent: Tue 4/12/2005 5:23 PM


We are excited to announce the release of IronPython 0.7.2. The
improvements over the recent 0.7.1 release are:


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3319 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050412/d3f2e65b/attachment.bin>

From kfarmer at thuban.org  Wed Apr 13 10:06:25 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Wed, 13 Apr 2005 01:06:25 -0700
Subject: [IronPython] IronPython 0.7.2 Released
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C1369A7@nostromo.circle-cross.home>

Is the calling of overloaded operators implemented?

(Mono 1.1.6 / Win32, Mapack imported)

>>> a = Matrix(3,3)
>>> a[0,0]=2.0
>>> a[0,1]=1.0
>>> a[0,2]=2.0
>>> a[1,0]=1.0
>>> a[1,1]=4.0
>>> a[1,2]=0.0
>>> a[2,0]=2.0
>>> a[2,1]=0.0
>>> a[2,2]=8.0
>>> a
2 1 2
1 4 0
2 0 8
>>> a.Inverse
0.8 -0.2 -0.2
-0.2 0.3 0.05
-0.2 0.05 0.175
>>> a * a.Inverse
IronPython.Objects.PythonTypeError: unsupported operand type(s) for *:
'Mapack.Matrix' and 'Mapack.Matrix'
in <0x005c2> IronPython.Objects.Ops:Multiply (System.Object x,
System.Object y)
in <0x00069> input_58:Run (IronPython.Objects.Frame frame)
in <0x00268> IronPython.Hosting.PythonEngine:DoOneInteractive
(IronPython.Objects.Frame topFrame)
in <0x00042> IronPython.Hosting.PythonEngine:RunInteractive ()


From kfarmer at thuban.org  Wed Apr 13 10:18:03 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Wed, 13 Apr 2005 01:18:03 -0700
Subject: [IronPython] IronPython 0.7.2 Released
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C1369A8@nostromo.circle-cross.home>

Same verified in MS beta:

IronPython 0.7.2 on .NET 2.0.40607.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import sys
>>> sys.LoadAssemblyFromFile("Mapack.dll")
>>> from Mapack import *
>>> a = Matrix.Random(3,3)
>>> a
0.805084117131813 0.256781293664491 0.696419091288195
0.985639146056789 0.0990895573511205 0.659152610534407
0.0564137879090448 0.647960312500578 0.733555638572925

>>> a.Inverse
17.2325124553564 -12.7822032611854 -4.87437875024199
33.3468034134656 -26.8047193679194 -7.57263592898315
-30.7809732161662 24.6600065362538 8.42710407628743

>>> a * a.Inverse
IronPython.Objects.PythonTypeError: unsupported operand type(s) for *:
'Mapack.Matrix' and 'Mapack.Matrix'
   at IronPython.Objects.Ops.Multiply(Object x, Object y)
   at input_6.Run(Frame frame)
   at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame)
   at IronPython.Hosting.PythonEngine.RunInteractive()


From abubakarm at gmail.com  Wed Apr 13 11:42:32 2005
From: abubakarm at gmail.com (Muhammad Abubakar)
Date: Wed, 13 Apr 2005 14:42:32 +0500
Subject: [IronPython] IronPython, please?
In-Reply-To: <f2b573190504100325109f8209@mail.gmail.com>
References: <200504092213.27872.MichaelNedzelsky@yandex.ru>
	<20050409192639.D097084D0B@che.dreamhost.com>
	<f2b573190504100325109f8209@mail.gmail.com>
Message-ID: <c40f6d350504130242a2a2c65@mail.gmail.com>

csc = c# compiler
vbc = vb.net compiler
jsc = jscript compiler
ipc = iron python compiler <<<

Ab.

On 4/10/05, Anthony Tarlano <mailinglist.account at gmail.com> wrote:
> Reginald,
> 
> I second your thoughts.. Let's just name the IronPython(console)
> python.net.exe and be done with the madness
> 
> ;-)
> 
> Anthony
> 
> On Apr 9, 2005 9:27 PM, R.R. Sprinkhuizen <reginald at rare-it.com> wrote:
> > People,
> >
> > I know we all have our preference of what to call IronPython(Console) in the
> > future, which is up to Jim and his team to decide. But could you all stick
> > to IronPython(Console) for now. The "fepy", "ironpy", "IP" and whatever
> > references make it hard to follow some discussions. At least, for me. You've
> > had your chance to say what you like, now wait until Jim has casted his
> > spell. This list is like "The police are thinking of changing the
> > speedlimit. I like 90mph/150kmh so that's how fast I will drive way ahead of
> > their decision. Then they'll see that's the right speed.".
> >
> > Thank you for listening.
> >
> > Reginald
> >
> > P.S. I said the magic word!
> >
> > _______________________________________________
> > users-ironpython.com mailing list
> > users-ironpython.com at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From a01720 at gmail.com  Wed Apr 13 12:10:51 2005
From: a01720 at gmail.com (a p)
Date: Wed, 13 Apr 2005 06:10:51 -0400
Subject: [IronPython] Re: IronPython License
In-Reply-To: <efcd798405041302554e176d8c@mail.gmail.com>
References: <9ED672B9D1A64C489291BE0FB822217D09F840A3@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
	<efcd798405041302554e176d8c@mail.gmail.com>
Message-ID: <efcd798405041303104571cb83@mail.gmail.com>

FYI (I included users-ironpython.com at lists.ironpython.com into CC list
but GMAIL somehow
ingored it, so I am posting my respond to Jason here)

---------- Forwarded message ----------
From: a p <a01720 at gmail.com>
Date: Apr 13, 2005 5:55 AM
Subject: Re: IronPython License
To: Jason Matusow <jasonma at windows.microsoft.com>
Cc: Jim Hugunin <jimhug at microsoft.com>

Jason:

You already know everything you need to know from your blog and especially from
IronPython mailing list. I am CC-ing my answer to this mailing list,
because it is not a private
communication we have here.

Microsoft has (or had?) a wonderful opportunity to dramatically
improve relationship
with Open Source people by making IronPython a success and enable it to be
integrated with Visual Studio. Jim has (or had?) a tremendous
recognition and his
willingless to join Microsoft created a lot of hope for the bright
future. Instead you
keep listening Microsoft lawyers and continue to try to destroy Open
Source movement
from within instead of embracing it.

Let's see what people already said and you are pretending to ignore it:

1. Anonimous said: "Why not make it clear that Microsoft will not sue
anyone using a derivative of this for violating its OWN patents?"

2. James Mastros said: "The license makes this software another piece
in the increasingly one-sided game of MAD called patents. Take this
scenario: I create a derived work from this, which I wish to sell
support contracts on. Whoops, that's a derived work, Microsoft sues me
for patent infringment, since the patent rights didn't transfer to
derived works per clause 6. Even better, if it turns out that
Microsoft folds the source for the bit of it that /I/ have patented
back into the mainstream, I can't sue them; if I try I'm in violation
of clause 5 and can no longer distribute my product. Doesn't seem like
a very symmetric relationship to me; it sounds like one that is
distinctly in the favor of Microsoft."

3. James Mastros said: "It does not give anyone the ability to offer
support contracts, unless they have the ability to relicense (for
which see below). Clause three of the license says it comes with none,
and explicitly says that you can't remove that section (which is
redundant as clause two of the license already says that)."

4. James Mastros said: "It does not give you the permission to
relicense the code under less permissive terms. It's perfectly legal
to take BSD'd code, modify it, and re-release it under the terms of
the GPL, or some other similar license, so long as you do not remove
"...the above copyright notice, this list of conditions and the
following disclaimer". This allows one to simplfy the legal
mumbo-jumbo by distributing an entire bundle under one license."

5. Sriram Krishnan asked: "can IronPython code be used in a
GPL-project?" Jason: where is Microsoft answer? Is it NO?

6. Terry L. Triplett asked for CPL: "I'd like to see IronPython
continue to be distributable everywhere that CPython might be found
that also happens to have a compliant CLR implementation."

7. Jonathan LaCour said: So, to review my pie-in-the-sky wishes to
guarantee IronPython success:
>   1. Switch to a similar, but respected license.
>       - Bonus points for picking the same license as mono.
>   2. Ditch the gotdotnet forums.  Make the mailing list "the way".
>   3. Don't require a passport to file bugs.
>   4. Have a public SVN or CVS repository.
>   5. Be open to accepting external patches.
>   6. Have at least one other "committer" (to help lighten the load on you).
>       - Bonus points if this person is outside Microsoft.
>       - Extra bonus points if this person is a respected Mono hacker.
>
> Items 1, 3, and 5 are non-negotiable to me.  If you don't do these at least, I
> guarantee that the project will stagnate, and something like Boo will become
> more widely accepted (especially by Open Source types).
>
> Anyway. I don't want to criticize you too much, as I think IronPython is a great
> piece of work.  I would just hate to see such a great opportunity be missed!
>
> and Andreas Kotes, Fred Dixon, Ryan Williams and a lot of other people agreed with above!

8. Just make your license OSI certified, people saying it and you keep
ingoring this request.

9. use sourceforge instead of gotdotnet; do not use PASSPORT! Jonathan
LaCour said: "I think the Passport thing is probably a showstopper for
many Open Source people.  I am not going to argue the technical merits
for this, but to many OSS people, Passport is considered some great
evil." Look what Passport TOS said: "You must enter into a different
legal agreement with Microsoft if you wish to offer the .NET Passport
Services to users of your own application, Web site, or Web service.
You may not use any software or hardware that reduces the number of
users directly accessing or using the .NET Passport Services
(sometimes called "multiplexing" or "pooling" software or hardware)."

10. Use mailing list, use public cvs/svn server as all non-microsoft
open source people.

11. J. Merill said: "Here's a sentence from the FAQ concerning
patents:  [quote] This license grants you a patent license to use and
distribute the Software under any Microsoft patent
claims that read on the Software itself. [end quote]."

12. And more... but I hope you got my (really people's) point. Don't
even think that you and your lawyers can outsmart entire mankind.
Again: with IronPython your
Microsoft has a unique opportunity but based on your blog and what you
forcing Jum to
do looks to me as your readiness to waste the opportunity. Go ahead with your
plans... and I feel sorry for Jim.

On 4/13/05, Jason Matusow <jasonma at windows.microsoft.com> wrote:
>
> Hello AP -
>
> Thanks for your comment to my blog and to the IronPython mailing list. I am
> sorry to hear that your attorneys have had a negative reaction to our
> license. Would you be willing to share your company name and provide us with
> some feedback on the license in terms of what was objectionable about it?
> Our goal is simply to understand the objections so that we may improve our
> process in the future. Each clause in the IronPython license is mirrored in
> terms found in OSI-approved licenses. We recognized that there is more we
> can do to improve our relationship with the OSI, but at this time our source
> code releases are not generally done under the auspices of one of their
> licenses.
>
> Your feedback is very welcome. If you have tough criticism for us in this
> space please do not hold back. Our source licensing efforts are an ongoing
> learning process and your input is highly valued.
>
> Thanks.
>
> Jason Matusow
> Director, Shared Source
> Microsoft


From fredrik at pythonware.com  Wed Apr 13 12:28:07 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 13 Apr 2005 12:28:07 +0200
Subject: [IronPython] Re: IronPython License
References: <9ED672B9D1A64C489291BE0FB822217D09F840A3@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com><efcd798405041302554e176d8c@mail.gmail.com>
	<efcd798405041303104571cb83@mail.gmail.com>
Message-ID: <d3is1m$c8a$1@sea.gmane.org>

> 12. And more... but I hope you got my (really people's) point. Don't
> even think that you and your lawyers can outsmart entire mankind.

now that's one constructive approach.

sorry, "a p", but you and your mail strikes me as incredibly immature and totally
unprofessional.  what company did you work for, again?

</F> 





From reginald at rare-it.com  Wed Apr 13 13:07:07 2005
From: reginald at rare-it.com (reginald at rare-it.com)
Date: Wed, 13 Apr 2005 13:07:07 +0200 (W. Europe Daylight Time)
Subject: [IronPython] IronPython, please?
In-Reply-To: <c40f6d350504130242a2a2c65@mail.gmail.com>
References: <200504092213.27872.MichaelNedzelsky@yandex.ru>
	<20050409192639.D097084D0B@che.dreamhost.com>
	<f2b573190504100325109f8209@mail.gmail.com>
	<c40f6d350504130242a2a2c65@mail.gmail.com>
Message-ID: <44983.194.151.13.245.1113390427.squirrel@www.rare-it.com>

> csc = c# compiler
> vbc = vb.net compiler
> jsc = jscript compiler
> ipc = iron python compiler <<<
>
> Ab.

Nice suggestion, but IronPython is not a compiler (yet?).

Reginald






From reginald at rare-it.com  Wed Apr 13 14:15:27 2005
From: reginald at rare-it.com (reginald at rare-it.com)
Date: Wed, 13 Apr 2005 14:15:27 +0200 (W. Europe Daylight Time)
Subject: [IronPython] Re: IronPython License
In-Reply-To: <d3is1m$c8a$1@sea.gmane.org>
References: <9ED672B9D1A64C489291BE0FB822217D09F840A3@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com><efcd798405041302554e176d8c@mail.gmail.com>
	<efcd798405041303104571cb83@mail.gmail.com>
	<d3is1m$c8a$1@sea.gmane.org>
Message-ID: <49018.194.151.13.245.1113394527.squirrel@www.rare-it.com>

>> 12. And more... but I hope you got my (really people's) point. Don't
>> even think that you and your lawyers can outsmart entire mankind.
>
> now that's one constructive approach.
>
> sorry, "a p", but you and your mail strikes me as incredibly immature and
> totally
> unprofessional.  what company did you work for, again?

Personally, I don't even think he has reached the working age yet. Style
of writing and contents remind me of somebody still in college. Feel free
to correct me, "a p".

A software vendor (or supplier, in case it's free) states in the license
agreement under what conditions you can use the software. If you don't
agree to that, don't use it. To me, IronPython is a proof-of-concept with
a lot of potential. I'm not too happy with the new license either, but
when I think about it, that's more because of the "feel" the license gives
me, than because of the "real issues" I can't live with. I guess we're all
a bit too suspicious when it comes to Microsoft giving us "free software".

Just my 2 cents...

Reginald






From abubakarm at gmail.com  Wed Apr 13 14:25:35 2005
From: abubakarm at gmail.com (Muhammad Abubakar)
Date: Wed, 13 Apr 2005 17:25:35 +0500
Subject: [IronPython] IronPython, please?
In-Reply-To: <44983.194.151.13.245.1113390427.squirrel@www.rare-it.com>
References: <200504092213.27872.MichaelNedzelsky@yandex.ru>
	<20050409192639.D097084D0B@che.dreamhost.com>
	<f2b573190504100325109f8209@mail.gmail.com>
	<c40f6d350504130242a2a2c65@mail.gmail.com>
	<44983.194.151.13.245.1113390427.squirrel@www.rare-it.com>
Message-ID: <c40f6d350504130525db5a39e@mail.gmail.com>

But as discussed in some of the previous posts, it does produces a
"_main__.exe" when u run the ironpython on a *.py file so it  is
producing IL like a c# compiler.

Ab.

On 4/13/05, reginald at rare-it.com <reginald at rare-it.com> wrote:
> > csc = c# compiler
> > vbc = vb.net compiler
> > jsc = jscript compiler
> > ipc = iron python compiler <<<
> >
> > Ab.
> 
> Nice suggestion, but IronPython is not a compiler (yet?).
> 
> Reginald
> 
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From reginald at rare-it.com  Wed Apr 13 19:40:02 2005
From: reginald at rare-it.com (R.R. Sprinkhuizen)
Date: Wed, 13 Apr 2005 19:40:02 +0200
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <c40f6d350504130525db5a39e@mail.gmail.com>
Message-ID: <20050413173942.4094084D23@che.dreamhost.com>

I think that's a very lean way to describe a compiler: it creates an .exe
file. But I see where you're coming from.

IPC is short, so why not?

Reginald 

-----Original Message-----
From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Muhammad Abubakar
Sent: woensdag 13 april 2005 14:26
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython, please?

But as discussed in some of the previous posts, it does produces a
"_main__.exe" when u run the ironpython on a *.py file so it  is producing
IL like a c# compiler.

Ab.

On 4/13/05, reginald at rare-it.com <reginald at rare-it.com> wrote:
> > csc = c# compiler
> > vbc = vb.net compiler
> > jsc = jscript compiler
> > ipc = iron python compiler <<<
> >
> > Ab.
> 
> Nice suggestion, but IronPython is not a compiler (yet?).
> 
> Reginald
> 
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
_______________________________________________
users-ironpython.com mailing list
users-ironpython.com at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com







From martmaly at exchange.microsoft.com  Wed Apr 13 21:47:06 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Wed, 13 Apr 2005 12:47:06 -0700
Subject: [IronPython] IronPython 0.7.2 Released
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701B0F3EC@df-chewy-msg.exchange.corp.microsoft.com>

Thanks, Keith!

Calling overloaded operators is not implemented yet and my quick test
showed that at the moment you can't even call:
Matrix.op_Multiply(a, a.Inverse) directly.

We should have fix for this in the next release. Simple version of this
is already working on my computer.

Martin


-----Original Message-----
From: Keith J. Farmer
Subject: RE: [IronPython] IronPython 0.7.2 Released

Is the calling of overloaded operators implemented?



From alleykat at gmail.com  Wed Apr 13 22:38:02 2005
From: alleykat at gmail.com (Travis Watkins)
Date: Wed, 13 Apr 2005 15:38:02 -0500
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <20050413173942.4094084D23@che.dreamhost.com>
References: <c40f6d350504130525db5a39e@mail.gmail.com>
	<20050413173942.4094084D23@che.dreamhost.com>
Message-ID: <adca365a050413133830bb5a1@mail.gmail.com>

On 4/13/05, R.R. Sprinkhuizen <reginald at rare-it.com> wrote:
> I think that's a very lean way to describe a compiler: it creates an .exe
> file. But I see where you're coming from.
> 
> IPC is short, so why not?

IPC is also an acronym for interprocess communication. Might be confusing.

> 
> Reginald
> 
> -----Original Message-----
> From: users-ironpython.com-bounces at lists.ironpython.com
> [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
> Muhammad Abubakar
> Sent: woensdag 13 april 2005 14:26
> To: Discussion of IronPython
> Subject: Re: [IronPython] IronPython, please?
> 
> But as discussed in some of the previous posts, it does produces a
> "_main__.exe" when u run the ironpython on a *.py file so it  is producing
> IL like a c# compiler.
> 
> Ab.
> 
> On 4/13/05, reginald at rare-it.com <reginald at rare-it.com> wrote:
> > > csc = c# compiler
> > > vbc = vb.net compiler
> > > jsc = jscript compiler
> > > ipc = iron python compiler <<<
> > >
> > > Ab.
> >
> > Nice suggestion, but IronPython is not a compiler (yet?).
> >
> > Reginald
> >
> >
> > _______________________________________________
> > users-ironpython.com mailing list
> > users-ironpython.com at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 


-- 
--
Travis Watkins
http://www.realistanew.com


From reginald at rare-it.com  Thu Apr 14 00:14:50 2005
From: reginald at rare-it.com (R.R. Sprinkhuizen)
Date: Thu, 14 Apr 2005 00:14:50 +0200
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <adca365a050413133830bb5a1@mail.gmail.com>
Message-ID: <20050413221515.F1AA484D0B@che.dreamhost.com>

> > I think that's a very lean way to describe a compiler: it creates an 
> > .exe file. But I see where you're coming from.
> > 
> > IPC is short, so why not?

> IPC is also an acronym for interprocess communication. Might be confusing.

Seems like all the good names are taken... 

Cheers!
Reginald

--
http://www.rare-it.com/b2e/blogs/switchbl8






From brian at zope.com  Thu Apr 14 00:38:24 2005
From: brian at zope.com (Brian Lloyd)
Date: Wed, 13 Apr 2005 18:38:24 -0400
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <adca365a050413133830bb5a1@mail.gmail.com>
Message-ID: <INENIOEOCHPHGHKLFLOLAEBDEDAA.brian@zope.com>

I can't believe nobody is lobbying for pyc.exe  ;)


Brian Lloyd        brian at zope.com
V.P. Engineering   540.361.1716
Zope Corporation   http://www.zope.com


> -----Original Message-----
> From: users-ironpython.com-bounces at lists.ironpython.com
> [mailto:users-ironpython.com-bounces at lists.ironpython.com]On Behalf Of
> Travis Watkins
> Sent: Wednesday, April 13, 2005 3:38 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] To Compile or Not to compile, that's the
> question
>
>
> On 4/13/05, R.R. Sprinkhuizen <reginald at rare-it.com> wrote:
> > I think that's a very lean way to describe a compiler: it
> creates an .exe
> > file. But I see where you're coming from.
> >
> > IPC is short, so why not?
>
> IPC is also an acronym for interprocess communication. Might be confusing.
>
> >
> > Reginald
> >
> > -----Original Message-----
> > From: users-ironpython.com-bounces at lists.ironpython.com
> > [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
> > Muhammad Abubakar
> > Sent: woensdag 13 april 2005 14:26
> > To: Discussion of IronPython
> > Subject: Re: [IronPython] IronPython, please?
> >
> > But as discussed in some of the previous posts, it does produces a
> > "_main__.exe" when u run the ironpython on a *.py file so it
> is producing
> > IL like a c# compiler.
> >
> > Ab.
> >
> > On 4/13/05, reginald at rare-it.com <reginald at rare-it.com> wrote:
> > > > csc = c# compiler
> > > > vbc = vb.net compiler
> > > > jsc = jscript compiler
> > > > ipc = iron python compiler <<<
> > > >
> > > > Ab.
> > >
> > > Nice suggestion, but IronPython is not a compiler (yet?).
> > >
> > > Reginald
> > >
> > >
> > > _______________________________________________
> > > users-ironpython.com mailing list
> > > users-ironpython.com at lists.ironpython.com
> > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> > >
> > _______________________________________________
> > users-ironpython.com mailing list
> > users-ironpython.com at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> > _______________________________________________
> > users-ironpython.com mailing list
> > users-ironpython.com at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
>
>
> --
> --
> Travis Watkins
> http://www.realistanew.com
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



From kfarmer at thuban.org  Thu Apr 14 00:43:59 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Wed, 13 Apr 2005 15:43:59 -0700
Subject: [IronPython] To Compile or Not to compile, that's the question
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F8A@nostromo.circle-cross.home>

Google found references to a pyc.exe, and none in English.
 
+1

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Brian Lloyd
Sent: Wed 4/13/2005 3:38 PM
To: Travis Watkins; Discussion of IronPython
Subject: RE: [IronPython] To Compile or Not to compile, that's the question



I can't believe nobody is lobbying for pyc.exe  ;)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3635 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050413/c7573e2d/attachment.bin>

From jeffg at ActiveState.com  Thu Apr 14 00:52:17 2005
From: jeffg at ActiveState.com (jeff griffiths)
Date: Wed, 13 Apr 2005 15:52:17 -0700
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <INENIOEOCHPHGHKLFLOLAEBDEDAA.brian@zope.com>
References: <INENIOEOCHPHGHKLFLOLAEBDEDAA.brian@zope.com>
Message-ID: <425DA2A1.2060805@activestate.com>

Brian Lloyd wrote:
> I can't believe nobody is lobbying for pyc.exe  ;)

...it might make more sense. Our PerlNET 'compiler' for example is 
'plc.exe', in keeping with csc.exe, etc.

cheers, JeffG

> 
> 
> Brian Lloyd        brian at zope.com
> V.P. Engineering   540.361.1716
> Zope Corporation   http://www.zope.com
> 
> 
> 
>>-----Original Message-----
>>From: users-ironpython.com-bounces at lists.ironpython.com
>>[mailto:users-ironpython.com-bounces at lists.ironpython.com]On Behalf Of
>>Travis Watkins
>>Sent: Wednesday, April 13, 2005 3:38 PM
>>To: Discussion of IronPython
>>Subject: Re: [IronPython] To Compile or Not to compile, that's the
>>question
>>
>>
>>On 4/13/05, R.R. Sprinkhuizen <reginald at rare-it.com> wrote:
>>
>>>I think that's a very lean way to describe a compiler: it
>>
>>creates an .exe
>>
>>>file. But I see where you're coming from.
>>>
>>>IPC is short, so why not?
>>
>>IPC is also an acronym for interprocess communication. Might be confusing.
>>
>>
>>>Reginald
>>>
>>>-----Original Message-----
>>>From: users-ironpython.com-bounces at lists.ironpython.com
>>>[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
>>>Muhammad Abubakar
>>>Sent: woensdag 13 april 2005 14:26
>>>To: Discussion of IronPython
>>>Subject: Re: [IronPython] IronPython, please?
>>>
>>>But as discussed in some of the previous posts, it does produces a
>>>"_main__.exe" when u run the ironpython on a *.py file so it
>>
>>is producing
>>
>>>IL like a c# compiler.
>>>
>>>Ab.
>>>
>>>On 4/13/05, reginald at rare-it.com <reginald at rare-it.com> wrote:
>>>
>>>>>csc = c# compiler
>>>>>vbc = vb.net compiler
>>>>>jsc = jscript compiler
>>>>>ipc = iron python compiler <<<
>>>>>
>>>>>Ab.
>>>>
>>>>Nice suggestion, but IronPython is not a compiler (yet?).
>>>>
>>>>Reginald
>>>>
>>>>
>>>>_______________________________________________
>>>>users-ironpython.com mailing list
>>>>users-ironpython.com at lists.ironpython.com
>>>>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>
>>>_______________________________________________
>>>users-ironpython.com mailing list
>>>users-ironpython.com at lists.ironpython.com
>>>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>_______________________________________________
>>>users-ironpython.com mailing list
>>>users-ironpython.com at lists.ironpython.com
>>>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>
>>
>>--
>>--
>>Travis Watkins
>>http://www.realistanew.com
>>_______________________________________________
>>users-ironpython.com mailing list
>>users-ironpython.com at lists.ironpython.com
>>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
> 
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From abubakarm at gmail.com  Thu Apr 14 06:18:31 2005
From: abubakarm at gmail.com (Muhammad Abubakar)
Date: Thu, 14 Apr 2005 09:18:31 +0500
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <425DA2A1.2060805@activestate.com>
References: <INENIOEOCHPHGHKLFLOLAEBDEDAA.brian@zope.com>
	<425DA2A1.2060805@activestate.com>
Message-ID: <c40f6d35050413211866dd7501@mail.gmail.com>

Me and my lean definitions. Anyway, plc is cool, so is csc. Thats why
I said go for ipc. As far as google is concerned it'll return almost
anything so I think its not useful to google first and than decide
what name should be given to a compiler/interpreter/translator :)
executable file. But I may be (definitely) ignorant of any legal
issues that u guys know which perhaps make it necessary to go search
first and name afterwords.

And about interprocess-process communication, its not done at the
command line by giving "ipc" letters is it? So its not confusing for
me atleast.

cheers,

Ab.

On 4/14/05, jeff griffiths <jeffg at activestate.com> wrote:
> Brian Lloyd wrote:
> > I can't believe nobody is lobbying for pyc.exe  ;)
> 
> ...it might make more sense. Our PerlNET 'compiler' for example is
> 'plc.exe', in keeping with csc.exe, etc.
> 
> cheers, JeffG
> 
> >
> >
> > Brian Lloyd        brian at zope.com
> > V.P. Engineering   540.361.1716
> > Zope Corporation   http://www.zope.com
> >
> >
> >
> >>-----Original Message-----
> >>From: users-ironpython.com-bounces at lists.ironpython.com
> >>[mailto:users-ironpython.com-bounces at lists.ironpython.com]On Behalf Of
> >>Travis Watkins
> >>Sent: Wednesday, April 13, 2005 3:38 PM
> >>To: Discussion of IronPython
> >>Subject: Re: [IronPython] To Compile or Not to compile, that's the
> >>question
> >>
> >>
> >>On 4/13/05, R.R. Sprinkhuizen <reginald at rare-it.com> wrote:
> >>
> >>>I think that's a very lean way to describe a compiler: it
> >>
> >>creates an .exe
> >>
> >>>file. But I see where you're coming from.
> >>>
> >>>IPC is short, so why not?
> >>
> >>IPC is also an acronym for interprocess communication. Might be confusing.
> >>
> >>
> >>>Reginald
> >>>
> >>>-----Original Message-----
> >>>From: users-ironpython.com-bounces at lists.ironpython.com
> >>>[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
> >>>Muhammad Abubakar
> >>>Sent: woensdag 13 april 2005 14:26
> >>>To: Discussion of IronPython
> >>>Subject: Re: [IronPython] IronPython, please?
> >>>
> >>>But as discussed in some of the previous posts, it does produces a
> >>>"_main__.exe" when u run the ironpython on a *.py file so it
> >>
> >>is producing
> >>
> >>>IL like a c# compiler.
> >>>
> >>>Ab.
> >>>
> >>>On 4/13/05, reginald at rare-it.com <reginald at rare-it.com> wrote:
> >>>
> >>>>>csc = c# compiler
> >>>>>vbc = vb.net compiler
> >>>>>jsc = jscript compiler
> >>>>>ipc = iron python compiler <<<
> >>>>>
> >>>>>Ab.
> >>>>
> >>>>Nice suggestion, but IronPython is not a compiler (yet?).
> >>>>
> >>>>Reginald
> >>>>
> >>>>
> >>>>_______________________________________________
> >>>>users-ironpython.com mailing list
> >>>>users-ironpython.com at lists.ironpython.com
> >>>>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>>>
> >>>
> >>>_______________________________________________
> >>>users-ironpython.com mailing list
> >>>users-ironpython.com at lists.ironpython.com
> >>>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>>
> >>>_______________________________________________
> >>>users-ironpython.com mailing list
> >>>users-ironpython.com at lists.ironpython.com
> >>>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>>
> >>
> >>
> >>--
> >>--
> >>Travis Watkins
> >>http://www.realistanew.com
> >>_______________________________________________
> >>users-ironpython.com mailing list
> >>users-ironpython.com at lists.ironpython.com
> >>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>
> >
> >
> > _______________________________________________
> > users-ironpython.com mailing list
> > users-ironpython.com at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From abubakarm at gmail.com  Thu Apr 14 09:41:51 2005
From: abubakarm at gmail.com (Muhammad Abubakar)
Date: Thu, 14 Apr 2005 12:41:51 +0500
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <425DA2A1.2060805@activestate.com>
References: <INENIOEOCHPHGHKLFLOLAEBDEDAA.brian@zope.com>
	<425DA2A1.2060805@activestate.com>
Message-ID: <c40f6d35050414004179133d4d@mail.gmail.com>

Oh and F# = fsc.
 Ab.

 On 4/14/05, jeff griffiths <jeffg at activestate.com> wrote: 
> 
> Brian Lloyd wrote:
> > I can't believe nobody is lobbying for pyc.exe ;)
> 
> ...it might make more sense. Our PerlNET 'compiler' for example is
> 'plc.exe', in keeping with csc.exe, etc.
> 
> cheers, JeffG
> 
> >
> >
> > Brian Lloyd brian at zope.com
> > V.P. Engineering 540.361.1716
> > Zope Corporation http://www.zope.com
> >
> >
> >
> >>-----Original Message-----
> >>From: users-ironpython.com-bounces at lists.ironpython.com
> >>[mailto:users-ironpython.com-bounces at lists.ironpython.com]On Behalf Of
> >>Travis Watkins
> >>Sent: Wednesday, April 13, 2005 3:38 PM
> >>To: Discussion of IronPython
> >>Subject: Re: [IronPython] To Compile or Not to compile, that's the
> >>question
> >>
> >>
> >>On 4/13/05, R.R. Sprinkhuizen <reginald at rare-it.com> wrote:
> >>
> >>>I think that's a very lean way to describe a compiler: it
> >>
> >>creates an .exe
> >>
> >>>file. But I see where you're coming from.
> >>>
> >>>IPC is short, so why not?
> >>
> >>IPC is also an acronym for interprocess communication. Might be 
> confusing.
> >>
> >>
> >>>Reginald
> >>>
> >>>-----Original Message-----
> >>>From: users-ironpython.com-bounces at lists.ironpython.com
> >>>[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
> >>>Muhammad Abubakar
> >>>Sent: woensdag 13 april 2005 14:26
> >>>To: Discussion of IronPython
> >>>Subject: Re: [IronPython] IronPython, please?
> >>>
> >>>But as discussed in some of the previous posts, it does produces a
> >>>"_main__.exe" when u run the ironpython on a *.py file so it
> >>
> >>is producing
> >>
> >>>IL like a c# compiler.
> >>>
> >>>Ab.
> >>>
> >>>On 4/13/05, reginald at rare-it.com <reginald at rare-it.com> wrote:
> >>>
> >>>>>csc = c# compiler
> >>>>>vbc = vb.net <http://vb.net> compiler
> >>>>>jsc = jscript compiler
> >>>>>ipc = iron python compiler <<<
> >>>>>
> >>>>>Ab.
> >>>>
> >>>>Nice suggestion, but IronPython is not a compiler (yet?).
> >>>>
> >>>>Reginald
> >>>>
> >>>>
> >>>>_______________________________________________
> >>>>users-ironpython.com <http://users-ironpython.com> mailing list
> >>>>users-ironpython.com at lists.ironpython.com
> >>>>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>>>
> >>>
> >>>_______________________________________________
> >>>users-ironpython.com <http://users-ironpython.com> mailing list
> >>>users-ironpython.com at lists.ironpython.com
> >>>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>>
> >>>_______________________________________________
> >>>users-ironpython.com <http://users-ironpython.com> mailing list
> >>>users-ironpython.com at lists.ironpython.com
> >>>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>>
> >>
> >>
> >>--
> >>--
> >>Travis Watkins
> >>http://www.realistanew.com
> >>_______________________________________________
> >>users-ironpython.com <http://users-ironpython.com> mailing list
> >>users-ironpython.com at lists.ironpython.com
> >>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>
> >
> >
> > _______________________________________________
> > users-ironpython.com <http://users-ironpython.com> mailing list
> > users-ironpython.com at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> _______________________________________________
> users-ironpython.com <http://users-ironpython.com> mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050414/59cf81da/attachment.html>

From mailinglist.account at gmail.com  Thu Apr 14 21:29:29 2005
From: mailinglist.account at gmail.com (Anthony Tarlano)
Date: Thu, 14 Apr 2005 21:29:29 +0200
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <c40f6d35050414004179133d4d@mail.gmail.com>
References: <INENIOEOCHPHGHKLFLOLAEBDEDAA.brian@zope.com>
	<425DA2A1.2060805@activestate.com>
	<c40f6d35050414004179133d4d@mail.gmail.com>
Message-ID: <f2b5731905041412294f739cc0@mail.gmail.com>

I still think the name python.net (i.e. python.net.exe) has not been taken. 

ActiveState's 2001 python for .net,
http://www.activestate.com/Corporate/Initiatives/NET/Research.html,
should not preempt the use of the name, since they surely aren't doing
anything with it and only used the name for the zip not the name of
the project.

Anthony

On 4/14/05, Muhammad Abubakar <abubakarm at gmail.com> wrote:
> Oh and F# = fsc. 
>   
> Ab.
> 
>   
> On 4/14/05, jeff griffiths <jeffg at activestate.com> wrote: 
> > Brian Lloyd wrote:
> > > I can't believe nobody is lobbying for pyc.exe  ;)
> > 
> > ...it might make more sense. Our PerlNET 'compiler' for example is 
> > 'plc.exe', in keeping with csc.exe, etc.
> > 
> > cheers, JeffG
> > 
> > >
> > >
> > > Brian Lloyd        brian at zope.com
> > > V.P. Engineering   540.361.1716
> > > Zope Corporation   http://www.zope.com
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: users-ironpython.com-bounces at lists.ironpython.com
> >
> >>[mailto:users-ironpython.com-bounces at lists.ironpython.com]On
> Behalf Of
> > >>Travis Watkins
> > >>Sent: Wednesday, April 13, 2005 3:38 PM 
> > >>To: Discussion of IronPython
> > >>Subject: Re: [IronPython] To Compile or Not to compile, that's the
> > >>question
> > >>
> > >>
> > >>On 4/13/05, R.R. Sprinkhuizen < reginald at rare-it.com> wrote:
> > >>
> > >>>I think that's a very lean way to describe a compiler: it
> > >>
> > >>creates an .exe
> > >>
> > >>>file. But I see where you're coming from. 
> > >>>
> > >>>IPC is short, so why not?
> > >>
> > >>IPC is also an acronym for interprocess communication. Might be
> confusing.
> > >>
> > >>
> > >>>Reginald
> > >>>
> > >>>-----Original Message-----
> > >>>From:
> users-ironpython.com-bounces at lists.ironpython.com
> > >>>[mailto:
> users-ironpython.com-bounces at lists.ironpython.com] On
> Behalf Of
> > >>>Muhammad Abubakar
> > >>>Sent: woensdag 13 april 2005 14:26
> > >>>To: Discussion of IronPython
> > >>>Subject: Re: [IronPython] IronPython, please? 
> > >>>
> > >>>But as discussed in some of the previous posts, it does produces a
> > >>>"_main__.exe" when u run the ironpython on a *.py file so it
> > >>
> > >>is producing
> > >>
> > >>>IL like a c# compiler.
> > >>>
> > >>>Ab.
> > >>>
> > >>>On 4/13/05, reginald at rare-it.com < reginald at rare-it.com> wrote:
> > >>>
> > >>>>>csc = c# compiler
> > >>>>>vbc = vb.net compiler
> > >>>>>jsc = jscript compiler
> > >>>>>ipc = iron python compiler <<< 
> > >>>>>
> > >>>>>Ab.
> > >>>>
> > >>>>Nice suggestion, but IronPython is not a compiler (yet?).
> > >>>>
> > >>>>Reginald
> > >>>>
> > >>>> 
> > >>>>_______________________________________________
> > >>>>users-ironpython.com mailing list
> > >>>> users-ironpython.com at lists.ironpython.com
> >
> >>>>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> > >>>> 
> > >>>
> > >>>_______________________________________________
> > >>>users-ironpython.com mailing list
> > >>> users-ironpython.com at lists.ironpython.com
> >
> >>>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> > >>>
> > >>>_______________________________________________ 
> > >>>users-ironpython.com mailing list
> > >>>users-ironpython.com at lists.ironpython.com
> > >>>
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> > >>>
> > >>
> > >>
> > >>--
> > >>--
> > >>Travis Watkins 
> > >>http://www.realistanew.com
> > >>_______________________________________________
> > >>users-ironpython.com mailing list 
> > >>users-ironpython.com at lists.ironpython.com
> >
> >>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> > >>
> > >
> > >
> > > _______________________________________________
> > > users-ironpython.com mailing list
> > > users-ironpython.com at lists.ironpython.com
> > >
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> > 
> > _______________________________________________ 
> > users-ironpython.com mailing list
> > users-ironpython.com at lists.ironpython.com
> >
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> > 
> 
>  
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> 
>


From kfarmer at thuban.org  Thu Apr 14 23:39:21 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Thu, 14 Apr 2005 14:39:21 -0700
Subject: [IronPython] To Compile or Not to compile, that's the question
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C1369A9@nostromo.circle-cross.home>

My first reaction to "python.net.exe" is that nearly everyone would end
up wrapping it in a script:  it's long and complex.  IMHO, people like
short names, particularly if they follow a pre-established pattern (eg,
csc, fsc, plc, cc, etc).

My second is that "should not" and "will not" depend entirely on
copyright issues at worst, and association at best.  "Python.NET" and
"Python for .NET" -- who's going to come into the community and be able
to tell the difference?  There's also
http://www.zope.org/Members/Brian/PythonNet/, which Brian could tell you
about.

I think the name should be unique -- and short.

-----Original Message-----
From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Anthony Tarlano
Sent: Thursday, April 14, 2005 12:29 PM
To: Muhammad Abubakar; Discussion of IronPython
Subject: Re: [IronPython] To Compile or Not to compile, that's the
question

I still think the name python.net (i.e. python.net.exe) has not been
taken. 

ActiveState's 2001 python for .net,
http://www.activestate.com/Corporate/Initiatives/NET/Research.html,
should not preempt the use of the name, since they surely aren't doing
anything with it and only used the name for the zip not the name of
the project.



From richard.mh at mac.com  Fri Apr 15 00:51:54 2005
From: richard.mh at mac.com (Richard Monson-Haefel)
Date: Thu, 14 Apr 2005 17:51:54 -0500
Subject: [IronPython] Article on IronPython: Please Review
Message-ID: <75c965b029580d28e781709a1046ac05@mac.com>

Hi,

I just finished writing an article on IronPython for a magazine. If 
anyone is interested in reviewing it, let me know. I'm sure I got a 
couple things wrong somewhere. Anyway, its only 600 words and I would 
need comments back by midnight tonight.

You can reply to this e-mail or send to me directly at 
rmonson at burtongroup.com.

Thanks,

Richard Monson-Haefel



From luismg at gmx.net  Fri Apr 15 03:06:09 2005
From: luismg at gmx.net (Luis M. Gonzalez)
Date: Thu, 14 Apr 2005 22:06:09 -0300
Subject: [IronPython] Article on IronPython: Please Review 
Message-ID: <000601c54157$512a3d10$1302a8c0@luis>

Richard, why don't you post your article here so we all can read it?

Luis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050414/e3393db5/attachment.html>

From richard.mh at mac.com  Fri Apr 15 04:11:31 2005
From: richard.mh at mac.com (Richard Monson-Haefel)
Date: Thu, 14 Apr 2005 21:11:31 -0500
Subject: [IronPython] Article on IronPython: Please Review
In-Reply-To: <000601c54157$512a3d10$1302a8c0@luis>
References: <000601c54157$512a3d10$1302a8c0@luis>
Message-ID: <f3b432fabb8363e0b4d3fffe391edef1@mac.com>

Oh. Well, the magazine I'm writing the article for has first 
publication rights. If I posted it on a mailing list it would be like 
publishing it.  That's why I can't just send it out. Sorry.

On Apr 14, 2005, at 8:06 PM, Luis M. Gonzalez wrote:

> Richard, why don't you post your article here so we all can read it?
> ?
> Luis
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 664 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050414/ba424314/attachment.bin>

From mailinglist.account at gmail.com  Fri Apr 15 15:50:04 2005
From: mailinglist.account at gmail.com (Anthony Tarlano)
Date: Fri, 15 Apr 2005 15:50:04 +0200
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <C02467D265F3F64E87DED53F9C3DE29C1369A9@nostromo.circle-cross.home>
References: <C02467D265F3F64E87DED53F9C3DE29C1369A9@nostromo.circle-cross.home>
Message-ID: <f2b573190504150650da26154@mail.gmail.com>

Keith, 

All good points but,

I still don't see the problem, since you don't type the '.exe' part so
it is just 'python.net'

As for Brian's python for .NET, as good as I am sure it is, I really
have a hard time believing that any developer is going to have a hard
time telling the difference between IronPython and his..

Anthony


On 4/14/05, Keith J. Farmer <kfarmer at thuban.org> wrote:
> My first reaction to "python.net.exe" is that nearly everyone would end
> up wrapping it in a script:  it's long and complex.  IMHO, people like
> short names, particularly if they follow a pre-established pattern (eg,
> csc, fsc, plc, cc, etc).
> 
> My second is that "should not" and "will not" depend entirely on
> copyright issues at worst, and association at best.  "Python.NET" and
> "Python for .NET" -- who's going to come into the community and be able
> to tell the difference?  There's also
> http://www.zope.org/Members/Brian/PythonNet/, which Brian could tell you
> about.
> 
> I think the name should be unique -- and short.
> 
> -----Original Message-----
> From: users-ironpython.com-bounces at lists.ironpython.com
> [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
> Anthony Tarlano
> Sent: Thursday, April 14, 2005 12:29 PM
> To: Muhammad Abubakar; Discussion of IronPython
> Subject: Re: [IronPython] To Compile or Not to compile, that's the
> question
> 
> I still think the name python.net (i.e. python.net.exe) has not been
> taken.
> 
> ActiveState's 2001 python for .net,
> http://www.activestate.com/Corporate/Initiatives/NET/Research.html,
> should not preempt the use of the name, since they surely aren't doing
> anything with it and only used the name for the zip not the name of
> the project.
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From mailinglist.account at gmail.com  Fri Apr 15 18:25:15 2005
From: mailinglist.account at gmail.com (Anthony Tarlano)
Date: Fri, 15 Apr 2005 18:25:15 +0200
Subject: [IronPython] Working with System.Data.DataColumn[]
Message-ID: <f2b57319050415092550351018@mail.gmail.com>

To all:

Is there anyway to add a System.Data.DataColumn instance to the
PrimaryKey System.Data.DataColumn[] in IronPython??

Please see following code 

Thanks in advance..

Anthony




IronPython 0.7.2 on .NET 2.0.40607.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import sys
>>> sys.LoadAssemblyByName('System.Data')
>>> #--
()
>>>
()
>>> from System      import Type, Console
>>> from System.Data import DataSet, DataColumn
>>> dataset = DataSet('MySet')
>>> dataset.Tables.Add('Order')
Order
>>> dataset.Tables['Order'].Columns.Add('OrderID',
...                                          Type.GetType('System.Int32'))
...
OrderID
>>> dataset.Tables['Order'].Columns.Add('CustomerFirstName',
...                                          Type.GetType('System.String'))
...
CustomerFirstName
>>> dataset.Tables['Order'].Columns.Add('CustomerLastName',
...                                          Type.GetType('System.String'))
...
CustomerLastName
>>> dataset.Tables['Order'].PrimaryKey
System.Data.DataColumn[]()
>>> dataset.Tables['Order'].Columns['OrderID']
OrderID
>>> dataset.Tables['Order'].PrimaryKey[0] = dataset.Tables['Order'].Columns['Ord
erID']
System.IndexOutOfRangeException: Index was outside the bounds of the array.
   at System.Array.InternalSetValue(Object value, Int32 index1, Int32 index2, In
t32 index3)
   at System.Array.SetValue(Object value, Int32 index)
   at IronPython.Objects.ArrayOps.SetIndex(Array a, Object index, Object value)
   at IronPython.Objects.Ops.SetIndex(Object o, Object index, Object value)
   at IronPython.Objects.Ops.SetIndexStackHelper(Object value, Object o, Object
index)
   at input_13.Run(Frame frame)
   at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame)
   at IronPython.Hosting.PythonEngine.RunInteractive()
>>>


From kfarmer at thuban.org  Fri Apr 15 19:02:03 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Fri, 15 Apr 2005 10:02:03 -0700
Subject: [IronPython] To Compile or Not to compile, that's the question
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C1369AD@nostromo.circle-cross.home>

For a compiler, 4 characters is about my limit.  After all, it's all
about my code -- not the tool that is used to transform it into
something else.

And it's not matter of there being a hard time -- it's a matter of
muddying the issue.  You have to start prefixing when you start talking
about these things.  While namespaces and long names work well in
computer languages, they don't work well in human languages.

-----Original Message-----
From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Anthony Tarlano
Sent: Friday, April 15, 2005 6:50 AM

I still don't see the problem, since you don't type the '.exe' part so
it is just 'python.net'

As for Brian's python for .NET, as good as I am sure it is, I really
have a hard time believing that any developer is going to have a hard
time telling the difference between IronPython and his..



From nicolas.lehuen at gmail.com  Fri Apr 15 19:26:49 2005
From: nicolas.lehuen at gmail.com (Nicolas Lehuen)
Date: Fri, 15 Apr 2005 19:26:49 +0200
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <C02467D265F3F64E87DED53F9C3DE29C1369AD@nostromo.circle-cross.home>
References: <C02467D265F3F64E87DED53F9C3DE29C1369AD@nostromo.circle-cross.home>
Message-ID: <c298f2d705041510267ffe4ce5@mail.gmail.com>

Guys,

You've been typing tens of messages about a way to save a few
characters in the compiler/interpreter name. Given your investment in
keystrokes during the debate, the resulting name has better be
short...

Just kidding !

Regards,
Nicolas

On 4/15/05, Keith J. Farmer <kfarmer at thuban.org> wrote:
> For a compiler, 4 characters is about my limit.  After all, it's all
> about my code -- not the tool that is used to transform it into
> something else.
> 
> And it's not matter of there being a hard time -- it's a matter of
> muddying the issue.  You have to start prefixing when you start talking
> about these things.  While namespaces and long names work well in
> computer languages, they don't work well in human languages.
> 
> -----Original Message-----
> From: users-ironpython.com-bounces at lists.ironpython.com
> [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
> Anthony Tarlano
> Sent: Friday, April 15, 2005 6:50 AM
> 
> I still don't see the problem, since you don't type the '.exe' part so
> it is just 'python.net'
> 
> As for Brian's python for .NET, as good as I am sure it is, I really
> have a hard time believing that any developer is going to have a hard
> time telling the difference between IronPython and his..
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From joe at notcharles.ca  Fri Apr 15 18:47:05 2005
From: joe at notcharles.ca (Joe Mason)
Date: Fri, 15 Apr 2005 12:47:05 -0400
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <C02467D265F3F64E87DED53F9C3DE29C1369AD@nostromo.circle-cross.home>
References: <C02467D265F3F64E87DED53F9C3DE29C1369AD@nostromo.circle-cross.home>
Message-ID: <20050415164705.GA4336@notcharles.ca>

On Fri, Apr 15, 2005 at 10:02:03AM -0700, Keith J. Farmer wrote:
> For a compiler, 4 characters is about my limit.  After all, it's all
> about my code -- not the tool that is used to transform it into
> something else.

You type the name of the compiler by hand a lot?  Wouldn't it be invoked
from a Makefile or IDE 90% of the time?

Besides, if you really object to a name longer than 4 characters, you
can always make an alias, but if there's a name class, it's harder to
alias from an ambiguous name to a non-ambiguous one.  So it's better to
err on the side of non-ambiguity.

Joe


From kfarmer at thuban.org  Fri Apr 15 21:11:03 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Fri, 15 Apr 2005 12:11:03 -0700
Subject: [IronPython] To Compile or Not to compile, that's the question
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F8D@nostromo.circle-cross.home>

People have been objecting to "IronPythonConsole" this whole time.  If it were a matter of "just make an alias", then this discussion was moot from the beginning.  For that matter, it was moot from before CSharpCompiler, CCompiler, or GnuCCompiler were created.
 
So I don't think that it's as simple for those who originally raised their objections.  I think the aim is for consistency, so we don't have to set aliases to use someone else's makefile.
 
(Personally, I never objected to IronPythonConsole -- but if there's a movement to change it, I still say change it to be in line with the other existing naming patterns.)

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Joe Mason
Sent: Fri 4/15/2005 9:47 AM
To: Discussion of IronPython
Subject: Re: [IronPython] To Compile or Not to compile, that's the question



On Fri, Apr 15, 2005 at 10:02:03AM -0700, Keith J. Farmer wrote:
> For a compiler, 4 characters is about my limit.  After all, it's all
> about my code -- not the tool that is used to transform it into
> something else.

You type the name of the compiler by hand a lot?  Wouldn't it be invoked
from a Makefile or IDE 90% of the time?

Besides, if you really object to a name longer than 4 characters, you
can always make an alias, but if there's a name class, it's harder to
alias from an ambiguous name to a non-ambiguous one.  So it's better to
err on the side of non-ambiguity.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 4563 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050415/c5cf12b3/attachment.bin>

From mailinglist.account at gmail.com  Sat Apr 16 10:41:59 2005
From: mailinglist.account at gmail.com (Anthony Tarlano)
Date: Sat, 16 Apr 2005 10:41:59 +0200
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <C02467D265F3F64E87DED53F9C3DE29C7F8D@nostromo.circle-cross.home>
References: <C02467D265F3F64E87DED53F9C3DE29C7F8D@nostromo.circle-cross.home>
Message-ID: <f2b5731905041601411b45f708@mail.gmail.com>

Keith,

I don't think we are naming a compiler, but naming an interpreter. 

I am a long time Python (CPython) and Jython user and during
development. I never use an Ide other then Xemacs and in the shell
window I use the interpreter as a matter of productivity.

So, given this background information, I am sure that you can see that
you are talking about 'Apples' and I am talking about 'Oranges'. Since
your usage pattern is an IDE and a Makefile, then your alias solution
is fine, but since I will consistantly be firing up a shell window and
typing the name of the interpreter, I want 'python.net' since I am
used to typing 'python' and 'jython'.

Thanks,

Anthony






On 4/15/05, Keith J. Farmer <kfarmer at thuban.org> wrote:
> People have been objecting to "IronPythonConsole" this whole time.  If it were a matter of "just make an alias", then this discussion was moot from the beginning.  For that matter, it was moot from before CSharpCompiler, CCompiler, or GnuCCompiler were created.
> 
> So I don't think that it's as simple for those who originally raised their objections.  I think the aim is for consistency, so we don't have to set aliases to use someone else's makefile.
> 
> (Personally, I never objected to IronPythonConsole -- but if there's a movement to change it, I still say change it to be in line with the other existing naming patterns.)
> 
> ________________________________
> 
> From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Joe Mason
> Sent: Fri 4/15/2005 9:47 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] To Compile or Not to compile, that's the question
> 
> On Fri, Apr 15, 2005 at 10:02:03AM -0700, Keith J. Farmer wrote:
> > For a compiler, 4 characters is about my limit.  After all, it's all
> > about my code -- not the tool that is used to transform it into
> > something else.
> 
> You type the name of the compiler by hand a lot?  Wouldn't it be invoked
> from a Makefile or IDE 90% of the time?
> 
> Besides, if you really object to a name longer than 4 characters, you
> can always make an alias, but if there's a name class, it's harder to
> alias from an ambiguous name to a non-ambiguous one.  So it's better to
> err on the side of non-ambiguity.
> 
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> 
>


From abubakarm at gmail.com  Sun Apr 17 08:53:44 2005
From: abubakarm at gmail.com (Muhammad Abubakar)
Date: Sun, 17 Apr 2005 11:53:44 +0500
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <f2b5731905041601411b45f708@mail.gmail.com>
References: <C02467D265F3F64E87DED53F9C3DE29C7F8D@nostromo.circle-cross.home>
	<f2b5731905041601411b45f708@mail.gmail.com>
Message-ID: <c40f6d35050416235372bd8d45@mail.gmail.com>

I have noticed that on windows world ppl are more used to using some
sort of ide but on linux/unix world ppl (hackers?) like to do a lot on
just shell using the name of the things they use. Since u r used to
typing python and jython what do u say about "ipc"?

Ab.

On 4/16/05, Anthony Tarlano <mailinglist.account at gmail.com> wrote:
> Keith,
> 
> I don't think we are naming a compiler, but naming an interpreter.
> 
> I am a long time Python (CPython) and Jython user and during
> development. I never use an Ide other then Xemacs and in the shell
> window I use the interpreter as a matter of productivity.
> 
> So, given this background information, I am sure that you can see that
> you are talking about 'Apples' and I am talking about 'Oranges'. Since
> your usage pattern is an IDE and a Makefile, then your alias solution
> is fine, but since I will consistantly be firing up a shell window and
> typing the name of the interpreter, I want 'python.net' since I am
> used to typing 'python' and 'jython'.
> 
> Thanks,
> 
> Anthony
> 
> 
> On 4/15/05, Keith J. Farmer <kfarmer at thuban.org> wrote:
> > People have been objecting to "IronPythonConsole" this whole time.  If it were a matter of "just make an alias", then this discussion was moot from the beginning.  For that matter, it was moot from before CSharpCompiler, CCompiler, or GnuCCompiler were created.
> >
> > So I don't think that it's as simple for those who originally raised their objections.  I think the aim is for consistency, so we don't have to set aliases to use someone else's makefile.
> >
> > (Personally, I never objected to IronPythonConsole -- but if there's a movement to change it, I still say change it to be in line with the other existing naming patterns.)
> >
> > ________________________________
> >
> > From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Joe Mason
> > Sent: Fri 4/15/2005 9:47 AM
> > To: Discussion of IronPython
> > Subject: Re: [IronPython] To Compile or Not to compile, that's the question
> >
> > On Fri, Apr 15, 2005 at 10:02:03AM -0700, Keith J. Farmer wrote:
> > > For a compiler, 4 characters is about my limit.  After all, it's all
> > > about my code -- not the tool that is used to transform it into
> > > something else.
> >
> > You type the name of the compiler by hand a lot?  Wouldn't it be invoked
> > from a Makefile or IDE 90% of the time?
> >
> > Besides, if you really object to a name longer than 4 characters, you
> > can always make an alias, but if there's a name class, it's harder to
> > alias from an ambiguous name to a non-ambiguous one.  So it's better to
> > err on the side of non-ambiguity.
> >
> >
> > _______________________________________________
> > users-ironpython.com mailing list
> > users-ironpython.com at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> >
> >
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From swaroopch at gmail.com  Sun Apr 17 09:04:48 2005
From: swaroopch at gmail.com (Swaroop C H)
Date: Sun, 17 Apr 2005 12:34:48 +0530
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <c40f6d35050416235372bd8d45@mail.gmail.com>
References: <C02467D265F3F64E87DED53F9C3DE29C7F8D@nostromo.circle-cross.home>
	<f2b5731905041601411b45f708@mail.gmail.com>
	<c40f6d35050416235372bd8d45@mail.gmail.com>
Message-ID: <351e88710504170004cc0b045@mail.gmail.com>

On 4/17/05, Muhammad Abubakar <abubakarm at gmail.com> wrote:
> I have noticed that on windows world ppl are more used to using some
> sort of ide but on linux/unix world ppl (hackers?) like to do a lot on
> just shell using the name of the things they use. Since u r used to
> typing python and jython what do u say about "ipc"?

"ipc" is just too cryptic.

Why isn't just "ironpython" good enough for everybody?.
If the command-line guys are worried about number of characters, I
assure you that there is such a thing as tab completion.

This name debate seems to be going on and on. I wish Jim would just
pronounce something and be done with it ;-)

Cheers,
-- 
Swaroop C H
Blog: http://www.swaroopch.info
Book: http://www.byteofpython.info


From innesm at gmail.com  Sun Apr 17 11:55:08 2005
From: innesm at gmail.com (Innes MacKenzie)
Date: Sun, 17 Apr 2005 10:55:08 +0100
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <351e88710504170004cc0b045@mail.gmail.com>
References: <C02467D265F3F64E87DED53F9C3DE29C7F8D@nostromo.circle-cross.home>
	<f2b5731905041601411b45f708@mail.gmail.com>
	<c40f6d35050416235372bd8d45@mail.gmail.com>
	<351e88710504170004cc0b045@mail.gmail.com>
Message-ID: <db7def6705041702555ffb0d9c@mail.gmail.com>

On 4/17/05, Swaroop C H <swaroopch at gmail.com> wrote:
> "ipc" is just too cryptic.

What about 'dir', 'cd', 'csc'?
 
> Why isn't just "ironpython" good enough for everybody?.

I hear there's a current thread on the subject, on the iron-python
mailing list. This may be a useful source for finding out peoples'
opinions. :-)

> If the command-line guys are worried about number of characters, I
> assure you that there is such a thing as tab completion.

That only works on files relative to the current directory, or on
absolute paths.
But anyway, if you're not a commandline guy why would you be bothered
what the compiler/interpreter is called?

> This name debate seems to be going on and on. I wish Jim would just
> pronounce something and be done with it ;-)

So, let me recap, you dont actually care one way or the other, are
growing bored with the debate, havent absorbed anyone's views, and
decided to chip in nonetheless? ;-)


From joe at notcharles.ca  Sun Apr 17 11:18:06 2005
From: joe at notcharles.ca (Joe Mason)
Date: Sun, 17 Apr 2005 05:18:06 -0400
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <db7def6705041702555ffb0d9c@mail.gmail.com>
References: <C02467D265F3F64E87DED53F9C3DE29C7F8D@nostromo.circle-cross.home>
	<f2b5731905041601411b45f708@mail.gmail.com>
	<c40f6d35050416235372bd8d45@mail.gmail.com>
	<351e88710504170004cc0b045@mail.gmail.com>
	<db7def6705041702555ffb0d9c@mail.gmail.com>
Message-ID: <20050417091806.GA10408@notcharles.ca>

On Sun, Apr 17, 2005 at 10:55:08AM +0100, Innes MacKenzie wrote:
> On 4/17/05, Swaroop C H <swaroopch at gmail.com> wrote:
> > "ipc" is just too cryptic.
> 
> What about 'dir', 'cd', 'csc'?

The first two are historical, and it's too late to change them.  The
third is just stupid.

> > If the command-line guys are worried about number of characters, I
> > assure you that there is such a thing as tab completion.
> 
> That only works on files relative to the current directory, or on
> absolute paths.

What?  What OS are you talking about?  On Linux it works everywhere,
even searching $PATH.  On Windows, why does it matter?  Don't you just
associate .py with the executable and doubleclick it?

Joe 


From sriramk at gmail.com  Sun Apr 17 12:16:25 2005
From: sriramk at gmail.com (Sriram Krishnan)
Date: Sun, 17 Apr 2005 15:46:25 +0530
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <20050417091806.GA10408@notcharles.ca>
Message-ID: <42623782.6aac9a32.2c70.ffffadf3@mx.gmail.com>

Joe Mason wrote:

> 
> What?  What OS are you talking about?  On Linux it works everywhere,
> even searching $PATH.  On Windows, why does it matter?  Don't you
> just associate .py with the executable and doubleclick it?  
> 

It's the same on Windows - tab completion in your command prompt searches
through your PATH environment variable

Sriram



From innesm at gmail.com  Sun Apr 17 12:32:21 2005
From: innesm at gmail.com (Innes MacKenzie)
Date: Sun, 17 Apr 2005 11:32:21 +0100
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <42623782.6aac9a32.2c70.ffffadf3@mx.gmail.com>
References: <20050417091806.GA10408@notcharles.ca>
	<42623782.6aac9a32.2c70.ffffadf3@mx.gmail.com>
Message-ID: <db7def67050417033295da23e@mail.gmail.com>

On 4/17/05, Sriram Krishnan <sriramk at gmail.com> wrote:
> Joe Mason wrote:
> 
> >
> > What?  What OS are you talking about?  On Linux it works everywhere,
> > even searching $PATH.  On Windows, why does it matter?  Don't you
> > just associate .py with the executable and doubleclick it?
> >
> 
> It's the same on Windows - tab completion in your command prompt searches
> through your PATH environment variable

Not on my XP laptop it doesnt.


From innesm at gmail.com  Sun Apr 17 12:49:31 2005
From: innesm at gmail.com (Innes MacKenzie)
Date: Sun, 17 Apr 2005 11:49:31 +0100
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <20050417091806.GA10408@notcharles.ca>
References: <C02467D265F3F64E87DED53F9C3DE29C7F8D@nostromo.circle-cross.home>
	<f2b5731905041601411b45f708@mail.gmail.com>
	<c40f6d35050416235372bd8d45@mail.gmail.com>
	<351e88710504170004cc0b045@mail.gmail.com>
	<db7def6705041702555ffb0d9c@mail.gmail.com>
	<20050417091806.GA10408@notcharles.ca>
Message-ID: <db7def67050417034971d6b356@mail.gmail.com>

On 4/17/05, Joe Mason <joe at notcharles.ca> wrote:
> On Sun, Apr 17, 2005 at 10:55:08AM +0100, Innes MacKenzie wrote:
> > On 4/17/05, Swaroop C H <swaroopch at gmail.com> wrote:
> > > "ipc" is just too cryptic.
> >
> > What about 'dir', 'cd', 'csc'?
> 
> The first two are historical, and it's too late to change them.  The
> third is just stupid.

So they ought to be ListDirectoryContents, ChangeDirectory, and
CSharpCompiler. Hrmm.
(NB: I believe monad implements short names as aliases, maybe
ironpythonwhateveritis.exe can be aliased as part of the default
install, so everyone can rely on the alias, but the more flowery and
discursive amongst us can use the long form. Or are there downsides to
that, I wonder?)

> 
> > > If the command-line guys are worried about number of characters, I
> > > assure you that there is such a thing as tab completion.
> >
> > That only works on files relative to the current directory, or on
> > absolute paths.
> 
> What? 

Ahem. That only works on... oh I see, rhetorical.

> What OS are you talking about?  On Linux it works everywhere,
> even searching $PATH.

Point made.

>On Windows, why does it matter?  Don't you just
> associate .py with the executable and doubleclick it?

Yes, I have .cs associated with csc so I can compile my C# projects
simply by doubleclicking!
(just kidding)


From sriramk at gmail.com  Sun Apr 17 12:57:45 2005
From: sriramk at gmail.com (Sriram Krishnan)
Date: Sun, 17 Apr 2005 16:27:45 +0530
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <db7def67050417033295da23e@mail.gmail.com>
Message-ID: <42624132.0f0cb89f.7b2e.ffffa1f9@mx.gmail.com>

Innes MacKenzie wrote:

> Not on my XP laptop it doesnt.


Oops - sorry - was using another shell when I tested this out.My bad.

Sriram



From joe at notcharles.ca  Sun Apr 17 14:10:37 2005
From: joe at notcharles.ca (Joe Mason)
Date: Sun, 17 Apr 2005 08:10:37 -0400
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <db7def67050417034971d6b356@mail.gmail.com>
References: <C02467D265F3F64E87DED53F9C3DE29C7F8D@nostromo.circle-cross.home>
	<f2b5731905041601411b45f708@mail.gmail.com>
	<c40f6d35050416235372bd8d45@mail.gmail.com>
	<351e88710504170004cc0b045@mail.gmail.com>
	<db7def6705041702555ffb0d9c@mail.gmail.com>
	<20050417091806.GA10408@notcharles.ca>
	<db7def67050417034971d6b356@mail.gmail.com>
Message-ID: <20050417121037.GA11233@notcharles.ca>

On Sun, Apr 17, 2005 at 11:49:31AM +0100, Innes MacKenzie wrote:
> On 4/17/05, Joe Mason <joe at notcharles.ca> wrote:
> > On Sun, Apr 17, 2005 at 10:55:08AM +0100, Innes MacKenzie wrote:
> > > On 4/17/05, Swaroop C H <swaroopch at gmail.com> wrote:
> > > > "ipc" is just too cryptic.
> > >
> > > What about 'dir', 'cd', 'csc'?
> > 
> > The first two are historical, and it's too late to change them.  The
> > third is just stupid.
> 
> So they ought to be ListDirectoryContents, ChangeDirectory, and
> CSharpCompiler. Hrmm.

I like "ldir", "chdir" and "csharp", myself, but the point is that having
a tradition of cryptic names is no reason to be cryptic for the sake of
it.  I haven't seen any argument for "ipc" except, "I will be typing it
a lot so it has to be less than 4 letters."

> > What OS are you talking about?  On Linux it works everywhere,
> > even searching $PATH.
> 
> Point made.

I wasn't trying to say, "Linux is better, hurr hurr!"  I was trying to
figure out if you were talking about Linux and just incorrect, or
talking about Windows, in which case I don't see why tab completion
matters.  Because...

> >On Windows, why does it matter?  Don't you just
> > associate .py with the executable and doubleclick it?
> 
> Yes, I have .cs associated with csc so I can compile my C# projects
> simply by doubleclicking!
> (just kidding)

I'm honestly trying to figure out why you intend to be typing the name
of a Python to .NET compiler often.  Even on Linux, where I use the
command line for everything, 90% of the time the compiler is invoked by
a Makefile so I only have to type its name once.  On Windows I was under
the impression that the compiler is always invoked by an IDE so you have
to type it's name even less often.  So - are you telling me you actually
compile C# projects by opening a window and typing "csc
somefilename.cs"?  If so, why?

When I talked about double-clicking .py files, I was confused and
thought we were still talking about the interpreter name, where a short
name is slightly more important.  But still, TAB-completion on Linux and
file association on Windows takes most of the burden off.

Joe


From drew at astro.pas.rochester.edu  Sun Apr 17 16:35:33 2005
From: drew at astro.pas.rochester.edu (Drew Moore)
Date: Sun, 17 Apr 2005 10:35:33 -0400
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <c40f6d35050416235372bd8d45@mail.gmail.com>
References: <C02467D265F3F64E87DED53F9C3DE29C7F8D@nostromo.circle-cross.home>	<f2b5731905041601411b45f708@mail.gmail.com>
	<c40f6d35050416235372bd8d45@mail.gmail.com>
Message-ID: <42627435.6000509@astro.pas.rochester.edu>

how bout 'prom' for "Python Running On Mono" ?
maybe 'porn' for Python On Runtime-.Net"?
;-)

I type 'mkae' a lot, so I'm all for short names.

Drew


From abubakarm at gmail.com  Mon Apr 18 06:37:10 2005
From: abubakarm at gmail.com (Muhammad Abubakar)
Date: Mon, 18 Apr 2005 09:37:10 +0500
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <20050417121037.GA11233@notcharles.ca>
References: <C02467D265F3F64E87DED53F9C3DE29C7F8D@nostromo.circle-cross.home>
	<f2b5731905041601411b45f708@mail.gmail.com>
	<c40f6d35050416235372bd8d45@mail.gmail.com>
	<351e88710504170004cc0b045@mail.gmail.com>
	<db7def6705041702555ffb0d9c@mail.gmail.com>
	<20050417091806.GA10408@notcharles.ca>
	<db7def67050417034971d6b356@mail.gmail.com>
	<20050417121037.GA11233@notcharles.ca>
Message-ID: <c40f6d350504172137337587ed@mail.gmail.com>

> to type it's name even less often.  So - are you telling me you actually
> compile C# projects by opening a window and typing "csc
> somefilename.cs"?  If so, why?

in my observation: it often happens that microsoft releases SDKs
before visual studios (betas), and when they release it, its usually
only available for the msdn subscribers where as the sdk is
downloadable for all. So in order to experiment (which may go on for
months for some) ppl have to write csc on console and write source on
the notepad. And there are ppl who just dont buy vs.net but try the
.net framework through sdks, later on thay may decide to buy the ide.
So these can be some of the reasons why ppl think about doing a csc
somefilename.cs.

> When I talked about double-clicking .py files, I was confused and
> thought we were still talking about the interpreter name, where a short
> name is slightly more important.  But still, TAB-completion on Linux and
> file association on Windows takes most of the burden off.

about file associations, few things that come to my mind are that as
far as *.txt or *.doc is concerned, associating to notepad and
microsoft word respectively makes sense but can we associate *.cs with
csc.exe (or mcs of mono on windows) or *.vb to vbc.exe or mbas.exe in
mono-on-windows? I would say no definitely, cuz there are some obvious
reasons that we have multiple files which contains our source code and
we may have to pass tens of /r switches to the compiler etc. Now due
to my ignorance of working with scripting languages u guys tell me do
we need to associate *.py files with the compiler/interpreter or like
in case of *.cs or *.vb, just associate them with the IDE? Are we not
going to be writing python apps whose source is going to spans to more
than one file like c#?

Ab.

On 4/17/05, Joe Mason <joe at notcharles.ca> wrote:
> On Sun, Apr 17, 2005 at 11:49:31AM +0100, Innes MacKenzie wrote:
> > On 4/17/05, Joe Mason <joe at notcharles.ca> wrote:
> > > On Sun, Apr 17, 2005 at 10:55:08AM +0100, Innes MacKenzie wrote:
> > > > On 4/17/05, Swaroop C H <swaroopch at gmail.com> wrote:
> > > > > "ipc" is just too cryptic.
> > > >
> > > > What about 'dir', 'cd', 'csc'?
> > >
> > > The first two are historical, and it's too late to change them.  The
> > > third is just stupid.
> >
> > So they ought to be ListDirectoryContents, ChangeDirectory, and
> > CSharpCompiler. Hrmm.
> 
> I like "ldir", "chdir" and "csharp", myself, but the point is that having
> a tradition of cryptic names is no reason to be cryptic for the sake of
> it.  I haven't seen any argument for "ipc" except, "I will be typing it
> a lot so it has to be less than 4 letters."
> 
> > > What OS are you talking about?  On Linux it works everywhere,
> > > even searching $PATH.
> >
> > Point made.
> 
> I wasn't trying to say, "Linux is better, hurr hurr!"  I was trying to
> figure out if you were talking about Linux and just incorrect, or
> talking about Windows, in which case I don't see why tab completion
> matters.  Because...
> 
> > >On Windows, why does it matter?  Don't you just
> > > associate .py with the executable and doubleclick it?
> >
> > Yes, I have .cs associated with csc so I can compile my C# projects
> > simply by doubleclicking!
> > (just kidding)
> 
> I'm honestly trying to figure out why you intend to be typing the name
> of a Python to .NET compiler often.  Even on Linux, where I use the
> command line for everything, 90% of the time the compiler is invoked by
> a Makefile so I only have to type its name once.  On Windows I was under
> the impression that the compiler is always invoked by an IDE so you have
> to type it's name even less often.  So - are you telling me you actually
> compile C# projects by opening a window and typing "csc
> somefilename.cs"?  If so, why?
> 
> When I talked about double-clicking .py files, I was confused and
> thought we were still talking about the interpreter name, where a short
> name is slightly more important.  But still, TAB-completion on Linux and
> file association on Windows takes most of the burden off.
> 
> Joe
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From abubakarm at gmail.com  Mon Apr 18 07:54:36 2005
From: abubakarm at gmail.com (Muhammad Abubakar)
Date: Mon, 18 Apr 2005 10:54:36 +0500
Subject: [IronPython] vs.net 2k5 beta 2 available
In-Reply-To: <c40f6d350504172137337587ed@mail.gmail.com>
References: <C02467D265F3F64E87DED53F9C3DE29C7F8D@nostromo.circle-cross.home>
	<f2b5731905041601411b45f708@mail.gmail.com>
	<c40f6d35050416235372bd8d45@mail.gmail.com>
	<351e88710504170004cc0b045@mail.gmail.com>
	<db7def6705041702555ffb0d9c@mail.gmail.com>
	<20050417091806.GA10408@notcharles.ca>
	<db7def67050417034971d6b356@mail.gmail.com>
	<20050417121037.GA11233@notcharles.ca>
	<c40f6d350504172137337587ed@mail.gmail.com>
Message-ID: <c40f6d3505041722547e949681@mail.gmail.com>

Hi all,
VS.net 2k5 Beta 2 available: check out
http://lab.msdn.microsoft.com/vs2005/get/.

Ab.
http://joehacker.blogspot.com


From kfarmer at thuban.org  Tue Apr 19 05:27:38 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Mon, 18 Apr 2005 20:27:38 -0700
Subject: [IronPython] To Compile or Not to compile, that's the question
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C1369B4@nostromo.circle-cross.home>

And let's be honest: VS.NET doesn't work on every platform that
IronPython is likely to live on.

-----Original Message-----
From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Muhammad Abubakar
Sent: Sunday, April 17, 2005 9:37 PM
To: Discussion of IronPython
Subject: Re: [IronPython] To Compile or Not to compile, that's the
question

> to type it's name even less often.  So - are you telling me you
actually
> compile C# projects by opening a window and typing "csc
> somefilename.cs"?  If so, why?



From kfarmer at thuban.org  Tue Apr 19 23:08:18 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Tue, 19 Apr 2005 14:08:18 -0700
Subject: [IronPython] (MS/Beta2) System.Collections.Generic.List bug?
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F8F@nostromo.circle-cross.home>

[Incidentally, the ".NET" in the version info is hardcoded -- is there a means to pick up the full name of the environment, rather than just the version?  This would allow more accurate reporting between MS and 3rd party CLR implementations.]
 
IronPython 0.7.2 on .NET 2.0.50215.44
Copyright (c) Microsoft Corporation. All rights reserved.
>>> from System.Collections.Generic import List
>>> __dict__
{'List':<type 'System.Collections.Generic.List`1'>}
>>> list = List[str]
>>> list
<type 'System.Collections.Generic.List`1[[System.String, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]'>
>>> list.Add(1)
System.Exception: bad args to this method <method# Add on System.Collections.Generic.List`1[[System.String, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]>
   at IronPython.Objects.ReflectedMethodBase.Call(Object[] args)
   at IronPython.Objects.Ops.Call(Object func, Object arg0)
   at input_4.Run(Frame frame)
   at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame)
   at IronPython.Hosting.PythonEngine.RunInteractive()
>>> list.Add("abc")
System.Exception: bad args to this method <method# Add on System.Collections.Generic.List`1[[System.String, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]>
   at IronPython.Objects.ReflectedMethodBase.Call(Object[] args)
   at IronPython.Objects.Ops.Call(Object func, Object arg0)
   at input_5.Run(Frame frame)
   at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame)
   at IronPython.Hosting.PythonEngine.RunInteractive()
>>> list.Add('abc')
System.Exception: bad args to this method <method# Add on System.Collections.Generic.List`1[[System.String, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]>
   at IronPython.Objects.ReflectedMethodBase.Call(Object[] args)
   at IronPython.Objects.Ops.Call(Object func, Object arg0)
   at input_6.Run(Frame frame)
   at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame)
   at IronPython.Hosting.PythonEngine.RunInteractive()
>>>


From richard.mh at mac.com  Wed Apr 20 00:04:14 2005
From: richard.mh at mac.com (Richard Monson-Haefel)
Date: Tue, 19 Apr 2005 17:04:14 -0500
Subject: [IronPython] vs.net 2k5 beta 2 available
In-Reply-To: <c40f6d3505041722547e949681@mail.gmail.com>
References: <C02467D265F3F64E87DED53F9C3DE29C7F8D@nostromo.circle-cross.home>
	<f2b5731905041601411b45f708@mail.gmail.com>
	<c40f6d35050416235372bd8d45@mail.gmail.com>
	<351e88710504170004cc0b045@mail.gmail.com>
	<db7def6705041702555ffb0d9c@mail.gmail.com>
	<20050417091806.GA10408@notcharles.ca>
	<db7def67050417034971d6b356@mail.gmail.com>
	<20050417121037.GA11233@notcharles.ca>
	<c40f6d350504172137337587ed@mail.gmail.com>
	<c40f6d3505041722547e949681@mail.gmail.com>
Message-ID: <243c2aec4046d9d6b0e1cb8a00576cd9@mac.com>

If memory services me correct, VS.NET 2005 is supposed to provide hooks 
that allow you extend the platform to support other languages in terms 
of compiling, syntax highlighting, debugging, etc.  Does the IronPython 
team intend to release a plug-in for the IronPython language?


On Apr 18, 2005, at 12:54 AM, Muhammad Abubakar wrote:

> Hi all,
> VS.net 2k5 Beta 2 available: check out
> http://lab.msdn.microsoft.com/vs2005/get/.
>
> Ab.
> http://joehacker.blogspot.com
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From jimhug at exchange.microsoft.com  Wed Apr 20 00:31:02 2005
From: jimhug at exchange.microsoft.com (Jim Hugunin)
Date: Tue, 19 Apr 2005 15:31:02 -0700
Subject: [IronPython] (MS/Beta2) System.Collections.Generic.List bug?
Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201AD9146@df-fido-msg.exchange.corp.microsoft.com>

Keith J. Farmer wrote:
> [Incidentally, the ".NET" in the version info is hardcoded -- is there
a
> means to pick up the full name of the environment, rather than just
the
> version?  This would allow more accurate reporting between MS and 3rd
> party CLR implementations.]

We're using System.Environment.Version to get the version number.  I
don't know any way to get a string specifying the implementation.  I'll
ask around and see what I can find.

> IronPython 0.7.2 on .NET 2.0.50215.44
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> from System.Collections.Generic import List
> >>> list = List[str]
> >>> list
> <type 'System.Collections.Generic.List`1[[System.String, mscorlib,
> Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]'>
> >>> list.Add("abc")
> System.Exception: bad args to this method <method# Add on
> System.Collections.Generic.List`1[[System.String, mscorlib,

I also always make this mistake when using generics in IronPython.  It's
so common it might indicate we need to think about tweaking the design.
At the very least we should work on the error message.

List[str] returns a new type object List<String>.  When you print it
above you can see that it's a type rather than an instance.  You're
treating this like it's an instance of a list.  You need to make an
instance first:
>>> l = list()
>>> l.Add('hi')
>>> l.Add(2)
System.Exception: bad args to this method <method# Add on <snip>

Ordinarily you'll do this all as one call, i.e. "l = List[str]()".

In case you're unfamiliar with Python's unbound methods, these are
instance methods exposed on the class that you can call with an instance
as the first argument, i.e.
>>> list.Add(l, 'bye')

This is a part of Python's object model that we're trying to reflect
accurately in the .NET world.

I hope this answers your question - Jim


From kfarmer at thuban.org  Wed Apr 20 01:09:44 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Tue, 19 Apr 2005 16:09:44 -0700
Subject: [IronPython] (MS/Beta2) System.Collections.Generic.List bug?
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F90@nostromo.circle-cross.home>

This is what I get for not having enough sleep.  I was doing this just fine a week ago -- glad to hear it wasn't some sudden breakage.
 
Forgot about those unbound methods..  Been ages since I've done foo(self, arg).
 
Re Environment:  If there isn't anything, it may be something to prod the Framework folk into adding to System.Environment.  I'm sure it'll save headaches along the lines of those error messages with the word "Microsoft" that got excised recently.  No need to have MS tracking down Ximian's bugs.

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Jim Hugunin
Sent: Tue 4/19/2005 3:31 PM
To: Discussion of IronPython
Subject: RE: [IronPython] (MS/Beta2) System.Collections.Generic.List bug?

We're using System.Environment.Version to get the version number.  I
don't know any way to get a string specifying the implementation.  I'll
ask around and see what I can find.

[...]
 
List[str] returns a new type object List<String>.  When you print it
above you can see that it's a type rather than an instance.  You're
treating this like it's an instance of a list.  You need to make an
instance first:
>>> l = list()
>>> l.Add('hi')
>>> l.Add(2)
System.Exception: bad args to this method <method# Add on <snip>

Ordinarily you'll do this all as one call, i.e. "l = List[str]()".

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 4945 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050419/5fca58a7/attachment.bin>

From jtenney at alum.mit.edu  Sun Apr 10 22:21:50 2005
From: jtenney at alum.mit.edu (John A. Tenney)
Date: Sun, 10 Apr 2005 13:21:50 -0700
Subject: [IronPython] Adding dynamic scripting to an existing .NET
	application
Message-ID: <20050410202156.E4BDA84D0B@che.dreamhost.com>

I'd like to be able to script up a .NET app that I have-say, for example, by
bringing up a dialog in which they can interact with existing objects in the
environment. 

 

At first blush, it works fine. However, it seems that, even though an
assembly is already loaded, that in order to create a new object in that
assembly from the IronPython command line, I still have to issue a
"sys.LoadAssembly." command. This loads up all the types a second time, but
doesn't use the existing types. As a result it reinitializes all static
variables, which is undesirable. Any solutions to this problem? Is there
some way that IronPython can work with an assembly that is already loaded?

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050410/a724c938/attachment.html>

From jtenney at alum.mit.edu  Tue Apr 12 21:39:36 2005
From: jtenney at alum.mit.edu (John A. Tenney)
Date: Tue, 12 Apr 2005 12:39:36 -0700
Subject: [IronPython] Questions for FAQ or User Guide
Message-ID: <20050412194525.5115E84D22@che.dreamhost.com>

1.	I'd like to pass an array of 6 doubles to a method, but get an error
message. For example, the "myMethod" call below fails when it requires a
double array.

array=[1, 2, 3.5, 4]

myObject.myMethod(array)

2.	I'd like to invoke an overloaded operator, or it's backing op_xxx
method. For example, both of these fail:

myComplex = myComplex1 + myComplex2

myComplex = Complex.op_Addition(myComplex1, myComplex2) 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050412/d9c6adb7/attachment.html>

From skolgan at cox.net  Thu Apr 14 01:24:38 2005
From: skolgan at cox.net (Serge Kolgan)
Date: Wed, 13 Apr 2005 19:24:38 -0400
Subject: [IronPython] To Compile or Not to compile, that's the question
In-Reply-To: <C02467D265F3F64E87DED53F9C3DE29C7F8A@nostromo.circle-cross.home>
Message-ID: <20050413232154.TDKU21504.lakermmtao06.cox.net@geforce>

 
pyc.exe is a popular on-the-fly convertor of English letters being typed on
a keyboard into Cyrillic fonts on the screen(being Russian myself I just
read what Google brought up).
 
I'd suggest ipyc.exe ( pronounced much like HP's IPAQ :) )

Best regards -

Serge Kolgan       (skolgan @ cox.net) 

 

 



  _____  

From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Keith J. Farmer
Sent: Wednesday, April 13, 2005 6:44 PM
To: Discussion of IronPython
Subject: RE: [IronPython] To Compile or Not to compile, that's the question


Google found references to a pyc.exe, and none in English.
 
+1

  _____  

From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Brian
Lloyd
Sent: Wed 4/13/2005 3:38 PM
To: Travis Watkins; Discussion of IronPython
Subject: RE: [IronPython] To Compile or Not to compile, that's the question



I can't believe nobody is lobbying for pyc.exe  ;)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3934 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050413/285cf0fe/attachment.bin>

From martmaly at exchange.microsoft.com  Wed Apr 20 01:36:37 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Tue, 19 Apr 2005 16:36:37 -0700
Subject: [IronPython] Questions for FAQ or User Guide
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701BCB8E7@df-chewy-msg.exchange.corp.microsoft.com>



>>> John A. Tenney Wrote:
>>>
>>> 1. I'd like to pass an array of 6 doubles to a method, but get an
error message.
>>> For example, the "myMethod" call below fails when it requires a
double array.
>>> array=[1, 2, 3.5, 4]
>>> myObject.myMethod(array)

If you create the array using the syntax above, you end up with object
of type list.
To create .Net array, you can do the following:

>>> import System
>>> array = System.Array.CreateInstance(System.Double, 5)
>>> array[0]=1.3
>>> array
System.Double[](1.3, 0, 0, 0, 0)

And call:

myObject.MyMethod(array)

>>> 2. I'd like to invoke an overloaded operator, or it's backing op_xxx
method.
>>> For example, both of these fail:
>>> myComplex = myComplex1 + myComplex2
>>> myComplex = Complex.op_Addition(myComplex1, myComplex2) 

This will be enabled in the 0.7.3 release which is coming out soon.
In 0.7.2 there is no way to access the user defined operators.

Martin


From kfarmer at thuban.org  Wed Apr 20 01:43:57 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Tue, 19 Apr 2005 16:43:57 -0700
Subject: [IronPython] To Compile or Not to compile, that's the question
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F91@nostromo.circle-cross.home>

Well, that explains why it's called "pyc" -> rus
 
I actually can sound out much of it.  Can't tell the difference much between tch, tsch, and the like.  Don't ask me to do it in cursive:  mmnnununuunnmm ;)
 
"ipyc", in english, would probably sound much like "eye pick", which reminds me of the Hellraiser movies.  Depending on your language, ymmv.

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Serge Kolgan
Sent: Wed 4/13/2005 4:24 PM
To: 'Discussion of IronPython'
Subject: RE: [IronPython] To Compile or Not to compile, that's the question


 
pyc.exe is a popular on-the-fly convertor of English letters being typed on a keyboard into Cyrillic fonts on the screen(being Russian myself I just read what Google brought up).
 
I'd suggest ipyc.exe ( pronounced much like HP's IPAQ :) )
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 4383 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050419/48f32ab1/attachment.bin>

From martmaly at exchange.microsoft.com  Wed Apr 20 03:24:47 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Tue, 19 Apr 2005 18:24:47 -0700
Subject: [IronPython] Re: Working with System.Data.DataColumn[]
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701BCB978@df-chewy-msg.exchange.corp.microsoft.com>

Anthony,

Yes, there is a way. With few changes your code is essentially correct:

import sys
sys.LoadAssemblyByName('System.Data')
from System      import Type, Console, Array
from System.Data import DataSet, DataColumn
key = Array.CreateInstance(DataColumn, 1)
dataset = DataSet('MySet')
dataset.Tables.Add('Order')
dataset.Tables['Order'].Columns.Add('OrderID',
Type.GetType('System.Int32'))
dataset.Tables['Order'].Columns.Add('CustomerFirstName',
Type.GetType('System.String'))
dataset.Tables['Order'].Columns.Add('CustomerLastName',
Type.GetType('System.String'))
dataset.Tables['Order'].PrimaryKey
dataset.Tables['Order'].Columns['OrderID']
key[0] = dataset.Tables['Order'].Columns['OrderID']
dataset.Tables['Order'].PrimaryKey = key


The PrimaryKey property is property of type "DataColumn[]" which
suggests that you should be
able to index it, but upon creation the array is that of length 0. The
primary key array
needs to be created separately:

key = Array.CreateInstance(DataColumn, 1)
key[0] = dataset.Tables['Order'].Columns['OrderID']
dataset.Tables['Order'].PrimaryKey = key

and then things work.

Martin

>>> Anthony Tarlano Wrote:
>>> To all:
>>> Is there anyway to add a System.Data.DataColumn instance to the
>>> PrimaryKey System.Data.DataColumn[] in IronPython??








From richard.mh at mac.com  Wed Apr 20 03:29:06 2005
From: richard.mh at mac.com (Richard Monson-Haefel)
Date: Tue, 19 Apr 2005 20:29:06 -0500
Subject: [IronPython] Questions for FAQ or User Guide
In-Reply-To: <1E1FC9DA1767ED44872F4E17AC17E8F701BCB8E7@df-chewy-msg.exchange.corp.microsoft.com>
References: <1E1FC9DA1767ED44872F4E17AC17E8F701BCB8E7@df-chewy-msg.exchange.corp.microsoft.com>
Message-ID: <3015221dc94803060ea363157548da5a@mac.com>

It might be better if IronPython auto converted the list of real number 
to an array in this case. If, that is, all the types in the list can be 
widened to the correct type, or if the parameter is an array of 
objects. That way you don't have to call an explicit method to set the 
list to an array of Double types.

The reason, I think this is important, is that in Python developers 
will avoid explicit typed of arrays  in favor of loose typed lists 
because its more Pythonic. Since interaction with general purpose 
languages (strongly typed) will require more strict typing, the 
interpreter or compiler should make that transformation (from List to 
array of doubles) implicitly, or if it can't be done throw an 
exception.  Otherwise, you are forcing IronPython developers to adhere 
to strict typing whenever they script interactions of objects defined 
by general purpose languages like C#.

richard

On Apr 19, 2005, at 6:36 PM, Martin Maly wrote:

>
>
>>>> John A. Tenney Wrote:
>>>>
>>>> 1. I'd like to pass an array of 6 doubles to a method, but get an
> error message.
>>>> For example, the "myMethod" call below fails when it requires a
> double array.
>>>> array=[1, 2, 3.5, 4]
>>>> myObject.myMethod(array)
>
> If you create the array using the syntax above, you end up with object
> of type list.
> To create .Net array, you can do the following:
>
>>>> import System
>>>> array = System.Array.CreateInstance(System.Double, 5)
>>>> array[0]=1.3
>>>> array
> System.Double[](1.3, 0, 0, 0, 0)
>
> And call:
>
> myObject.MyMethod(array)



From martmaly at exchange.microsoft.com  Wed Apr 20 20:17:09 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Wed, 20 Apr 2005 11:17:09 -0700
Subject: [IronPython] Questions for FAQ or User Guide
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701BCBB26@df-chewy-msg.exchange.corp.microsoft.com>

That is a good suggestion. The initial look shows that it would be quite
possible to implement it. I'll give it a try.

Martin

-----Original Message-----
From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Richard Monson-Haefel
Sent: Tuesday, April 19, 2005 6:29 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Questions for FAQ or User Guide

It might be better if IronPython auto converted the list of real number 
to an array in this case. If, that is, all the types in the list can be 
widened to the correct type, or if the parameter is an array of 
objects. That way you don't have to call an explicit method to set the 
list to an array of Double types.

The reason, I think this is important, is that in Python developers 
will avoid explicit typed of arrays  in favor of loose typed lists 
because its more Pythonic. Since interaction with general purpose 
languages (strongly typed) will require more strict typing, the 
interpreter or compiler should make that transformation (from List to 
array of doubles) implicitly, or if it can't be done throw an 
exception.  Otherwise, you are forcing IronPython developers to adhere 
to strict typing whenever they script interactions of objects defined 
by general purpose languages like C#.

richard



From bob at redivi.com  Wed Apr 20 20:39:19 2005
From: bob at redivi.com (Bob Ippolito)
Date: Wed, 20 Apr 2005 14:39:19 -0400
Subject: [IronPython] Questions for FAQ or User Guide
In-Reply-To: <1E1FC9DA1767ED44872F4E17AC17E8F701BCBB26@df-chewy-msg.exchange.corp.microsoft.com>
References: <1E1FC9DA1767ED44872F4E17AC17E8F701BCBB26@df-chewy-msg.exchange.corp.microsoft.com>
Message-ID: <8a9dac849c4815f1191a325f070c677c@redivi.com>

It's certainly possible, PyObjC does a lot of conversions like this and 
it works rather well.

-bob

On Apr 20, 2005, at 2:17 PM, Martin Maly wrote:

> That is a good suggestion. The initial look shows that it would be 
> quite
> possible to implement it. I'll give it a try.
>
> Martin
>
> -----Original Message-----
> From: users-ironpython.com-bounces at lists.ironpython.com
> [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
> Richard Monson-Haefel
> Sent: Tuesday, April 19, 2005 6:29 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Questions for FAQ or User Guide
>
> It might be better if IronPython auto converted the list of real number
> to an array in this case. If, that is, all the types in the list can be
> widened to the correct type, or if the parameter is an array of
> objects. That way you don't have to call an explicit method to set the
> list to an array of Double types.
>
> The reason, I think this is important, is that in Python developers
> will avoid explicit typed of arrays  in favor of loose typed lists
> because its more Pythonic. Since interaction with general purpose
> languages (strongly typed) will require more strict typing, the
> interpreter or compiler should make that transformation (from List to
> array of doubles) implicitly, or if it can't be done throw an
> exception.  Otherwise, you are forcing IronPython developers to adhere
> to strict typing whenever they script interactions of objects defined
> by general purpose languages like C#.
>
> richard
>
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From richard.mh at mac.com  Wed Apr 20 20:51:14 2005
From: richard.mh at mac.com (Richard Monson-Haefel)
Date: Wed, 20 Apr 2005 13:51:14 -0500
Subject: [IronPython] Questions for FAQ or User Guide
In-Reply-To: <1E1FC9DA1767ED44872F4E17AC17E8F701BCBB26@df-chewy-msg.exchange.corp.microsoft.com>
References: <1E1FC9DA1767ED44872F4E17AC17E8F701BCBB26@df-chewy-msg.exchange.corp.microsoft.com>
Message-ID: <d26916ad4cdff601fd242c3cae888357@mac.com>

Cool!

On Apr 20, 2005, at 1:17 PM, Martin Maly wrote:

> That is a good suggestion. The initial look shows that it would be 
> quite
> possible to implement it. I'll give it a try.
>
> Martin
>
> -----Original Message-----
> From: users-ironpython.com-bounces at lists.ironpython.com
> [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
> Richard Monson-Haefel
> Sent: Tuesday, April 19, 2005 6:29 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Questions for FAQ or User Guide
>
> It might be better if IronPython auto converted the list of real number
> to an array in this case. If, that is, all the types in the list can be
> widened to the correct type, or if the parameter is an array of
> objects. That way you don't have to call an explicit method to set the
> list to an array of Double types.
>
> The reason, I think this is important, is that in Python developers
> will avoid explicit typed of arrays  in favor of loose typed lists
> because its more Pythonic. Since interaction with general purpose
> languages (strongly typed) will require more strict typing, the
> interpreter or compiler should make that transformation (from List to
> array of doubles) implicitly, or if it can't be done throw an
> exception.  Otherwise, you are forcing IronPython developers to adhere
> to strict typing whenever they script interactions of objects defined
> by general purpose languages like C#.
>
> richard
>
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From kfarmer at thuban.org  Wed Apr 20 22:49:52 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Wed, 20 Apr 2005 13:49:52 -0700
Subject: [IronPython] Questions for FAQ or User Guide
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F92@nostromo.circle-cross.home>

But where should the line be drawn in favor of not throwing casting errors?  I wouldn't want to use something that didn't know how to play nice when it leaves its own little world.

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Martin Maly
Sent: Wed 4/20/2005 11:17 AM
To: Discussion of IronPython
Subject: RE: [IronPython] Questions for FAQ or User Guide



That is a good suggestion. The initial look shows that it would be quite
possible to implement it. I'll give it a try.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3649 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050420/b41c0dc8/attachment.bin>

From richard.mh at mac.com  Wed Apr 20 23:22:42 2005
From: richard.mh at mac.com (Richard Monson-Haefel)
Date: Wed, 20 Apr 2005 16:22:42 -0500
Subject: [IronPython] Questions for FAQ or User Guide
In-Reply-To: <C02467D265F3F64E87DED53F9C3DE29C7F92@nostromo.circle-cross.home>
References: <C02467D265F3F64E87DED53F9C3DE29C7F92@nostromo.circle-cross.home>
Message-ID: <7d683d384f4a60a816a3156a443907d1@mac.com>

Well, the way I see it (not that my opinion is all that important, but 
...) you should be able to use more explicit typing by declaring the 
System.Double [] type  if you desire, but IronPython should attempt to 
do the transformation if you choose not to (or neglect) to do so. That 
way you get both options. Very explicit type conversions or implicit 
conversions.  It becomes a matter of style.  The thing to remember, 
IMO, is that IronPython is a dynamic language and by nature dynamic 
language are loosely typed. If you require explicit typing, than you 
are breaking that model, in which case you might as well not use 
IronPython at all.


On Apr 20, 2005, at 3:49 PM, Keith J. Farmer wrote:

> But where should the line be drawn in favor of not throwing casting 
> errors?  I wouldn't want to use something that didn't know how to play 
> nice when it leaves its own little world.
>
> ________________________________
>
> From: users-ironpython.com-bounces at lists.ironpython.com on behalf of 
> Martin Maly
> Sent: Wed 4/20/2005 11:17 AM
> To: Discussion of IronPython
> Subject: RE: [IronPython] Questions for FAQ or User Guide
>
>
>
> That is a good suggestion. The initial look shows that it would be 
> quite
> possible to implement it. I'll give it a try.
>
>
> <winmail.dat>_______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From kfarmer at thuban.org  Thu Apr 21 00:23:53 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Wed, 20 Apr 2005 15:23:53 -0700
Subject: [IronPython] Questions for FAQ or User Guide
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F93@nostromo.circle-cross.home>

Well, the point I was going to bring up last night was that one could live very happily within IronPython, following Pythonic customs; but one should be expected to follow the customs that exist in the CLR world when talking with it.
 
Some types I can see free conversions for -- particularly value types.  Some types, such as arrays, would be tricker and I suspect impossible in cases: for those I'd desire strong-typing.  For stuff that IronPython may expose to the outside world, strong-typing should be a requirement (even if it's declaring the type to be Object), no?
 
C#2 brings on type inference for delegates, so I can see a similar scheme going on.  For IronPython I think it'd be closer to a dispatch based on type, which I can see getting very bloaty.
 
I'm not familiar with how Jim addressed this in Jython?

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Richard Monson-Haefel
Sent: Wed 4/20/2005 2:22 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Questions for FAQ or User Guide



Well, the way I see it (not that my opinion is all that important, but
...) you should be able to use more explicit typing by declaring the
System.Double [] type  if you desire, but IronPython should attempt to
do the transformation if you choose not to (or neglect) to do so. That
way you get both options. Very explicit type conversions or implicit
conversions.  It becomes a matter of style.  The thing to remember,
IMO, is that IronPython is a dynamic language and by nature dynamic
language are loosely typed. If you require explicit typing, than you
are breaking that model, in which case you might as well not use
IronPython at all.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 4809 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050420/6b463ce2/attachment.bin>

From kfarmer at thuban.org  Thu Apr 21 02:22:10 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Wed, 20 Apr 2005 17:22:10 -0700
Subject: [IronPython] Questions for FAQ or User Guide
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F94@nostromo.circle-cross.home>

I just came across Starkiller: http://www.python.org/pycon/dc2004/papers/1/paper.pdf
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3077 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050420/836ad1bb/attachment.bin>

From firemoth at gmail.com  Thu Apr 21 06:22:28 2005
From: firemoth at gmail.com (Timothy Fitz)
Date: Thu, 21 Apr 2005 00:22:28 -0400
Subject: [IronPython] Questions for FAQ or User Guide
In-Reply-To: <C02467D265F3F64E87DED53F9C3DE29C7F94@nostromo.circle-cross.home>
References: <C02467D265F3F64E87DED53F9C3DE29C7F94@nostromo.circle-cross.home>
Message-ID: <972ec5bd0504202122345e4ea8@mail.gmail.com>

On 4/20/05, Keith J. Farmer <kfarmer at thuban.org> wrote:
> I just came across Starkiller: http://www.python.org/pycon/dc2004/papers/1/paper.pdf

Unfortunately Starkiller will most likely not be released. Michael
Salib was under the employ of MIT when he wrote it and therefor does
not own the code. When I talked to him at PyCon he said he had started
on a rewrite to get around these issues and that releasing it would be
possible but would take convincing MIT the ideas have no commercial
viability (standard operating procedure there, but would take months
minimum and quite a bit of effort).

Also, Starkiller makes assumptions that IronPython absolutely cannot
(no eval and others more egregious).

And now, on the extremely blindingly bright side of things, there is
PyPy. It does type inferencing in a rather different way than
Starkiller, and is designed for targeting different output formats
(CLI!) So the idea is definitely alive and kicking (and now well
funded by the European Union).

As for why I'm so negative about Starkiller's application; blame Brett
Cannon. He gave a good presentation on why type inferencing is very
hard and doesn't gain much in Python without making changes to the
language itself.


From kfarmer at thuban.org  Thu Apr 21 07:39:56 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Wed, 20 Apr 2005 22:39:56 -0700
Subject: [IronPython] Questions for FAQ or User Guide
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C1369B7@nostromo.circle-cross.home>

Nonetheless, it does present some basis from which to start.

I also suspect, specifically regarding the Starkiller paper, that some
of the problems aren't all that relevent.  For example, dynamic method
creation: is that something that is going to be exposed outside of
IronPython?  If not, then do we need to worry about it?  If so, such as
a callback defined through some hosted scripting environment, then
perhaps we say that callbacks must be unambiguous about their type.  I'm
willing to suggest that all such reference types must be strongly typed.
Strings, numbers, and other primitives should be fairly simple
otherwise.

Not that my musings should matter -- this is well out of my experience.
;)

-----Original Message-----
From: Timothy Fitz [mailto:firemoth at gmail.com] 
Sent: Wednesday, April 20, 2005 9:22 PM

Also, Starkiller makes assumptions that IronPython absolutely cannot
(no eval and others more egregious).

And now, on the extremely blindingly bright side of things, there is
PyPy. It does type inferencing in a rather different way than
Starkiller, and is designed for targeting different output formats
(CLI!) So the idea is definitely alive and kicking (and now well
funded by the European Union).



From firemoth at gmail.com  Thu Apr 21 19:02:55 2005
From: firemoth at gmail.com (Timothy Fitz)
Date: Thu, 21 Apr 2005 13:02:55 -0400
Subject: [IronPython] Questions for FAQ or User Guide
In-Reply-To: <C02467D265F3F64E87DED53F9C3DE29C1369B7@nostromo.circle-cross.home>
References: <C02467D265F3F64E87DED53F9C3DE29C1369B7@nostromo.circle-cross.home>
Message-ID: <972ec5bd05042110023193035b@mail.gmail.com>

On 4/21/05, Keith J. Farmer <kfarmer at thuban.org> wrote:
> Nonetheless, it does present some basis from which to start.
> 
> I also suspect, specifically regarding the Starkiller paper, that some
> of the problems aren't all that relevent.  For example, dynamic method
> creation: is that something that is going to be exposed outside of
> IronPython?  If not, then do we need to worry about it?  If so, such as
> a callback defined through some hosted scripting environment, then
> perhaps we say that callbacks must be unambiguous about their type.  I'm
> willing to suggest that all such reference types must be strongly typed.
> Strings, numbers, and other primitives should be fairly simple
> otherwise.

Sure, you could do that and gain performance; however, python favors
simplicity over such a solution. Very specifically IronPython is meant
to implement Python and not change the language. So basically
IronPython is not going to do this. If you take this philosophy and
apply it to python as a hole, you end up with a type inferenced
python; you end up with something like Boo. So while IronPython isn't
going to implement this, there exist an easy avenue to do what you're
asking for. So I'd suggest you give Boo a look if that's what your
looking for. (Previous discussions have suggested Boo as a nice
python-like way of writing statically typed code instead of C#, and
then have python call out to that instead)


From kirko at microsoft.com  Mon Apr 25 20:53:48 2005
From: kirko at microsoft.com (Kirk Olynyk)
Date: Mon, 25 Apr 2005 11:53:48 -0700
Subject: [IronPython] Overloading OnPaint etc.
Message-ID: <310187D53C02434D8F2CF4CD951B734102A61EDC@RED-MSG-60.redmond.corp.microsoft.com>

Under C#, you can overload OnPaint on a class derived from Form and then
it will automatically be called upon the paint event. I find that under
IronPython that I am forced to explicitly add the OnPaint method to the
paint message handler list. Is this by design?

 

import sys

sys.LoadAssemblyByName("System")

sys.LoadAssemblyByName("System.Drawing")

sys.LoadAssemblyByName("System.Windows.Forms")

 

from System import *

from System.Windows.Forms import *

from System.Drawing import *

 

class HelloWorld(Form):

    

    def __init__ (self):

        print "HelloWorld.__init__"

        self.Text = "Hello World"

        self.BackColor = Color.White

        self.Paint += HelloWorld.OnPaint        # not necessary in
Csharp

    

    def OnPaint (self, pea):

        print "HelloWorld.OnPaint"

        grfx = pea.Graphics

        grfx.DrawString("Hell, Windows Forms!", self.Font,
Brushes.Black, 0, 0)

 

Application.Run(HelloWorld())

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050425/1a371edb/attachment.html>

From jimhug at exchange.microsoft.com  Tue Apr 26 20:48:47 2005
From: jimhug at exchange.microsoft.com (Jim Hugunin)
Date: Tue, 26 Apr 2005 11:48:47 -0700
Subject: [IronPython] Questions for FAQ or User Guide
Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201B766FA@df-fido-msg.exchange.corp.microsoft.com>

I've been working on a blog entry that tries to cover this in great
detail.  Rather than go silent until I find time to complete that, I
thought I should chime in a little here.

<Assume a big prelude about the fact that IronPython tries to do the
right conversions to make it easy and natural for Python programmers to
work with CLS libraries.  This will explain numeric types, strings, and
delegates which all work pretty naturally today.>

When working with CLS libraries, IronPython tries first to ensure that
nothing is impossible and second to make interactions as natural and
convenient when possible.  This is why Martin's answer below is an
important one showing how this method can be called from IronPython
today.  There will always be cases where some CLS methods will require
techniques such as explicitly creating typed arrays in order to work
with them effectively.  I would expect that an experienced IronPython
user will never be able to completely get away from the occasional need
to create a typed array. 

Arrays are probably the hardest type of all to get right.  They're a
special type to the runtime without an interface or even a standard
class which leaves much less design room to improve their interaction
with IronPython.  Unfortunately, arrays are also probably the most
commonly used collection type because they are easy to create.  Just
like Python has special syntax for building lists and tuples, C# has
special syntax for easily building arrays.

The key challenge with arrays is that they are mutable.  That means that
you can change the contents of an array after creating it.  Some methods
that accept an array need to mutate its contents and expect the caller
to be able to see that mutated array.  Most methods that take an array
treat it as read-only input and won't make any changes to the contents.
This second set of methods would be better specified with an immutable
type such as Python's tuples; however, the ease of use of arrays over
other types means that this is rare.  Unfortunately, it is hard or
impossible to automatically tell the difference between these two types
of methods.  Here are two examples from System.String:

public string Trim(char[] trimChars);
- Ideally, this should accept any sequence of chars, including a Python
string

public void CopyTo(int sourceIndex, char[] destination,
                   int destinationIndex, int count);
- Needs an array for its destination because it is counting on mutating
the array

Because we can't tell the difference between these two signatures, it's
impossible have different rules for the two cases.  I'm very
uncomfortable accepting a list of chars for the second method.

A third method on System.String shows that things aren't always this
grim.  The format method uses the params keyword to indicate that it
takes 0 or more args.  This means that programming languages can support
dynamically building this array at the call site from a variable-length
argument list.  As a result, we can infer that this array is not used as
an out parameter.  In fact, this maps directly to Python's *args
support.  I'd claim that Python has a slightly better design for this
feature because it uses the immutable Tuple type here rather than a
theoretically mutable array.

public static string Format(string format, params object[] args);
- The use of params here gives us great support

History - Jython doesn't automatically convert between Python
collections and arrays.  It added a special jarray class for building
Java style arrays that could be used in the same way as
System.Array.CreateInstance.  Jython's jarray did have several
convenience constructors that made it easier to go from a list to an
array that we might want to consider here.

If I recall correctly, Numeric Python which is an even older CPython
extension of mine that supports working with numeric arrays does do
automatic conversions from Python sequences to numeric arrays in order
to make some vector math operations easier to write.  This conversion
would make sense in that case because it could be known that the
operands to the arithmetic function wouldn't ever be mutated.

Some thoughts - Jim

Richard Monson-Haefel wrote:
> It might be better if IronPython auto converted the list of real
number
> to an array in this case. If, that is, all the types in the list can
be
> widened to the correct type, or if the parameter is an array of
> objects. That way you don't have to call an explicit method to set the
> list to an array of Double types.
> 
> The reason, I think this is important, is that in Python developers
> will avoid explicit typed of arrays  in favor of loose typed lists
> because its more Pythonic. Since interaction with general purpose
> languages (strongly typed) will require more strict typing, the
> interpreter or compiler should make that transformation (from List to
> array of doubles) implicitly, or if it can't be done throw an
> exception.  Otherwise, you are forcing IronPython developers to adhere
> to strict typing whenever they script interactions of objects defined
> by general purpose languages like C#.
> 
> richard
> 
> On Apr 19, 2005, at 6:36 PM, Martin Maly wrote:
> 
> >
> >
> >>>> John A. Tenney Wrote:
> >>>>
> >>>> 1. I'd like to pass an array of 6 doubles to a method, but get an
> > error message.
> >>>> For example, the "myMethod" call below fails when it requires a
> > double array.
> >>>> array=[1, 2, 3.5, 4]
> >>>> myObject.myMethod(array)
> >
> > If you create the array using the syntax above, you end up with
object
> > of type list.
> > To create .Net array, you can do the following:
> >
> >>>> import System
> >>>> array = System.Array.CreateInstance(System.Double, 5)
> >>>> array[0]=1.3
> >>>> array
> > System.Double[](1.3, 0, 0, 0, 0)
> >
> > And call:
> >
> > myObject.MyMethod(array)


From martmaly at exchange.microsoft.com  Tue Apr 26 22:32:23 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Tue, 26 Apr 2005 13:32:23 -0700
Subject: [IronPython] IronPython 0.7.3 Released
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701C45576@df-chewy-msg.exchange.corp.microsoft.com>

Hello IronPython community,

Today we have released IronPython 0.7.3.

The main changes over the 0.7.2 release are:
* Operator overloading. Following code now works in IronPython:
	...
	x = Mapack.Matrix.Random(2,3)
	y = Mapack.Matrix.Random(3,5)
	x * y
* Empty constructors for value types:
	x = Point()
	x += Size(1,1)
* Numerous bug fixes

Our thanks go to the members of the community who reported bugs
and provided valuable feedback (*):

Nicholas Jacobson
Anthony Tarlano
John A. Tenney
Keith J. Farmer
Richard Monson-Haefel

List of bugs fixed for the 0.7.3 release:
* __import__ not implemented and not hooked up into import statement
* Cannot import random.py
* Cannot import string.py
* Can't split string with multiple separators
* 2.5 rounds down to 2, etc
* string's count method throws an exception
* The built-in string method split doesn't take a second parameter.
* The builtin string method 'startswith' refuses to take 2 or 3
parameters.
* dictionary method 'get' broken with only 1 arg
* The dictionary method 'setdefault' refuses to take only one argument.
* The list method 'pop' refuses to take one argument.
* Can't read file via enumerator
* Octal numbers can contain 8s and 9s
* import accepts any string
* in-place add not implemented for lists
* File I/O can't be set to unbuffered (bufsize=0)
* Bit shift overflow does not convert to long
* Can't take the bitwise not of a long.
* dir doesn't work on an instantiated class
* del doesn't work on an instantiated class
* Point, Size missing empty constructors
* Point, Size missing overloads for +, -, +=, -=
* "*" operator overloading for Matrix does not kick in
* in-place assignments not supported by Complex
* Generators in nested functions throw code-gen time error.
* List.reverse() corrupts data
* Generate indexing by the tuple safely
* compile doesn't handle the 3rd argument correctly
* Method call to super class virtual method causes infinite recursion

Thank you and keep in touch
The IronPython Team

http://workspaces.gotdotnet.com/ironpython
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
http://www.microsoft.com/downloads/details.aspx?FamilyID=cf952fdb-2344-4
b1e-b169-3f5dfbca2984&displaylang=en


(*) I misplaced the original email in which the "List.reverse() corrupts
data"
    bug was reported so I apologize if the list of people who helped to
make
    this release happen is incomplete. Feel free to send me an email and
remind me.



From jimhug at exchange.microsoft.com  Tue Apr 26 22:37:46 2005
From: jimhug at exchange.microsoft.com (Jim Hugunin)
Date: Tue, 26 Apr 2005 13:37:46 -0700
Subject: [IronPython] Overloading OnPaint etc.
Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201B767B2@df-fido-msg.exchange.corp.microsoft.com>

This is broken.  Unfortunately, you should assume that in IronPython 0.7.3 you can't override any methods from a CLS super type so that it will be seen from the CLS side.

FYI - It is possible in IronPython 0.7.3 to override a very small set of methods from a CLS super type in such a way that other CLS languages will see and be affected by those overrides.  Looking over the code, the set of methods that work for this are exactly those needed to run the parrotbench benchmark - no more and no less.

Now that you've reminded us of this issue, fixing the bug is high on our priority list and I'd expect this to be fixed in the next 1-2 weeks for 0.7.4.  The basic design is in place to make this work for int.__cmp__ and a few other key methods so the work is just to extend that design to cover the general case.

Thanks - Jim

________________________________________
From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Kirk Olynyk
Sent: Monday, April 25, 2005 11:54 AM
To: users-ironpython.com at lists.ironpython.com
Subject: [IronPython] Overloading OnPaint etc.

Under C#, you can overload OnPaint on a class derived from Form and then it will automatically be called upon the paint event. I find that under IronPython that I am forced to explicitly add the OnPaint method to the paint message handler list. Is this by design?
?
import sys
sys.LoadAssemblyByName("System")
sys.LoadAssemblyByName("System.Drawing")
sys.LoadAssemblyByName("System.Windows.Forms")
?
from System import *
from System.Windows.Forms import *
from System.Drawing import *
?
class HelloWorld(Form):
??? 
??? def __init__ (self):
??????? print "HelloWorld.__init__"
??????? self.Text = "Hello World"
??????? self.BackColor = Color.White
??????? self.Paint += HelloWorld.OnPaint??????? # not necessary in Csharp
??? 
??? def OnPaint (self, pea):
??????? print "HelloWorld.OnPaint"
??????? grfx = pea.Graphics
??????? grfx.DrawString("Hell, Windows Forms!", self.Font, Brushes.Black, 0, 0)
?
Application.Run(HelloWorld())


From kfarmer at thuban.org  Tue Apr 26 23:46:24 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Tue, 26 Apr 2005 14:46:24 -0700
Subject: [IronPython] IronPython 0.7.3 Released
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F95@nostromo.circle-cross.home>

Out of curiosity, is there a feel for when 1.0 should be reached (excluding bug fixes), or some other roadmap?
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2999 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050426/1df11f08/attachment.bin>

From mahs at telcopartners.com  Tue Apr 26 23:56:39 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Tue, 26 Apr 2005 14:56:39 -0700
Subject: [IronPython] reload or workaround
In-Reply-To: <1E1FC9DA1767ED44872F4E17AC17E8F701C45576@df-chewy-msg.exchange.corp.microsoft.com>
References: <1E1FC9DA1767ED44872F4E17AC17E8F701C45576@df-chewy-msg.exchange.corp.microsoft.com>
Message-ID: <d4md45$7fe$1@sea.gmane.org>

Congrats and thanks for the 0.73 release

Since reload is not available yet, what is the best workaround for re-compiling 
changed source for imported modules?

The exe/pdf files cannot be deleted

del sys.modules[...] followed by import ...

raises a System.IO.IOException


Until now, I have been restarting the interpreter and re-importing the module 
after every source change.  Is there a better way yet?

Thanks

Michael



From jimhug at exchange.microsoft.com  Wed Apr 27 00:13:55 2005
From: jimhug at exchange.microsoft.com (Jim Hugunin)
Date: Tue, 26 Apr 2005 15:13:55 -0700
Subject: [IronPython] reload or workaround
Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201B7686F@df-fido-msg.exchange.corp.microsoft.com>

Michael Spencer wrote:
> Since reload is not available yet, what is the best workaround for re-
> compiling
> changed source for imported modules?

Execfile is a good option for many situations and was implemented to
make sure we had at least a partial reload story.  Until we get great
IDE support, one of my favorite ways of driving Python is with emacs
mode.  I'll edit my script in one buffer and then use the emacs command
to execfile that code in the open interactive buffer.  This works great
when you're working on a single module at a time.  Does this help?

A simple version of reload shouldn't be that much work.  I don't know
why it fell off the radar for this long.  We'll get that running in the
next 1-2 weeks for 0.7.4.

Thanks - Jim 


From mahs at telcopartners.com  Wed Apr 27 00:42:30 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Tue, 26 Apr 2005 15:42:30 -0700
Subject: [IronPython] Re: reload or workaround
In-Reply-To: <6C91A34F0BB48B40A86F1E146B7A049201B7686F@df-fido-msg.exchange.corp.microsoft.com>
References: <6C91A34F0BB48B40A86F1E146B7A049201B7686F@df-fido-msg.exchange.corp.microsoft.com>
Message-ID: <d4mfq4$fq4$1@sea.gmane.org>

Jim Hugunin wrote:
> Michael Spencer wrote:
> 
>>Since reload is not available yet, what is the best workaround for re-
>>compiling
>>changed source for imported modules?
> 
> 
> Execfile is a good option for many situations and was implemented to
> make sure we had at least a partial reload story. 

Thanks, that *is* a better work-around.  Too bad execfile doesn't take a globals 
argument - then we'd have reload for free.  And exec barfs on exec "import ~", 
so that isn't an option either for now.

  Until we get great
> IDE support, one of my favorite ways of driving Python is with emacs
> mode.  I'll edit my script in one buffer and then use the emacs command
> to execfile that code in the open interactive buffer.  This works great
> when you're working on a single module at a time.  Does this help?
> 
That's very much the set-up I use with CPython, albeit with a wxPython-based 
shell. But I think you'll be able to make reload in less time than it would take 
me to learn emacs ;-)

> A simple version of reload shouldn't be that much work.  I don't know
> why it fell off the radar for this long.  We'll get that running in the
> next 1-2 weeks for 0.7.4.
> 
> Thanks - Jim 
I'll look forward to it.

Cheers

Michael



From mahs at telcopartners.com  Wed Apr 27 00:52:03 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Tue, 26 Apr 2005 15:52:03 -0700
Subject: [IronPython] Saving sys.path
Message-ID: <d4mgc0$h7p$1@sea.gmane.org>

Second feature request of the week:

I would like to save sys.path settings between interpreter sessions.

Is there a way to do this today?

If not, could there be an OS environment variable for this or, a startup.py file 
loaded each time the interpreter starts?

Thanks

Michael



From kfarmer at thuban.org  Wed Apr 27 01:02:24 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Tue, 26 Apr 2005 16:02:24 -0700
Subject: [IronPython] Saving sys.path
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F96@nostromo.circle-cross.home>

Perhaps (to at least keep the .NET way) a .config file instead of an environment variable?
 
That file *could* specify one or more startup files, to maintain the Python mystique.

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Michael Spencer
Sent: Tue 4/26/2005 3:52 PM
To: users-ironpython.com at lists.ironpython.com
Subject: [IronPython] Saving sys.path



Second feature request of the week:

I would like to save sys.path settings between interpreter sessions.

Is there a way to do this today?

If not, could there be an OS environment variable for this or, a startup.py file
loaded each time the interpreter starts?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3705 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050426/bbbfc0e4/attachment.bin>

From mahs at telcopartners.com  Wed Apr 27 01:37:06 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Tue, 26 Apr 2005 16:37:06 -0700
Subject: [IronPython] Nice speed
Message-ID: <d4mj0f$oog$1@sea.gmane.org>

IronPython runs this sieve function 20-30% faster than CPython


def primes2(n):
     if n<2: return []
     s=range(1,n,2) # [1,3,5....n | n-1]
     s[0] = 2
     len_s = len(s)
     for i in xrange(1,int(sqrt(n)/2)+1):
         m = s[i]
         if m:
             j=(m*m)/2
             while j<len_s:
                 s[j]=0
                 j = j+m

     return [i for i in s if i]

def timeit(N):
     t1 = time.clock()
     l1 = primes2(N)
     tp1 = time.clock()- t1
     return tp1

CPython 2.4
  >>> [timeit(1000000) for i in 1,2,3]
  [0.746761948795168, 0.76873792618893333, 0.78001002920763085]
  >>>

IronPython 0.7.3
  >>> [timeit(1000000) for i in 1,2,3]
  [0.590843200683594, 0.550788879394531, 0.490707397460938]
  >>>


Michael



From alleykat at gmail.com  Wed Apr 27 02:21:54 2005
From: alleykat at gmail.com (Travis Watkins)
Date: Tue, 26 Apr 2005 19:21:54 -0500
Subject: [IronPython] Nice speed
In-Reply-To: <d4mj0f$oog$1@sea.gmane.org>
References: <d4mj0f$oog$1@sea.gmane.org>
Message-ID: <adca365a05042617213f9dc245@mail.gmail.com>

On 4/26/05, Michael Spencer <mahs at telcopartners.com> wrote:
> IronPython runs this sieve function 20-30% faster than CPython
> 
> def primes2(n):
>      if n<2: return []
>      s=range(1,n,2) # [1,3,5....n | n-1]
>      s[0] = 2
>      len_s = len(s)
>      for i in xrange(1,int(sqrt(n)/2)+1):
>          m = s[i]
>          if m:
>              j=(m*m)/2
>              while j<len_s:
>                  s[j]=0
>                  j = j+m
> 
>      return [i for i in s if i]
> 
> def timeit(N):
>      t1 = time.clock()
>      l1 = primes2(N)
>      tp1 = time.clock()- t1
>      return tp1
> 
> CPython 2.4
>   >>> [timeit(1000000) for i in 1,2,3]
>   [0.746761948795168, 0.76873792618893333, 0.78001002920763085]
>   >>>
> 
> IronPython 0.7.3
>   >>> [timeit(1000000) for i in 1,2,3]
>   [0.590843200683594, 0.550788879394531, 0.490707397460938]
>   >>>
> 
> Michael
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 

Never trust the program you're running to give you accurate time. Use
'time python foo.py' instead. If you're going to do that put most of
the code in a seperate file that gets imported so the bytecode gets
cached since IronPython is precompiled to IL. Other than that, cool.

-- 
Travis Watkins
http://www.realistanew.com


From mahs at telcopartners.com  Wed Apr 27 04:15:08 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Tue, 26 Apr 2005 19:15:08 -0700
Subject: [IronPython] Re: Nice speed
In-Reply-To: <adca365a05042617213f9dc245@mail.gmail.com>
References: <d4mj0f$oog$1@sea.gmane.org>
	<adca365a05042617213f9dc245@mail.gmail.com>
Message-ID: <d4ms8n$eo4$1@sea.gmane.org>

Travis Watkins wrote:
> 
> Never trust the program you're running to give you accurate time. 

I thought (and think) that the measurements are sufficiently accurate, and the 
differences sufficiently marked to support the speed claim.  I also ran the test 
with much longer cycles, checked the reported time with wall-clock time, and 
obtained comparable results.  Repeating each test several times, and discarding 
outliers reduces the impact of other processes.  What sort of inaccuracies are 
you concerned about here?

Of course, this is far too narrow a test from which to draw any broad 
conclusions about the speed of the implementation.

Use
> 'time python foo.py' instead.

I presume you mean on ~nix.  I'm using Windows, and I'm not aware of a similar 
facility (which doesn't mean it doesn't exist).

  If you're going to do that put most of
> the code in a seperate file that gets imported so the bytecode gets
> cached since IronPython is precompiled to IL. 

I compared pre-compiled functions in each case.  Can you explain why what you 
suggest is fairer?

Other than that, cool.
> 
It is, isn't it ;-)

Michael



From fredrik at pythonware.com  Wed Apr 27 12:39:16 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 27 Apr 2005 12:39:16 +0200
Subject: [IronPython] Re: Nice speed
References: <d4mj0f$oog$1@sea.gmane.org>
	<adca365a05042617213f9dc245@mail.gmail.com>
Message-ID: <d4npqi$sus$1@sea.gmane.org>

Travis Watkins wrote:

> Never trust the program you're running to give you accurate time. Use
> 'time python foo.py' instead.

so you can make sure that the thing you're measuring is hidden by all the irrelevant
stuff that's going on when a process starts, and, if the thing you're measuring is small
enough, your results will be completely meaningless.  hello?

</F> 





From alleykat at gmail.com  Wed Apr 27 12:52:29 2005
From: alleykat at gmail.com (Travis Watkins)
Date: Wed, 27 Apr 2005 05:52:29 -0500
Subject: [IronPython] Re: Nice speed
In-Reply-To: <d4npqi$sus$1@sea.gmane.org>
References: <d4mj0f$oog$1@sea.gmane.org>
	<adca365a05042617213f9dc245@mail.gmail.com>
	<d4npqi$sus$1@sea.gmane.org>
Message-ID: <adca365a05042703526538a4ae@mail.gmail.com>

On 4/27/05, Fredrik Lundh <fredrik at pythonware.com> wrote:
> Travis Watkins wrote:
> 
> > Never trust the program you're running to give you accurate time. Use
> > 'time python foo.py' instead.
> 
> so you can make sure that the thing you're measuring is hidden by all the irrelevant
> stuff that's going on when a process starts, and, if the thing you're measuring is small
> enough, your results will be completely meaningless.  hello?
> 
> </F>
> 
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 

Garth already explained how to account for that.

-- 
Travis Watkins
http://www.realistanew.com


From fredrik at pythonware.com  Wed Apr 27 12:55:31 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 27 Apr 2005 12:55:31 +0200
Subject: [IronPython] Re: Re: Nice speed
References: <d4mj0f$oog$1@sea.gmane.org><adca365a05042617213f9dc245@mail.gmail.com><d4npqi$sus$1@sea.gmane.org>
	<adca365a05042703526538a4ae@mail.gmail.com>
Message-ID: <d4nqp1$b5$1@sea.gmane.org>

Travis Watkins wrote:

> Garth already explained how to account for that.

there's no Garth in this thread, at least not on my server.  what are you referring to?

(and my criticism still stands: "time python" is an extremely lousy way to benchmark
Python processes, no matter what "Garth" says).

</F> 





From jvm_cop at spamcop.net  Wed Apr 27 17:55:35 2005
From: jvm_cop at spamcop.net (J. Merrill)
Date: Wed, 27 Apr 2005 11:55:35 -0400
Subject: [IronPython] Questions for FAQ or User Guide
In-Reply-To: <C02467D265F3F64E87DED53F9C3DE29C7F94@nostromo.circle-cross .home>
Message-ID: <4.3.2.7.2.20050427115452.039ffe70@mail.comcast.net>

I don't know what's happened with Starkiller development, but a quick reading of the first page suggests that Boo is using many of the same ideas.

At 08:22 PM 4/20/2005, Keith J. Farmer wrote
>I just came across Starkiller: http://www.python.org/pycon/dc2004/papers/1/paper.pdf


J. Merrill / Analytical Software Corp



From martmaly at exchange.microsoft.com  Wed Apr 27 19:20:53 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Wed, 27 Apr 2005 10:20:53 -0700
Subject: [IronPython] Saving sys.path
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701C4587F@df-chewy-msg.exchange.corp.microsoft.com>

There are, as far as I can see, three different ways to help in this
case and I am looking into implementing all of them very soon,
definitely for the next release.

 

CPython uses environment variables PYTHONSTARTUP and PYTHONPATH to drive
the initialization of the interpreter

Also, on initialization, the interpreter executes statement "import
site" which is the third way to hook into the initialization process.

 

As for the environment variables go, there is a question of naming. One
possibility is to use the well-known names (PYTHONSTARTUP, PYTHONPATH)
and another is to use our own: IRONPYTHONSTARTUP and IRONPYTHONPATH. We
prefer the latter (names prefixed with IRON) to avoid conflicts for
those of us who use CPython and IronPython on the same machine.

 

Unless there is strong reason to use the standard names, we will go
forward with the IRONPYTHON... ones.

 

If you feel one way or another, please let us know. For the purpose of
the environment variable naming, we are not considering other naming
schemes so the choice is either standard names, or IRONPYTHON* ones.

 

Keith, I think this should provide you with the tools you need for your
work, correct? We will try to get this update out even sooner than
usual. 

 

Martin

 

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Keith J. Farmer
Sent: Tuesday, April 26, 2005 4:02 PM
To: Discussion of IronPython
Subject: RE: [IronPython] Saving sys.path

 

Perhaps (to at least keep the .NET way) a .config file instead of an
environment variable?

 

That file *could* specify one or more startup files, to maintain the
Python mystique.

 

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com on behalf of
Michael Spencer
Sent: Tue 4/26/2005 3:52 PM
To: users-ironpython.com at lists.ironpython.com
Subject: [IronPython] Saving sys.path

Second feature request of the week:

I would like to save sys.path settings between interpreter sessions.

Is there a way to do this today?

If not, could there be an OS environment variable for this or, a
startup.py file
loaded each time the interpreter starts?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050427/9ba4eba7/attachment.html>

From mahs at telcopartners.com  Wed Apr 27 19:30:39 2005
From: mahs at telcopartners.com (Michael Spencer)
Date: Wed, 27 Apr 2005 10:30:39 -0700
Subject: [IronPython] Re: Saving sys.path
In-Reply-To: <1E1FC9DA1767ED44872F4E17AC17E8F701C4587F@df-chewy-msg.exchange.corp.microsoft.com>
References: <1E1FC9DA1767ED44872F4E17AC17E8F701C4587F@df-chewy-msg.exchange.corp.microsoft.com>
Message-ID: <d4ohss$lv6$1@sea.gmane.org>

Martin Maly wrote:

> If you feel one way or another, please let us know. For the purpose of
> the environment variable naming, we are not considering other naming
> schemes so the choice is either standard names, or IRONPYTHON* ones.
> 
I agree that any environment variables should be different from CPython's

Also, a temporary solution that might change in future versions would be fine.

Michael



From kfarmer at thuban.org  Wed Apr 27 20:31:06 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Wed, 27 Apr 2005 11:31:06 -0700
Subject: [IronPython] Saving sys.path
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F97@nostromo.circle-cross.home>

Actually, it was Michael who brought it up originally, so maybe ask him?  I just butted in.
 
But...
 
There is a reason I'm not overly fond of environment variables -- they tend to get onerous to manage, and they don't necessarily propagate to user accounts after the admin sets them, as I discovered last night.  I've switched to using a normal user account on my machine, and discovered I couldn't change the global IRONPYTHON_HOME variable I'd created (my path includes %IRONPYTHON_HOME% as a convenience thing)?  So I switched to admin, changed it there, and switched back to my user.  My user still used the old home for 0.7.2.  I had to go back to admin, open up the PATH variable, not change a thing, and re-close it before my user switched to 0.7.3.  
 
Bug in XP?  Almost certainly, IMHO (and I love XP).  Ignorable for managing IronPython installations?  Probably not.  I think a better administrative experience would involve minimizing the dependency on environment variables, and given the built-in mechanisms in .NET
 
In the case of configuring the interpreter, one need not copy the way CPython does it, if it can be argued that IronPython could do it better, by configuring the application rather than the shell.  It'd allow configuration specific to even a version, if needed, and a richer configuration at that.  I'd at least like to see that as an option.
 
I propose IronPython use .config, and override with Environment Variables

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Martin Maly
Sent: Wed 4/27/2005 10:20 AM
To: Discussion of IronPython
Subject: RE: [IronPython] Saving sys.path



There are, as far as I can see, three different ways to help in this case and I am looking into implementing all of them very soon, definitely for the next release.

 

CPython uses environment variables PYTHONSTARTUP and PYTHONPATH to drive the initialization of the interpreter

Also, on initialization, the interpreter executes statement "import site" which is the third way to hook into the initialization process.

 

As for the environment variables go, there is a question of naming. One possibility is to use the well-known names (PYTHONSTARTUP, PYTHONPATH) and another is to use our own: IRONPYTHONSTARTUP and IRONPYTHONPATH. We prefer the latter (names prefixed with IRON) to avoid conflicts for those of us who use CPython and IronPython on the same machine.

 

Unless there is strong reason to use the standard names, we will go forward with the IRONPYTHON... ones.

 

If you feel one way or another, please let us know. For the purpose of the environment variable naming, we are not considering other naming schemes so the choice is either standard names, or IRONPYTHON* ones.

 

Keith, I think this should provide you with the tools you need for your work, correct? We will try to get this update out even sooner than usual. 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 6741 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050427/6f00277a/attachment.bin>

From garthk at gmail.com  Wed Apr 27 22:15:46 2005
From: garthk at gmail.com (Garth T Kidd)
Date: Thu, 28 Apr 2005 06:15:46 +1000
Subject: [IronPython] Re: Re: Nice speed
In-Reply-To: <d4nqp1$b5$1@sea.gmane.org>
References: <d4mj0f$oog$1@sea.gmane.org>
	<adca365a05042617213f9dc245@mail.gmail.com>
	<d4npqi$sus$1@sea.gmane.org>
	<adca365a05042703526538a4ae@mail.gmail.com>
	<d4nqp1$b5$1@sea.gmane.org>
Message-ID: <8aeed5d005042713154a8c8dbe@mail.gmail.com>

Okay, I've switched my subscription to my posting address so my
messages don't get queued. :)

What I said was: given that we're comparing different environments,
[using 'time' is] only a good idea if you also run zero-loop tests so
you can subtract the startup and shutdown costs. I get where Travis is
trying to head on measuring CPU time rather than wall-clock time.

To be *really* careful, of course, one should run a number of tests at
different orders of magnitude to see whether you have algorithmic
scalability problems. Also, it's probably not going to matter whether
you try and measure CPU time or wall time in Python or out of it as
long as you publish your tests and raw data and gathering and publish
any comments pointing out problems, variations on other platforms,
etc.

Regards,
Garth.


From briandorsey at gmail.com  Wed Apr 27 22:23:25 2005
From: briandorsey at gmail.com (Brian Dorsey)
Date: Wed, 27 Apr 2005 13:23:25 -0700
Subject: [IronPython] Saving sys.path
In-Reply-To: <C02467D265F3F64E87DED53F9C3DE29C7F97@nostromo.circle-cross.home>
References: <C02467D265F3F64E87DED53F9C3DE29C7F97@nostromo.circle-cross.home>
Message-ID: <66e877b705042713232687f658@mail.gmail.com>

On 27/04/05, Keith J. Farmer <kfarmer at thuban.org> wrote:
> I've switched to using a normal user account on my machine, and discovered I couldn't change the global IRONPYTHON_HOME variable I'd created (my path includes %IRONPYTHON_HOME% as a convenience thing)?  So I switched to admin, changed it there, and switched back to my user. 

Windows 2000/XP allow you to set both user and system level
environment variables. For my PYTHONPATH environment setting, I use a
user level environment variable and this seems to work fine when I
need it. Maybe the same would work for you? (you may have to delete
the system level variable first.

>In the case of configuring the interpreter, one need not copy the way
CPython does it, if it can be argued that IronPython could do it
better, by configuring the application rather than the shell.  It'd
allow configuration specific to even a version, if needed, and a
richer configuration at that.  I'd at least like to see that as an
option.

CPython also allows some other options, such as using .pth files in
your site-packages folder. This allows configuration of the
application rather than the shell.

>From my perspective as a regular CPython user on windows, .pth files
have generally worked well for me, and I use them instead of
environment variables for the most part.

Take care,
-Brian


From garthk at gmail.com  Wed Apr 27 11:50:49 2005
From: garthk at gmail.com (Garth T Kidd)
Date: Wed, 27 Apr 2005 19:50:49 +1000
Subject: [IronPython] Nice speed
In-Reply-To: <adca365a05042617213f9dc245@mail.gmail.com>
References: <d4mj0f$oog$1@sea.gmane.org>
	<adca365a05042617213f9dc245@mail.gmail.com>
Message-ID: <8aeed5d00504270250617b348f@mail.gmail.com>

> Never trust the program you're running to give you accurate time. Use
> 'time python foo.py' instead. 

Given that we're comparing different environments, that's only a good
idea if you also run zero-loop tests so you can subtract the startup
and shutdown costs.

Regards,
Garth.


From kfarmer at thuban.org  Wed Apr 27 22:44:34 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Wed, 27 Apr 2005 13:44:34 -0700
Subject: [IronPython] Saving sys.path
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F98@nostromo.circle-cross.home>

I'd set a user-level environment variable as well, checking that out, but it seemed a kludge at best.  In a multi-user environment it'd be a hassle.  For deployment to multiple machines, it'd be annoying at best.
 
With respect, I'll maintain my stance of using .config files as the mechanism supported by .NET.  I'd prefer unifying under that, rather than trying to grandfather in a variety of -isms from CPython.  I should point out that nothing prevents IronPython from having the capability to support both -- one as standard, the other as override, if grandfather it must.
 
In fact, I think it'd make much more sense to support .config.  Consider the possibility of embedding IronPython in a C# app, or an ASP.NET app, or of producing IronPython modules for use in the rest of .NET -- in any of these cases, the consuming developers are going to expect .config files rather than environment variables, and rightly so.  We shouldn't have to special case the configuration mechanism, just to make it work with peers under the same runtime.  Apps using the CLR use .config files, and I think IronPython should take that into consideration.
 
(Python was my favorite language until C# came along.  Maybe with IronPython-omega with generics...)

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Brian Dorsey
Sent: Wed 4/27/2005 1:23 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Saving sys.path

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 4377 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050427/2c15fe1d/attachment.bin>

From briandorsey at gmail.com  Wed Apr 27 23:09:20 2005
From: briandorsey at gmail.com (Brian Dorsey)
Date: Wed, 27 Apr 2005 14:09:20 -0700
Subject: [IronPython] Saving sys.path
In-Reply-To: <C02467D265F3F64E87DED53F9C3DE29C7F98@nostromo.circle-cross.home>
References: <C02467D265F3F64E87DED53F9C3DE29C7F98@nostromo.circle-cross.home>
Message-ID: <66e877b705042714097442068f@mail.gmail.com>

On 27/04/05, Keith J. Farmer <kfarmer at thuban.org> wrote:
> I'd set a user-level environment variable as well, checking that out, but it seemed a kludge at best.  In a multi-user environment it'd be a hassle.  For deployment to multiple machines, it'd be annoying at best.

Indeed. In that scenario I'd install directly into site-packages or
add a .pth file into site-packages. Or, like I usually do for windows
deployments, package it up with py2exe and an installer. :)  (however,
as you can see, I'm firmly in CPython land... what does
'site-packages' even mean in a DotNet assembly? :)

> With respect, I'll maintain my stance of using .config files as the mechanism supported by .NET.  I'd prefer unifying under that, rather than trying to grandfather in a variety of -isms from CPython.  I should point out that nothing prevents IronPython from having the capability to support both -- one as standard, the other as override, if grandfather it must.

If both are needed (and your scenario below is pretty convincing) then
supporting both would work for me. I guess the principle I'm hoping
for is that for the most part a CPython person should be able to just
start using IronPythonConsole.exe (or whatever) instead of python.exe,
at least for simple apps. The only difference being that suddenly the
CLR is available.

> In fact, I think it'd make much more sense to support .config.  Consider the possibility of embedding IronPython in a C# app, or an ASP.NET app, or of producing IronPython modules for use in the rest of .NET -- in any of these cases, the consuming developers are going to expect .config files rather than environment variables, and rightly so.  We shouldn't have to special case the configuration mechanism, just to make it work with peers under the same runtime.  Apps using the CLR use .config files, and I think IronPython should take that into consideration.

Yes indeed. I suppose there are a lot of questions there, which I
hadn't even considered. Would all of your modules be 'frozen' into the
assembly?

Anyway, I've passed far beyond my experience here, so I'm going to
stop. I just wanted to make the point that people coming from CPython
are going to expect to be able to use environment variables and .pth
files.

Take care,
-Brian


From kfarmer at thuban.org  Wed Apr 27 23:50:42 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Wed, 27 Apr 2005 14:50:42 -0700
Subject: [IronPython] Saving sys.path
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F9A@nostromo.circle-cross.home>

I agree that the env vars and the .pth present a migration path -- and that's a good thing I don't intend to disagree with.
 
Freezing of modules:  funny you should mention that.  I recall a somewhat undermentioned feature of assemblies being composable from several seperate files, referred to as modules.  That's beyond my experience, as well, and I imagine depends greatly on how Jim and Martin construct the assembly to begin with.
 
Site-Packages:  Global Assembly Cache, I think.  When you install J#, it installs J# framework assemblies in such a way that they're accessible from C#.  The same I think should be done here.  I can see a tool being created to convert a stock Python package into IL and importing it into the GAC.  It's a difference in installation, that makes it appropriate for the new platform.
 
Anyway, I'm supposed to be head-down in some gruesome Java, which is neither Python nor .NET, so I should shut up for a while and let the sub-Guidos speak.
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3925 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050427/4db38673/attachment.bin>

From luismg at gmx.net  Thu Apr 28 14:20:35 2005
From: luismg at gmx.net (Luis M. Gonzalez)
Date: Thu, 28 Apr 2005 09:20:35 -0300
Subject: [IronPython] Not GotDotNet...
Message-ID: <000501c54bec$b28d0ac0$1302a8c0@luis>

In my expererince, one out of three times I visit GotDotNet the site is 
down.
I've been rying to submit a bug since yesterday, but this is what I see:

"Operational Troubleshooting in Progress
The Gotdotnet team is aware of the current site operational issues and is 
working on a solution. Thanks for your patience."

I also noted that when it's up, it is slow and buggy.
I'd like to ask to the Ironpython team to seriously consider another 
alternative...
The problems with this site are very annoying to those who visit it 
regularly.

Regards,
Luis 



From jimhug at exchange.microsoft.com  Thu Apr 28 18:07:06 2005
From: jimhug at exchange.microsoft.com (Jim Hugunin)
Date: Thu, 28 Apr 2005 09:07:06 -0700
Subject: [IronPython] Not GotDotNet...
Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201B76E77@df-fido-msg.exchange.corp.microsoft.com>

Luis M. Gonzalez wrote:
> In my expererince, one out of three times I visit GotDotNet the site
is
> down.
> I've been rying to submit a bug since yesterday, but this is what I
see:
> 
> "Operational Troubleshooting in Progress
> The Gotdotnet team is aware of the current site operational issues and
is
> working on a solution. Thanks for your patience."
> 
> I also noted that when it's up, it is slow and buggy.
> I'd like to ask to the Ironpython team to seriously consider another
> alternative...
> The problems with this site are very annoying to those who visit it
> regularly.

We are looking into alternatives to GotDotNet (GDN); however, this is
not going to be a fast process.  I don't think that you can expect
improvements to the IronPython GDN site for at least several months.
Given the feedback we've had regarding GDN, we've made sure that you can
actively participate in the IronPython community without needing to ever
use that site.

Community discussion - All discussions are happening on this mailing
list.  I just turned off the virtually unused GDN forum that no one
liked.  We're also more actively handling moderation requests on this
mailing list to make sure messages don't get stuck in the mailman spam
filters.

Download site - You can always download the latest release from
downloads.microsoft.com without going through GDN.  This download site
is one of the more reliable and better supported download sites you'll
find for any project of this type.  The announcement email sent to this
list always includes a direct link to that download site.

Bug reporting - The GDN bug tracker is still the best option that we
have for a publicly searchable and editable bug database.  However, we
also made available the address ironpy at microsoft.com to handle bug
reports.  You can either send your bug reports to that alias or send
them directly to this list if you think they'd be interesting to a wider
audience.  We have a separate bug tracking tool that we use internally
to make sure we don't lose track of bugs that you submit this way.  We
know that this isn't ideal and want to get a publicly searchable and
editable bug database in place; however, don't let GDN stop you from
submitting your bugs.

Source code - We currently ship source code with every release and new
drops are out every 1-2 weeks.  We also know that this isn't ideal and
that many people would prefer a live cvs or svn repository.

Thanks - Jim


From martmaly at exchange.microsoft.com  Thu Apr 28 20:58:58 2005
From: martmaly at exchange.microsoft.com (Martin Maly)
Date: Thu, 28 Apr 2005 11:58:58 -0700
Subject: [IronPython] Not GotDotNet...
Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701C45D19@df-chewy-msg.exchange.corp.microsoft.com>

We are aware of the problems with GotDotNet and are looking for the
long-term solution.

If you have problems reporting bugs on the site, you can send email with
the bug description to "ironpy (at) microsoft (dot) com" or even to this
mailing list and we will take the bug from there. 

Martin

> Luis M. Gonzalez Wrote:
> In my expererince, one out of three times I visit GotDotNet
> the site is down.
>
> I've been rying to submit a bug since yesterday, but this is what I
see:
>
> "Operational Troubleshooting in Progress
> The Gotdotnet team is aware of the current site operational issues and
is 
> working on a solution. Thanks for your patience."

> I also noted that when it's up, it is slow and buggy.
> I'd like to ask to the Ironpython team to seriously consider another 
> alternative...
> The problems with this site are very annoying to those who visit it 
> regularly.

> Regards,
> Luis



From amigrave at gmail.com  Fri Apr 29 11:27:44 2005
From: amigrave at gmail.com (Fabien Meghazi)
Date: Fri, 29 Apr 2005 11:27:44 +0200
Subject: [IronPython] Executing a python source from C#
Message-ID: <7772a25905042902275751df9f@mail.gmail.com>

Hi all,

How can I execute some python code that I have in a String() from a C# .NET
program or an aspx application ?
I also would like to get back the stdout that the python code produced.

Is it possible ?

-- 
Fabien Meghazi
http://www.amigrave.com


From jimhug at exchange.microsoft.com  Fri Apr 29 19:00:18 2005
From: jimhug at exchange.microsoft.com (Jim Hugunin)
Date: Fri, 29 Apr 2005 10:00:18 -0700
Subject: [IronPython] Executing a python source from C#
Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201BF2ACC@df-fido-msg.exchange.corp.microsoft.com>

Fabien Meghazi wrote:
> How can I execute some python code that I have in a String() from a C#
> .NET
> program or an aspx application ?
> I also would like to get back the stdout that the python code
produced.

You want to use IronPython.Hosting.PythonEngine.  Here's a simple
example program.  We're very interested in feedback on experiences with
hosting IronPython from other .NET languages as that's an important
scenario, but not one that I have much personal experience with.

Does this give you what you're looking for? - Jim

----------------------------------------------
using System;
using System.Collections.Generic;
using System.Text;
using System.Diagnostics;

using IronPython.Hosting;

namespace HostingDemo {
    class Program {
        static void Main(string[] args) {
            PythonEngine engine = new PythonEngine();

            // evaluating a Python expression to get an object back
            string expr = "2+2";
            Console.WriteLine("{0} = {1}", expr, engine.Evaluate(expr));

            // executing a chunk of Python code
            string stmt = "for i in range(6):\n\tprint '***'*(i+1)";
            engine.Execute(stmt);

            // exposing variables to Python code
            Program p = new Program();
            engine.SetVariable("app", p);
            string s =
(string)engine.Evaluate("app.GetImportantString()");
            Debug.Assert(s == p.GetImportantString());

            // capturing stdout - this should be much cleaner
            // using code outside of IronPython.Hosting will be much
less 
            // stable than code inside of IronPython.Hosting
            OutputCollector output = new OutputCollector();
            IronPython.Modules.sys.stdout = output;
            engine.Execute(stmt);
            string result = output.buffer.ToString();
            Console.WriteLine("got string of length {0}",
result.Length);
 
Console.WriteLine(IronPython.Objects.StringOps.Quote(result));
        }

        public string GetImportantString() {
            return "ni";
        }

        // A quick hack, not the ideal framework design
        class OutputCollector {
            public StringBuilder buffer = new StringBuilder();

            public bool softspace = false; // weird Python print feature
            public void write(string data) {
                buffer.Append(data);
            }
        }
    }
}


From kfarmer at thuban.org  Fri Apr 29 19:35:01 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Fri, 29 Apr 2005 10:35:01 -0700
Subject: [IronPython] Executing a python source from C#
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F9C@nostromo.circle-cross.home>

What happens if we send in a partial block, as might happen when creating an embeddable console?

		string stmt = "for i in range(6):";
		engine.Execute(stmt);

Or is it expected that we ensure that such things don't happen?

 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3183 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050429/0386cd02/attachment.bin>

From jimhug at exchange.microsoft.com  Fri Apr 29 19:46:24 2005
From: jimhug at exchange.microsoft.com (Jim Hugunin)
Date: Fri, 29 Apr 2005 10:46:24 -0700
Subject: [IronPython] Executing a python source from C#
Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201BF2B21@df-fido-msg.exchange.corp.microsoft.com>

That will generate a SyntaxError just as if you passed a partial block to exec.  If you're interested in experimenting with embeddable consoles, you should take a look at the code for IronPythonConsole which also uses PythonEngine to do its loops.

Ultimately, I think that IronPython should ship with a standard interactive console for both winforms and avalon that have a few customization hooks but are designed to be easily plugged into your apps.  I'm still not sure if this embeddable console should be written in C# or in IronPython itself and am curious to hear the results of experiments using either approach.  I'm leaning towards the idea of building it, and even the standard command-line console, in IronPython.

Thanks - Jim

________________________________________
From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer
Sent: Friday, April 29, 2005 10:35 AM
To: Discussion of IronPython
Subject: RE: [IronPython] Executing a python source from C#

What happens if we send in a partial block, as might happen when creating an embeddable console?
string stmt = "for i in range(6):";
engine.Execute(stmt);
Or is it expected that we ensure that such things don't happen?
?


From kfarmer at thuban.org  Fri Apr 29 20:27:29 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Fri, 29 Apr 2005 11:27:29 -0700
Subject: [IronPython] Executing a python source from C#
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F9D@nostromo.circle-cross.home>

I think having a standard interface for creating consoles would be a great way to implement IronPython's console.  Being able to swap in semi-arbitrary languages into FooConsole could be useful for a variety of apps.
 
public delegate ConsoleInputHandler(string input);
 
IConsole console = new Console<IronPythonInterpreter>(consoleSettings, consoleHistory);
console.OnInput += new ConsoleInputHandler(OnInput);
 
public void OnInput(string input)
{

		
		console.SubmitLine(input);
		 
		switch(console.State)
		{

				case ConsoleState.ContinueLine: { console.Prompt = ConsolePrompt.Continue; break; }
				case ConsoleState.NewLine: { console.ExecuteCurrentLine();  prompt = ConsolePrompt.New; break; }

		}

}
 
.. back to Java sloggery.

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Jim Hugunin
Sent: Fri 4/29/2005 10:46 AM
To: Discussion of IronPython
Subject: RE: [IronPython] Executing a python source from C#



That will generate a SyntaxError just as if you passed a partial block to exec.  If you're interested in experimenting with embeddable consoles, you should take a look at the code for IronPythonConsole which also uses PythonEngine to do its loops.

Ultimately, I think that IronPython should ship with a standard interactive console for both winforms and avalon that have a few customization hooks but are designed to be easily plugged into your apps.  I'm still not sure if this embeddable console should be written in C# or in IronPython itself and am curious to hear the results of experiments using either approach.  I'm leaning towards the idea of building it, and even the standard command-line console, in IronPython.

Thanks - Jim

________________________________________
From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer
Sent: Friday, April 29, 2005 10:35 AM
To: Discussion of IronPython
Subject: RE: [IronPython] Executing a python source from C#

What happens if we send in a partial block, as might happen when creating an embeddable console?
string stmt = "for i in range(6):";
engine.Execute(stmt);
Or is it expected that we ensure that such things don't happen?
 
_______________________________________________
users-ironpython.com mailing list
users-ironpython.com at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 6163 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050429/916dd39d/attachment.bin>

From ryan at acceleration.net  Fri Apr 29 22:48:36 2005
From: ryan at acceleration.net (Ryan Davis)
Date: Fri, 29 Apr 2005 16:48:36 -0400
Subject: [IronPython] Executing a python source from C#
In-Reply-To: <C02467D265F3F64E87DED53F9C3DE29C7F9D@nostromo.circle-cross.home>
Message-ID: <20050429204628.AFD1684D22@che.dreamhost.com>

What I'd really like is the ability to create a .dll that we reference in other .NET apps, just as now we can write a class library
in C# and use it in a VB.NET web application.
 
I have zero clue of the complexity of that task, but that'd be my ideal.  I imagine that'd be pretty hard, given the differences in
function declaration semantics alone.  I'm thinking of **kwargs and default parameters, specifically.  I don't know how that would
map to a C# compatible signature.  I guess for default parameters:
 
def foo(a=1, b=2, c=4):
 
you could make successive overloads that call one "master" version:
 
int foo(a)
int foo(a,b)
int foo(a,b,c)
 
but then there's no way to do the equivalent of foo(b=3) without running into ambiguity, and you end up having to do a lot more
function calls than you really should.  
 
.. back to C# sloggery.
Thanks,
Ryan 
  _____  

From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Keith J. Farmer
Sent: Friday, April 29, 2005 2:27 PM
To: Discussion of IronPython
Subject: RE: [IronPython] Executing a python source from C#
 
I think having a standard interface for creating consoles would be a great way to implement IronPython's console.  Being able to
swap in semi-arbitrary languages into FooConsole could be useful for a variety of apps.
 
public delegate ConsoleInputHandler(string input);
 
IConsole console = new Console<IronPythonInterpreter>(consoleSettings, consoleHistory);
console.OnInput += new ConsoleInputHandler(OnInput);
 
public void OnInput(string input)
{
console.SubmitLine(input);
 
switch(console.State)
{
case ConsoleState.ContinueLine: { console.Prompt = ConsolePrompt.Continue; break; }
case ConsoleState.NewLine: { console.ExecuteCurrentLine();  prompt = ConsolePrompt.New; break; }
}
}
 
.. back to Java sloggery.
 
  _____  

From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Jim Hugunin
Sent: Fri 4/29/2005 10:46 AM
To: Discussion of IronPython
Subject: RE: [IronPython] Executing a python source from C#
That will generate a SyntaxError just as if you passed a partial block to exec.  If you're interested in experimenting with
embeddable consoles, you should take a look at the code for IronPythonConsole which also uses PythonEngine to do its loops.

Ultimately, I think that IronPython should ship with a standard interactive console for both winforms and avalon that have a few
customization hooks but are designed to be easily plugged into your apps.  I'm still not sure if this embeddable console should be
written in C# or in IronPython itself and am curious to hear the results of experiments using either approach.  I'm leaning towards
the idea of building it, and even the standard command-line console, in IronPython.

Thanks - Jim

________________________________________
From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of
Keith J. Farmer
Sent: Friday, April 29, 2005 10:35 AM
To: Discussion of IronPython
Subject: RE: [IronPython] Executing a python source from C#

What happens if we send in a partial block, as might happen when creating an embeddable console?
string stmt = "for i in range(6):";
engine.Execute(stmt);
Or is it expected that we ensure that such things don't happen?
 
_______________________________________________
users-ironpython.com mailing list
users-ironpython.com at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 11046 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050429/e787c5de/attachment.bin>

From kfarmer at thuban.org  Fri Apr 29 23:13:13 2005
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Fri, 29 Apr 2005 14:13:13 -0700
Subject: [IronPython] Executing a python source from C#
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C7F9E@nostromo.circle-cross.home>

.NET Attributes have a similar calling mechanism in C#:
 
[FooAttribute(1, 2, A=3, B=4)]
 
To use the named parameters, I believe FooAttribute must implement A and B as properties.  Since attributes are classes, one can instantiate them, and set properties at that time.
 
Not exactly the way I think it'd work for a method, but I imagine compiler magic would happen similarly, without ambiguity.
 
blah()
bar = foo(b=3) 
blah()
 
-> 
blah();
 
fooParams = new FooParams(); 
fooParams.b = 3; 
bar = MagicFoo(fooParams);
 
blah();
 
.....
 
private struct FooParams
{
    aType a; 
    bType b; 
    cType c;
 
    public FooParams()
    {
        this.a = defaultA;
        this.b = defaultB;
        this.c = defaultC;
    }
}
 
private FooReturnType MagicFoo(FooParams fooParams)
{
    return foo(fooParams.a, fooParams.b, fooParams.c);
}
 
Disclaimer:  you don't want to know what I'm talking out of.  I'm just in it for the fun thought experiments.
... and to avoid thinking of how long it takes Eclipse to get out of swap space.

________________________________

From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Ryan Davis
Sent: Fri 4/29/2005 1:48 PM
To: 'Discussion of IronPython'
Subject: RE: [IronPython] Executing a python source from C#


What I'd really like is the ability to create a .dll that we reference in other .NET apps, just as now we can write a class library in C# and use it in a VB.NET web application.
 
I have zero clue of the complexity of that task, but that'd be my ideal.  I imagine that'd be pretty hard, given the differences in function declaration semantics alone.  I'm thinking of **kwargs and default parameters, specifically.  I don't know how that would map to a C# compatible signature.  I guess for default parameters:
 
def foo(a=1, b=2, c=4):
 
you could make successive overloads that call one "master" version:
 
int foo(a)
int foo(a,b)
int foo(a,b,c)
 
but then there's no way to do the equivalent of foo(b=3) without running into ambiguity, and you end up having to do a lot more function calls than you really should.  
 
.. back to C# sloggery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 8875 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050429/26958eec/attachment.bin>