From estebistec at gmail.com Fri Feb 18 16:41:18 2005 From: estebistec at gmail.com (Steven Cummings) Date: Fri, 18 Feb 2005 09:41:18 -0600 Subject: [IronPython] import-as supported? Message-ID: Does this Python language feature exist in IronPython yet? I tried import System.Windows.Forms as WinForms and in trying to extend WinForms.Form I got the error "package has no attribute...". Thanks. /S From estebistec at gmail.com Fri Feb 18 16:43:19 2005 From: estebistec at gmail.com (Steven Cummings) Date: Fri, 18 Feb 2005 09:43:19 -0600 Subject: [IronPython] Base-class constructor Message-ID: I apologize if this has already been discussed on the list, but I couldn't find anything by searcing in the archives. I'm trying to call the constructor of Form as follows: class MyForm(System.Windows.Forms.Form): def __init__(self, title): System.Windows.Forms.Form.__init__(self) .... and I'm getting an attribute error on __init__. So how do I get the base-constructor? Thanks. /S From andy_somogyi at hotmail.com Fri Feb 18 21:52:13 2005 From: andy_somogyi at hotmail.com (Andy Somogyi) Date: Fri, 18 Feb 2005 13:52:13 -0700 Subject: [IronPython] IronPython status Message-ID: Hello All As I have not seen much updates on IronPython recently, and I believe it is a superb product and tremendous potential, I have recently begun the process of looking for and fixing bugs in the IronPython distribution. So far, I have fixed the issue with a module not storing the __name__ attribute properly, eval not parsing input string correctly, and the map function not working when given more than 2 arguments. If Jim has no objections, I have created a CVS repository with all the fixes at: http://cvs.sourceforge.net/viewcvs.py/numerator/IronPython-0.6/ Also, if Jim has no objections, you can submit bug reports at: http://sourceforge.net/tracker/?atid=594164&group_id=90590&func=browse I have also started documenting IronPython, and I will be producing ndoc generated help files. From ryan4096 at bellsouth.net Tue Feb 22 01:15:01 2005 From: ryan4096 at bellsouth.net (Ryan Williams) Date: Mon, 21 Feb 2005 19:15:01 -0500 Subject: [IronPython] IronPython status In-Reply-To: References: Message-ID: <1109031301.30307.3.camel@localhost.localdomain> Personally, I think it's great that someone wants to work on it. I really like the idea of IronPython, and have been disappointed to see the current lack of activity. On Fri, 2005-02-18 at 13:52 -0700, Andy Somogyi wrote: > Hello All > > As I have not seen much updates on IronPython recently, and I believe it is > a superb product and tremendous potential, I have recently begun the process > of looking for and fixing bugs in the IronPython distribution. > > So far, I have fixed the issue with a module not storing the __name__ > attribute properly, eval not parsing input string correctly, and the map > function not working when given more than 2 arguments. > > If Jim has no objections, I have created a CVS repository with all the fixes > at: > > http://cvs.sourceforge.net/viewcvs.py/numerator/IronPython-0.6/ > > Also, if Jim has no objections, you can submit bug reports at: > http://sourceforge.net/tracker/?atid=594164&group_id=90590&func=browse > > I have also started documenting IronPython, and I will be producing ndoc > generated help files. > > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From hchrholm at online.no Tue Feb 22 09:06:21 2005 From: hchrholm at online.no (Hans-Christian Holm) Date: Tue, 22 Feb 2005 09:06:21 +0100 Subject: [IronPython] IronPython status References: <1109031301.30307.3.camel@localhost.localdomain> Message-ID: <001601c518b5$65896ee0$0b00a8c0@HC6> In the meanwhile, I would suggest a look at Boo, a great new CLR language (http://boo.codehaus.org/). It's not Python, but very similiar. It lacks some of the more dynamic features of Python, but compensates well for that in other areas. And it works, today. I might even prefer Boo to IronPython even if IronPython should reach a more mature stage. Hans-Christian ----- Original Message ----- From: "Ryan Williams" To: Sent: Tuesday, February 22, 2005 1:15 AM Subject: Re: [IronPython] IronPython status > Personally, I think it's great that someone wants to work on it. I > really like the idea of IronPython, and have been disappointed to see > the current lack of activity. > > On Fri, 2005-02-18 at 13:52 -0700, Andy Somogyi wrote: >> Hello All >> >> As I have not seen much updates on IronPython recently, and I believe it >> is >> a superb product and tremendous potential, I have recently begun the >> process >> of looking for and fixing bugs in the IronPython distribution. >> >> So far, I have fixed the issue with a module not storing the __name__ >> attribute properly, eval not parsing input string correctly, and the map >> function not working when given more than 2 arguments. >> >> If Jim has no objections, I have created a CVS repository with all the >> fixes >> at: >> >> http://cvs.sourceforge.net/viewcvs.py/numerator/IronPython-0.6/ >> >> Also, if Jim has no objections, you can submit bug reports at: >> http://sourceforge.net/tracker/?atid=594164&group_id=90590&func=browse >> >> I have also started documenting IronPython, and I will be producing ndoc >> generated help files. >> >> >> _______________________________________________ >> 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 andy_somogyi at hotmail.com Tue Feb 22 19:22:13 2005 From: andy_somogyi at hotmail.com (Andy Somogyi) Date: Tue, 22 Feb 2005 11:22:13 -0700 Subject: [IronPython] IronPython status In-Reply-To: <001601c518b5$65896ee0$0b00a8c0@HC6> Message-ID: I did take a look at Boo, hoping to use some code / ideas of thier implementation. It is kind of an interesting implementation, they seem to be very fond of many many classes where each one has very little functionality by itself. Also, part of the Boo implementation is in c# and the other part is in Boo. I am really not fond of interpreters written in the interpretting language. I think the CPython / Jython / IronPython approach is MUCH better, faster, more stable and easier to follow. Also, I am not very fond of 'like' languages, i.e. a 'C' like language or a 'Java' like language, or in this case a 'Python' like language. I like IronPython because it IS Python, not 'like' Python. Also, IronPython is well designed and it is fairly easy to follow and understand the code. The syntactic and semantic portions of IronPython are nearly perfect, it has a well consturcted recursive descent parser that generates a tradational AST. The runtime portion of IronPython just needs some work. With my 'fork' of IronPython, I'm implementing the runtime slightly differently. Currently, all python objects are of a type called 'DynamicType'. When a native .net assembly is imported, all the types are wrapped in a derivitive of 'DynamicType'. Now, the .net runtime allready supports the features of this type via the 'IReflect' and 'IExpando' interfaces. So, what I am going to do is this: All Python types will implement the IReflect and optionally the IExpando interface. Python functions will extend the standard 'MethodInfo' interface. Then all generated code will operate on these standard interfaces. The advantage is that .net assemblys can be imported directly, without having to wrap the types in a python type, and all Python objects can be visible to external programs using the standard reflection interfaces. The other nice thing about the MethodInfo interface is that in .net 2.0 there is a new feature called 'lightweight code generation': Basically, you can create a new fully dynamic method. This new method is not part of a type, and can be garbage collected like any other .net object. So, the .net 'DynamicMethod' type implements the 'MethodInfo' interface, and when IronPython moves to .net 2.0, the new lightweight code generation features can be seamlessly added. >In the meanwhile, I would suggest a look at Boo, a great new CLR language >(http://boo.codehaus.org/). It's not Python, but very similiar. It lacks >some of the more dynamic features of Python, but compensates well for that >in other areas. And it works, today. I might even prefer Boo to IronPython >even if IronPython should reach a more mature stage. > >Hans-Christian > >----- Original Message ----- From: "Ryan Williams" >To: >Sent: Tuesday, February 22, 2005 1:15 AM >Subject: Re: [IronPython] IronPython status > > >>Personally, I think it's great that someone wants to work on it. I >>really like the idea of IronPython, and have been disappointed to see >>the current lack of activity. >> >>On Fri, 2005-02-18 at 13:52 -0700, Andy Somogyi wrote: >>>Hello All >>> >>>As I have not seen much updates on IronPython recently, and I believe it >>>is >>>a superb product and tremendous potential, I have recently begun the >>>process >>>of looking for and fixing bugs in the IronPython distribution. >>> >>>So far, I have fixed the issue with a module not storing the __name__ >>>attribute properly, eval not parsing input string correctly, and the map >>>function not working when given more than 2 arguments. >>> >>>If Jim has no objections, I have created a CVS repository with all the >>>fixes >>>at: >>> >>>http://cvs.sourceforge.net/viewcvs.py/numerator/IronPython-0.6/ >>> >>>Also, if Jim has no objections, you can submit bug reports at: >>>http://sourceforge.net/tracker/?atid=594164&group_id=90590&func=browse >>> >>>I have also started documenting IronPython, and I will be producing ndoc >>>generated help files. >>> >>> >>>_______________________________________________ >>>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 brian at zope.com Tue Feb 22 19:44:03 2005 From: brian at zope.com (Brian Lloyd) Date: Tue, 22 Feb 2005 13:44:03 -0500 Subject: [IronPython] IronPython status In-Reply-To: Message-ID: <20050222184404.5950A3B8038@smtp.zope.com> > Also, I am not very fond of 'like' languages, i.e. a 'C' like > language or a 'Java' like language, or in this case a 'Python' > like language. I definitely agree with the general sentiment here - though there are still some issues ahead with Python on the CLR that will probably need to be dealt with (attributes, etc.) > Now, the .net runtime allready supports the features of this > type via the 'IReflect' and 'IExpando' interfaces. > > So, what I am going to do is this: All Python types will > implement the IReflect and optionally the IExpando interface. > Python functions will extend the standard 'MethodInfo' interface. > Then all generated code will operate on these standard interfaces. Have you been able to find any concise info on IExpando? I've had an inkling that it could be useful for (unmanaged)Python with .NET, but it seems underdocumented... BTW, I'd be happy to lend a hand on this stuff. I was really hoping that there would be an update on the 'official' status of IP, but in the meantime I'm happy to contribute in the hope that this work will be merged in later... Brian Lloyd brian at zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com From steven at wilcoxzone.com Tue Feb 22 19:46:15 2005 From: steven at wilcoxzone.com (Steven Wilcox) Date: Tue, 22 Feb 2005 13:46:15 -0500 Subject: [IronPython] IronPython status In-Reply-To: Message-ID: <20050222184618.LTYZ2073.imf18aec.mail.bellsouth.net@celerond28> I want to agree here that Boo is fundamentally flawed in that it really is only "like" Python. Probably the worst thing they did was choose the ":" for variable parameter inputs to .net library functions. That was just a cheap way out of coding corner they'd gotten into. What that does, with just one single character is wreck huge amounts of Python compatibility. You see it with other areas as well. The beauty of Python is its built-in constructs and types. To be able to use lists, tuples and dictionaries... to be able to iterate over them without having to know ahead of time the object type... and then to wield that power against a nice set of libraries in .NET (especially for the UI) is a powerful combination. But really my point here is that sticking close to the original language is a good idea. The primary key to IronPython success exists in finishing what has been started... -ScW -----Original Message----- From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Andy Somogyi Sent: Tuesday, February 22, 2005 1:22 PM To: users-ironpython.com at lists.ironpython.com Subject: Re: [IronPython] IronPython status I did take a look at Boo, hoping to use some code / ideas of thier implementation. It is kind of an interesting implementation, they seem to be very fond of many many classes where each one has very little functionality by itself. Also, part of the Boo implementation is in c# and the other part is in Boo. I am really not fond of interpreters written in the interpretting language. I think the CPython / Jython / IronPython approach is MUCH better, faster, more stable and easier to follow. Also, I am not very fond of 'like' languages, i.e. a 'C' like language or a 'Java' like language, or in this case a 'Python' like language. I like IronPython because it IS Python, not 'like' Python. Also, IronPython is well designed and it is fairly easy to follow and understand the code. The syntactic and semantic portions of IronPython are nearly perfect, it has a well consturcted recursive descent parser that generates a tradational AST. The runtime portion of IronPython just needs some work. With my 'fork' of IronPython, I'm implementing the runtime slightly differently. Currently, all python objects are of a type called 'DynamicType'. When a native .net assembly is imported, all the types are wrapped in a derivitive of 'DynamicType'. Now, the .net runtime allready supports the features of this type via the 'IReflect' and 'IExpando' interfaces. So, what I am going to do is this: All Python types will implement the IReflect and optionally the IExpando interface. Python functions will extend the standard 'MethodInfo' interface. Then all generated code will operate on these standard interfaces. The advantage is that .net assemblys can be imported directly, without having to wrap the types in a python type, and all Python objects can be visible to external programs using the standard reflection interfaces. The other nice thing about the MethodInfo interface is that in .net 2.0 there is a new feature called 'lightweight code generation': Basically, you can create a new fully dynamic method. This new method is not part of a type, and can be garbage collected like any other .net object. So, the .net 'DynamicMethod' type implements the 'MethodInfo' interface, and when IronPython moves to .net 2.0, the new lightweight code generation features can be seamlessly added. >In the meanwhile, I would suggest a look at Boo, a great new CLR language >(http://boo.codehaus.org/). It's not Python, but very similiar. It lacks >some of the more dynamic features of Python, but compensates well for that >in other areas. And it works, today. I might even prefer Boo to IronPython >even if IronPython should reach a more mature stage. > >Hans-Christian > >----- Original Message ----- From: "Ryan Williams" >To: >Sent: Tuesday, February 22, 2005 1:15 AM >Subject: Re: [IronPython] IronPython status > > >>Personally, I think it's great that someone wants to work on it. I >>really like the idea of IronPython, and have been disappointed to see >>the current lack of activity. >> >>On Fri, 2005-02-18 at 13:52 -0700, Andy Somogyi wrote: >>>Hello All >>> >>>As I have not seen much updates on IronPython recently, and I believe it >>>is >>>a superb product and tremendous potential, I have recently begun the >>>process >>>of looking for and fixing bugs in the IronPython distribution. >>> >>>So far, I have fixed the issue with a module not storing the __name__ >>>attribute properly, eval not parsing input string correctly, and the map >>>function not working when given more than 2 arguments. >>> >>>If Jim has no objections, I have created a CVS repository with all the >>>fixes >>>at: >>> >>>http://cvs.sourceforge.net/viewcvs.py/numerator/IronPython-0.6/ >>> >>>Also, if Jim has no objections, you can submit bug reports at: >>>http://sourceforge.net/tracker/?atid=594164&group_id=90590&func=browse >>> >>>I have also started documenting IronPython, and I will be producing ndoc >>>generated help files. >>> >>> >>>_______________________________________________ >>>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 brian at zope.com Tue Feb 22 20:04:01 2005 From: brian at zope.com (Brian Lloyd) Date: Tue, 22 Feb 2005 14:04:01 -0500 Subject: [IronPython] IronPython status In-Reply-To: <20050222184618.LTYZ2073.imf18aec.mail.bellsouth.net@celerond28> Message-ID: <20050222190403.08F9B3B8038@smtp.zope.com> > The beauty of Python is its built-in constructs and types. > To be able to > use lists, tuples and dictionaries... to be able to iterate over them > without having to know ahead of time the object type... and > then to wield > that power against a nice set of libraries in .NET > (especially for the UI) > is a powerful combination. > > But really my point here is that sticking close to the > original language is > a good idea. The primary key to IronPython success exists in > finishing what > has been started... Agreed - it would be helpful, I think, for those who are interested to come up with a prioritized list of what needs to be done to 'finish'. There appears to be some desire and momentum from people willing to contribute, so we should take advantage of that and reconcile things when Jim re-surfaces ;) Brian Lloyd brian at zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com From luismg at gmx.net Tue Feb 22 20:05:34 2005 From: luismg at gmx.net (Luis M. Gonzalez) Date: Tue, 22 Feb 2005 16:05:34 -0300 Subject: Subject: [IronPython] IronPython status References: <20050219200541.D23E0988AD@che.dreamhost.com> Message-ID: <000a01c51911$7f593ba0$1302a8c0@luis> Also, part of the Boo implementation is in c# and the other part is in Boo. I am really not fond of interpreters written in the interpretting language. I think the CPython / Jython / IronPython approach is MUCH better, faster, more stable and easier to follow. I guess you have some misconceptions about these languages: Boo is written in C# and soon it will be written in Boo itself (when .net 2.0 is stable). It is a first class .Net language and it has the same performance of C#, VB.NET or any other statically typed .NET language. Regarding Ironpython, it is also being written in C# (please correct me if I'm wrong). But this is not important at all, as long as the resulting code when using these languages is MSIL, which is the "real" .NET language. The difference between Ironpython and Boo is that Ironpython is intended to be an implementation of the dynamic Python language in .NET, whilst Boo is a statically typed language with a python-like syntax intended to be a first class .NET language that uses the .NET class libraries instead of the Python ones. Being statically typed, it has all the performance of C#, but it lacks the dynamicity of Python (unless you explicity use "duck typing"). It can be viewed as a simplified, terser C# with a pythonic syntax. Also, I am not very fond of 'like' languages, i.e. a 'C' like language or a 'Java' like language, or in this case a 'Python' like language. Guido Van Rossum said that Boo is 95% Python, but statically typed, thus it feels completely different. It's trade-off. If you want it dynamic (Python or Ironpython) , you pay the price in terms of performance. If you want it fast (Boo), you have to adequate your coding style in a static way, and you also have to forget about the standard class libraries. You'll use .NET's instead. I like IronPython because it IS Python, not 'like' Python. Also, IronPython is well designed and it is fairly easy to follow and understand the code. Sure, Ironpython is just another implementation of Python, just like Jython. The runtime portion of IronPython just needs some work. Ironpython is still in beta. Now if you want to know how its development is going, I guess you'll have to wait until Pycon 2005 (see below): Keynote Speakers at PyCon 2005 Wednesday, March 23, 9:30 AM Jim Hugunin, Microsoft Corporation: "Python on the .NET Platform" Jim Hugunin is well-known in the Python world for his pioneering work on JPython (now Jython), and more recently for the IronPython .NET implementation of Python. Jim joined Microsoft's Common Language Runtime team in August last year to continue his work on IronPython and further improve the CLR's support for dynamic languages such as Python. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luismg at gmx.net Tue Feb 22 20:26:20 2005 From: luismg at gmx.net (Luis M. Gonzalez) Date: Tue, 22 Feb 2005 16:26:20 -0300 Subject: [IronPython] IronPython status Message-ID: <008d01c51914$6a11f810$1302a8c0@luis> >> Also, part of the Boo implementation is in c# and the other part is in Boo. >> I am really not fond of interpreters written in the interpretting language. I think the >> CPython / Jython / IronPython approach is MUCH better, faster, more stable >> and easier to follow. I guess you have some misconceptions about these languages: Boo is written in C# and soon it will be written in Boo itself (when .net 2.0 is stable). It is a first class .Net language and it has the same performance of C#, VB.NET or any other statically typed .NET language. Regarding Ironpython, it is also being written in C# (please correct me if I'm wrong). But this is not important at all, as long as the resulting code when using these languages is MSIL, which is the "real" .NET language. The difference between Ironpython and Boo is that Ironpython is intended to be an implementation of the dynamic Python language in .NET, whilst Boo is a statically typed language with a python-like syntax intended to be a first class .NET language that uses the .NET class libraries instead of the Python ones. Being statically typed, it has all the performance of C#, but it lacks the dynamicity of Python (unless you explicity use "duck typing"). It can be viewed as a simplified, terser C# with a pythonic syntax. >> Also, I am not very fond of 'like' languages, i.e. a 'C' like language or a >> 'Java' like language, or in this case a 'Python' like language. Guido Van Rossum said that Boo is 95% Python, but statically typed, thus it feels completely different. It's trade-off. If you want it dynamic (Python or Ironpython) , you pay the price in terms of performance. If you want it fast (Boo), you have to adequate your coding style in a static way, and you also have to forget about the standard class libraries. You'll use .NET's instead. In my oppinion, both (Ironpyhon and Boo) are excellent additions to my tools set. I'm using the Boo Add-in for SharpDevelop and I'm doing some GUI stuff in Windows Forms, and after a while, I'm very comfortable with it. >From a python programmer's perspective, it is very easy to grasp, especially for its fantastic type inference mechanism. However, I see it as a replacement of C#, not as a replacement of Python. It's a very good thing that now, python programmers have this new option. I can se myself in the future using Ironpyhon whenever possible, and resorting to Boo when I need full performance, since it takes just a couple of minutes to translate from one to the other. >> I like IronPython because it IS Python, not 'like' Python. Also, IronPython >> is well designed and it is fairly easy to follow and understand the code. Sure, Ironpython is just another implementation of Python, just like Jython. >> The runtime portion of IronPython just needs some work. Ironpython is still in beta. Now if you want to know how its development is going, I guess you'll have to wait until Pycon 2005 (see below): Keynote Speakers at PyCon 2005 Wednesday, March 23, 9:30 AM Jim Hugunin, Microsoft Corporation: "Python on the .NET Platform" Jim Hugunin is well-known in the Python world for his pioneering work on JPython (now Jython), and more recently for the IronPython .NET implementation of Python. Jim joined Microsoft's Common Language Runtime team in August last year to continue his work on IronPython and further improve the CLR's support for dynamic languages such as Python. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy_somogyi at hotmail.com Tue Feb 22 21:06:11 2005 From: andy_somogyi at hotmail.com (Andy Somogyi) Date: Tue, 22 Feb 2005 13:06:11 -0700 Subject: [IronPython] IronPython status In-Reply-To: <20050222190403.08F9B3B8038@smtp.zope.com> Message-ID: I think the first thing that would be very helpfull is a python conformance test suite. Basically a set of Python scripts that tests every portion of the language and can verify that IronPython is (not at the moment, but soon) 100% compatilble with the oficial Python interpreter. I have a public CVS repository set up with the initial import of the IronPython sources so we can track future changes. This is at my sourceforge project, so this includes bug and issue reporting and tracking. > > But really my point here is that sticking close to the > > original language is > > a good idea. The primary key to IronPython success exists in > > finishing what > > has been started... I fully agree, IronPython is off to a very good start, and appears to have a fairly decent following. Has anyone heard anything from Jim? I tried to contact him at microsoft (I have a great deal of intrest in the position he posted on his blog) and I have not heard anything back. Brian, IExpando is pretty well documented, at least in VS2003 it is. Basically, it is a replacement for IDispatch which is the core of VB, JScript (classic), and any previous MS scripting technology. I have tons of experience with IDispatch (a while back, I even wrote a complete Scheme interpreter where all objects were based on IDispatch). Basically, IExpando is an interface where you can add properties and methods to an object. Most .net objects do not implement IExpando, they all however implement IReflect (via the Type object). IReflect allows you to call and invoke properties and methods whereas IExpando allows you to add properties and methods. The only object that I am aware of that implement IExpando are the objects returned from and used inside JScript and VBScript .net. Also, whenever you import a classic COM object, it will show up as an IExpando object. > > The beauty of Python is its built-in constructs and types. > > To be able to > > use lists, tuples and dictionaries... to be able to iterate over them > > without having to know ahead of time the object type... and > > then to wield > > that power against a nice set of libraries in .NET > > (especially for the UI) > > is a powerful combination. > > > >Agreed - it would be helpful, I think, for those who are >interested to come up with a prioritized list of what needs >to be done to 'finish'. There appears to be some desire and >momentum from people willing to contribute, so we should >take advantage of that and reconcile things when Jim re-surfaces ;) > > >Brian Lloyd brian at zope.com >V.P. Engineering 540.361.1716 >Zope Corporation http://www.zope.com > > From bob at redivi.com Wed Feb 23 00:03:50 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 22 Feb 2005 18:03:50 -0500 Subject: [IronPython] IronPython status In-Reply-To: References: Message-ID: <8f77a680d0bbe6ce810a427a48a9084b@redivi.com> On Feb 22, 2005, at 13:22, Andy Somogyi wrote: > Also, part of the Boo implementation is in c# and the other part is in > Boo. I am really > not fond of interpreters written in the interpretting language. I > think the > CPython / Jython / IronPython approach is MUCH better, faster, more > stable > and easier to follow. Quite a few very smart people would disagree with you on this point! -bob From andy_somogyi at hotmail.com Wed Feb 23 01:13:49 2005 From: andy_somogyi at hotmail.com (Andy Somogyi) Date: Tue, 22 Feb 2005 17:13:49 -0700 Subject: [IronPython] IronPython status Message-ID: > >>Also, part of the Boo implementation is in c# and the other part is in >>Boo. I am really not fond of interpreters written in the interpretting >>language. I think the CPython / Jython / IronPython approach is MUCH >>better, faster, more stable and easier to follow. > >Quite a few very smart people would disagree with you on this point! > >-bob Thats OK, this is America and we are allowed to do that :) In the case of Boo, IMO, it might not be that bad of an idea as Boo is essentially a statically typed python, so it can be compiled to standard IL instructions just like any other statically typed .net language. In other words it does NOT require an interpreter or run time libraries (other than the standard .net lib). A dynamically typed language such as Python can not be *FULLY* compiled to IL. This is because Python is a dynamic language, the exact operations performed on variables will depend on thier type, and this is not known untill runtime. IronPython does compile all stack operations expressions to IL, but the IL code assigments, calls, etc... ends up calling the various library support functions. It is the library functions where all assigments, calls, etc.. end up being made as this is where the logic to determine what operation to perform based on variable types is done. So, you still end up requiring a farily extensive support library. IronPython (and Jython) blur the line between an interpreted and a compiled language. If the library functions were themselves written in Python, we would have the chicken and egg issue, how do you bootstrap it? You end up needing another interpreter / runtime to support the interpreter / runtime you are writting. While I'm sure there are several advantages to this approach, and I'm sure there are many supporters of this approach, personally, I like the approach CPython / Jython / IronPython took, and that is why I have decided to put my efforts behind IronPython. As for my earlier statment, I will retract the word 'better' as this is a very subjective term. I'm sure there is some situation where a interpreter for a language written in the same interpreted languge can be judged 'better' by some set of metrics. From bob at redivi.com Wed Feb 23 01:50:07 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 22 Feb 2005 19:50:07 -0500 Subject: [IronPython] IronPython status In-Reply-To: References: Message-ID: <1cf04f2042103b682b6b4131d4708347@redivi.com> On Feb 22, 2005, at 19:13, Andy Somogyi wrote: >> >>> Also, part of the Boo implementation is in c# and the other part is >>> in Boo. I am really not fond of interpreters written in the >>> interpretting language. I think the CPython / Jython / IronPython >>> approach is MUCH better, faster, more stable and easier to follow. >> >> Quite a few very smart people would disagree with you on this point! > > Thats OK, this is America and we are allowed to do that :) Although you and I are probably both in America, the whole internet isn't :) > In the case of Boo, IMO, it might not be that bad of an idea as Boo > is essentially a statically typed python, so it can be compiled to > standard IL instructions > just like any other statically typed .net language. In other words it > does > NOT require an interpreter or run time libraries (other than the > standard .net lib). > > A dynamically typed language such as Python can not be *FULLY* > compiled to > IL. This is because Python is a dynamic language, the exact operations > performed > on variables will depend on thier type, and this is not known untill > runtime. Well the meaning of "fully" compiled is pretty ambiguous. You can do it naively, and it would generate a bunch of code and be slow, but you can do it. > IronPython does compile all stack operations expressions to IL, but > the IL code assigments, calls, etc... ends up calling the various > library support > functions. It is the library functions where all assigments, calls, > etc.. end > up being made as this is where the logic to determine what operation to > perform based on variable types is done. > > So, you still end up requiring a farily extensive support library. > IronPython (and Jython) > blur the line between an interpreted and a compiled language. The line isn't very blurry, they're both completely interpreted languages. IronPython is 100% IL bytecode and it generates nothing but IL bytecode, which gets interpreted/translated by virtual machine. Same for Jython, with some different acronyms. > If the library functions were themselves written in Python, we would > have > the chicken and egg issue, how do you bootstrap it? You end up needing > another interpreter / runtime to support the interpreter / runtime you > are > writting. The bootstrapping problem is solved because there is a Python implementation already available (several, actually). The approach that PyPy is taking is to implement Python in a subset of Python that *can* be directly translated to a static form (but is also valid Python code that can be tested/verified with a traditional CPython interpreter). In order to make sure they're doing it right, they have several backends in development (LLVM, Pyrex, C, etc.). > While I'm sure there are several advantages to this approach, and I'm > sure > there are many supporters of this approach, personally, I like the > approach > CPython / Jython / IronPython took, and that is why I have decided to > put my efforts behind IronPython. And this approach is why there are three very distinct implementations. If the majority of Python were written in Python, then Jython and IronPython would be Python 2.4 compatible, each with the same complete standard library (plus implementation specific support, of course). > As for my earlier statment, I will retract the word 'better' as this > is a very > subjective term. I'm sure there is some situation where a interpreter > for > a language written in the same interpreted languge can be judged > 'better' > by some set of metrics. Well there is plenty of prior art (C, C#, LISP, Scheme, Smalltalk, etc.) that shows exactly how this is possible and reasonable, and how it can be faster, easier to understand, and more portable than the approach of writing a large part of the interpreter directly in some host language. Also consider that the less code you write in C#, the more useful it is to projects other than IronPython. -bob From ianm at ActiveState.com Wed Feb 23 05:51:25 2005 From: ianm at ActiveState.com (Ian MacLean) Date: Wed, 23 Feb 2005 13:51:25 +0900 Subject: [IronPython] IronPython status In-Reply-To: <1cf04f2042103b682b6b4131d4708347@redivi.com> References: <1cf04f2042103b682b6b4131d4708347@redivi.com> Message-ID: <421C0BCD.2090407@activestate.com> Bob Ippolito wrote: >> >> >> So, you still end up requiring a farily extensive support library. >> IronPython (and Jython) >> blur the line between an interpreted and a compiled language. > > > The line isn't very blurry, they're both completely interpreted > languages. IronPython is 100% IL bytecode and it generates nothing > but IL bytecode, which gets interpreted/translated by virtual > machine. Same for Jython, with some different acronyms. > > By that logic boo, c# and vb.net are also "completely interpreted" since they generate nothing but IL bytecode. Ian From py at ls-l.org Wed Feb 23 12:52:00 2005 From: py at ls-l.org (Chema Cortes) Date: Wed, 23 Feb 2005 12:52:00 +0100 Subject: [IronPython] IronPython status In-Reply-To: <008d01c51914$6a11f810$1302a8c0@luis> References: <008d01c51914$6a11f810$1302a8c0@luis> Message-ID: <421C6E60.7060202@ls-l.org> Luis M. Gonzalez wrote: > In my oppinion, both (Ironpyhon and Boo) are excellent additions to my > tools set. > I'm using the Boo Add-in for SharpDevelop and I'm doing some GUI stuff > in Windows Forms, and after a while, I'm very comfortable with it. > From a python programmer's perspective, it is very easy to grasp, > especially for its fantastic type inference mechanism. > However, I see it as a replacement of C#, not as a replacement of Python. I think so. Boo can be to IronPython like pyrex is to python, an easy way to write extensions for a python programmer. And viceversa, IronPython can be an excelent scripting language for Boo. From randall_burns at yahoo.com Wed Feb 23 22:17:17 2005 From: randall_burns at yahoo.com (Randall Burns) Date: Wed, 23 Feb 2005 13:17:17 -0800 (PST) Subject: [IronPython] Re: users-ironpython.com Digest, Vol 7, Issue 5 In-Reply-To: <20050223200821.56FF5985B9@che.dreamhost.com> Message-ID: <20050223211717.147.qmail@web14323.mail.yahoo.com> This would be _really_ nice if it could be made _very_ seemless. -From: Chema Cortes >Luis M. Gonzalez wrote: >> In my oppinion, both (Ironpyhon and Boo) are >> excellent additions to my ......... >>However, I see it as a replacement of C#, not as a >>replacement of >>Python. >I think so. Boo can be to IronPython like pyrex is to >python, an easy way to write extensions for a python >programmer. And viceversa, >IronPython can be an excelent scripting language for > Boo. __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From ken.manheimer at gmail.com Wed Feb 23 22:55:04 2005 From: ken.manheimer at gmail.com (Ken Manheimer) Date: Wed, 23 Feb 2005 16:55:04 -0500 Subject: [IronPython] Re: users-ironpython.com Digest, Vol 7, Issue 5 In-Reply-To: <20050223211717.147.qmail@web14323.mail.yahoo.com> References: <20050223200821.56FF5985B9@che.dreamhost.com> <20050223211717.147.qmail@web14323.mail.yahoo.com> Message-ID: <2cd46e7f05022313552ad571a3@mail.gmail.com> On Wed, 23 Feb 2005 13:17:17 -0800 (PST), Randall Burns wrote: > This would be _really_ nice if it could be made _very_ > seemless. >[...] > >Luis M. Gonzalez wrote: > >I think so. Boo can be to IronPython like pyrex is to > >python, an easy way to write extensions for a python > >programmer. And viceversa, > >IronPython can be an excelent scripting language for > > Boo. I dunno if that's so attractive. The more "seamless", the more problematic and unexpected the surprises the programmer will experience from the subtle disparities between the two languages. Personally, i have enough trouble keeping things straight when i have to switch between javascript, C, and python ("is '&&' now the logical or bitwise 'and'?"), i shudder to imagine navigating the confusion when the differences are so subtle. At least java and jython look different enough that it's obvious which one you're reading... But this is all ever so hypothetical, i shouldn't complain yet!-) -- Ken Manheimer ken.manheimer at gmail.com From luismg at gmx.net Thu Feb 24 05:37:11 2005 From: luismg at gmx.net (Luis M. Gonzalez) Date: Thu, 24 Feb 2005 01:37:11 -0300 Subject: [IronPython] Re: users-ironpython.com Digest, Vol 7, Issue 5 Message-ID: <000601c51a2a$833f27b0$1302a8c0@luis> >> I dunno if that's so attractive. The more "seamless", the more >> problematic and unexpected the surprises the programmer will >> experience from the subtle disparities between the two languages. >> >> Personally, i have enough trouble keeping things straight when i have >> to switch between javascript, C, and python ("is '&&' now the logical >> or bitwise 'and'?"), i shudder to imagine navigating the confusion >> when the differences are so subtle. At least java and jython look >> different enough that it's obvious which one you're reading... >> >> But this is all ever so hypothetical, i shouldn't complain yet!-) I understand your concern. I used to think that way before trying out Boo, but really, it's not that complicated. There's no significant difference in their syntax, which is almost identical. The difference is in the fact that Boo is statically typed, while Python is dynamic. That means that in some cases you have to declare types (not very offen, because most of the time the types are authomatically inferred). For example, you can type: a = 5 ---> ( you don't need to declare its type here, because it is inferred as "int" ) a = 'hello' ( you can't do that, because "a" has been previously inferred as "int") On the other hand, you can do that in Python (or Ironpython) because it is dynamic, not static. The other significant difference is that although it is static, its type inference mechanism works most of the times, so you don't need to declare types. For example, in C# you would have to type inplicity each variable's type: int a = 5; or string a = "hello"; -------------- next part -------------- An HTML attachment was scrubbed... URL: From KarmaSlave at MyRealBox.com Thu Feb 24 17:16:44 2005 From: KarmaSlave at MyRealBox.com (Burning) Date: Thu, 24 Feb 2005 11:16:44 -0500 Subject: Differences between Boo and Python (WAS: Re: [IronPython] Re: users-ironpython.com Digest, Vol 7, Issue 5) In-Reply-To: <000601c51a2a$833f27b0$1302a8c0@luis> References: <000601c51a2a$833f27b0$1302a8c0@luis> Message-ID: <421DFDEC.8090908@MyRealBox.com> Luis M. Gonzalez wrote: > > a = 5 ---> ( you don't need to declare its type here, because it is > inferred as "int" ) > a = 'hello' ( you can't do that, because "a" has been previously > inferred as "int") Actually, you can do this to mimick Python: (careful, your newsreader might think these are quotes instead of prompts from the Boo Interpreter.) >>> a as duck >>> a = 5 5 >>> a = 'hello' 'hello' >>> a = [] [] >>> a = (1, 2, 3) (1, 2, 3) >>> a = {"ham":"sandwich"} {'ham': 'sandwich'} >>> From luismg at gmx.net Sun Feb 27 07:00:12 2005 From: luismg at gmx.net (Luis M. Gonzalez) Date: Sun, 27 Feb 2005 03:00:12 -0300 Subject: [IronPython] Re: users-ironpython.com Digest, Vol 7, Issue 5 Message-ID: <000601c51c91$9ba51490$1302a8c0@luis> >> This would be _really_ nice if it could be made _very_seemless. I don't see why not. Both run on the same framework and generate the same intermediate language. I already use C# assemblies from within Boo projects and it works seamlessly. It would be way easier than mixing python/pyrex. Most of the times it would just require a simple "copy and paste" operation from python (or ironpython) an a couple of tweaks in the code. To have an idea of how similar Boo is to python, you can read this: http://boo.codehaus.org/Gotchas+for+Python+Users -------------- next part -------------- An HTML attachment was scrubbed... URL: