From kfarmer at thuban.org Sun May 1 11:00:07 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Sun, 1 May 2005 02:00:07 -0700 Subject: [IronPython] Executing a python source from C# Message-ID: In fact... http://blogs.msdn.com/johngossman/archive/2005/04/30/413735.aspx http://blogs.msdn.com/johngossman/archive/2005/04/30/413743.aspx ________________________________ 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 11:27 AM 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amigrave at gmail.com Sun May 1 23:20:28 2005 From: amigrave at gmail.com (Fabien Meghazi) Date: Sun, 1 May 2005 23:20:28 +0200 Subject: [IronPython] Executing a python source from C# In-Reply-To: <6C91A34F0BB48B40A86F1E146B7A049201BF2ACC@df-fido-msg.exchange.corp.microsoft.com> References: <6C91A34F0BB48B40A86F1E146B7A049201BF2ACC@df-fido-msg.exchange.corp.microsoft.com> Message-ID: <7772a259050501142059974134@mail.gmail.com> > 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 Thanks a lot for your answer. Anyway I'm afraid that I won't be able to do what I want as the company where I'm working in won't install the framework 2.0 on the web servers before 2059 I guess. As PythonEngine does not exists in IronPython 0.6 (correct me if I'm wrong) I won't be able to use IronPython. Sorry not to have told you before that I was not using the last version of IronPython. From mailinglist.account at gmail.com Tue May 3 15:33:52 2005 From: mailinglist.account at gmail.com (Anthony Tarlano) Date: Tue, 3 May 2005 15:33:52 +0200 Subject: [IronPython] Developing a System.Web.Service.WebService Message-ID: Hi all, I was wondering if anyone has successfully created a WebService in IronPython and deployed it using ASP.NET? If not I will make it a point to post my results after accomplishing the task.. ;-) One piece of information I need in order to begin is how I set the namespace for a package? I.e. in C# you can say namespace NicelyNamedSpace {... }, how do you do this with IronPython? Regards, Anthony From martmaly at exchange.microsoft.com Tue May 3 19:36:50 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Tue, 3 May 2005 10:36:50 -0700 Subject: [IronPython] IronPython 0.7.4 released Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701CD0EE0@df-chewy-msg.exchange.corp.microsoft.com> Hello IronPython community, We have just released IronPython 0.7.4. There were few feature requests and bug fixes that the community felt strongly about so we decided to release the 0.7.4 faster than usual. We hope that you will find the update useful even though we may have not delivered on all our promises for 0.7.4. We decided that getting release with high priority requests to you would be the right thing to do (and we are still keeping our promises in mind for the upcoming release). The important changes for the 0.7.4 release are: * reload() is now implemented * site.py, IRONPYTHONPATH and IRONPYTHONSTARTUP environment variables (see below for more details) * implementation of sys.stdin * raw_input and input functions were implemented * Assignment to a slice not implemented (on list) * implementation of built-in function reversed() * float numbers now print correctly with decimal point * missing attribute access on old-style generates correct error The members of our community who provided important feedback, reported bugs that we fixed for this release, or otherwise contributed to the 0.7.4 release are listed below. Thank you for your work, contribution and feedback: Nicholas Jacobson Keith J. Farmer Michael Spencer Anthony Tarlano Flexibal mrwizard82d1 luismg More information on site.py: As we discussed on an email alias, standard CPython implementation has several ways to support configuration on startup: "import site.py", PYTHONPATH, PYTHONSTARTUP. We implemented all three for the 0.7.4 release. The "site.py" file that is included with the distribution is empty, but we tested not only with our empty one, but also with the site.py that is part of CPython 2.3.5 distribution. The 2.3.5 version of site.py works with IronPython. However, IronPython does not process site.py successfully in the 2.4 environment because of the use of multi-line import statement in the import fan-out of the 'site.py' file (in os.py) For the environment variables, we chose names IRONPYTHONPATH and IRONPYTHONSTARTUP. One trick that we use at Microsoft a lot when it comes to environment variables is that we do not put the environment variables into the global (per-machine or per-user) settings. Instead we use simple scripts to configure environment of the command line for the task at hand. Sdkvars.bat from the .NET SDK is an example. Progress on regression testing: We are also making progress on running the standard CPython regression tests. As of this very moment we pass test_math.py and random.py self-test, we can also import string.py and site.py (which imports variety of other modules). Because of the 2.4 features that we have not yet implemented in IronPython we are using the regression test suite from CPython 2.3.5 distribution. The next test to try and pass is test_builtin.py that Michael Spencer got running for us on IronPython. We hope that you will find this release useful. 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=BF172CE4-E185-4 9AE-BC7E-CB283741522D&displaylang=en From kfarmer at thuban.org Tue May 3 20:05:28 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 3 May 2005 11:05:28 -0700 Subject: [IronPython] IronPython 0.7.4 released Message-ID: .. So how would I do such configuration for non-command-line programs? Do I need to always front the executable with a bat file? Such a requirement presents a big wart for those not living in the command line, and I don't see any good reason to let it remain. I think this is a point where Python should hybridize to live well among its new neighbors. May I request .config file support for a future release? Heck, I'd be happy to hack it in myself. Good news on the testing progress! ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Martin Maly Sent: Tue 5/3/2005 10:36 AM * site.py, IRONPYTHONPATH and IRONPYTHONSTARTUP environment variables (see below for more details) [...] variables into the global (per-machine or per-user) settings. Instead we use simple scripts to configure environment of the command line for the task at hand. Sdkvars.bat from the .NET SDK is an example. -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 4247 bytes Desc: not available URL: From mahs at telcopartners.com Tue May 3 21:21:54 2005 From: mahs at telcopartners.com (Michael Spencer) Date: Tue, 03 May 2005 12:21:54 -0700 Subject: [IronPython] Re: IronPython 0.7.4 released In-Reply-To: <1E1FC9DA1767ED44872F4E17AC17E8F701CD0EE0@df-chewy-msg.exchange.corp.microsoft.com> References: <1E1FC9DA1767ED44872F4E17AC17E8F701CD0EE0@df-chewy-msg.exchange.corp.microsoft.com> Message-ID: Martin Maly wrote: > Hello IronPython community, > > We have just released IronPython 0.7.4. There were few feature requests > and bug fixes that the community felt strongly about so we decided to > release the 0.7.4 faster than usual. Thanks I note sys.platform has also changed to '.NET', from 'java-clr'. Michael From martmaly at exchange.microsoft.com Tue May 3 21:28:39 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Tue, 3 May 2005 12:28:39 -0700 Subject: [IronPython] Re: IronPython 0.7.4 released Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701CD0F9C@df-chewy-msg.exchange.corp.microsoft.com> Yes, it was part of getting the standard CPython's site.py to import correctly by IronPython. The standard site.py would assume that it is dealing with Jython if it detects 'java' as the prefix of the sys.platform string. Martin > Michael Spencer Wrote: > > Thanks > > I note sys.platform has also changed to '.NET', from 'java-clr'. > > Michael From dstcruz at gmail.com Tue May 3 21:37:38 2005 From: dstcruz at gmail.com (Daniel Santa Cruz) Date: Tue, 3 May 2005 15:37:38 -0400 Subject: [IronPython] Re: IronPython 0.7.4 released In-Reply-To: <1E1FC9DA1767ED44872F4E17AC17E8F701CD0F9C@df-chewy-msg.exchange.corp.microsoft.com> References: <1E1FC9DA1767ED44872F4E17AC17E8F701CD0F9C@df-chewy-msg.exchange.corp.microsoft.com> Message-ID: <4fcfd94a050503123766288bd5@mail.gmail.com> How can I determine which standard functions are currently implemented by IronPython? Would: >>> import sys >>> dir() show me what we have? Thanks! Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From martmaly at exchange.microsoft.com Tue May 3 22:14:42 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Tue, 3 May 2005 13:14:42 -0700 Subject: [IronPython] Re: IronPython 0.7.4 released Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701CD0FEF@df-chewy-msg.exchange.corp.microsoft.com> Hi Daniel, For the sys module, you can do: import sys dir(sys) and get the result that way. Similarly for __builtin__. For sys and __builtin__ what you see in dir is what is implemented (or else it is a bug). However, there are modules - for example recently added 'binascii' - in which we only have empty stubs for the functions so even though dir(binascii) returns the full set of functions, none of them are implemented yet. Martin > Daniel Santa Cruz Wrote: > How can I determine which standard functions are currently implemented by IronPython? > > Would: > >>> import sys > >>> dir() > > show me what we have? > > Thanks! > Daniel From mahs at telcopartners.com Tue May 3 22:19:30 2005 From: mahs at telcopartners.com (Michael Spencer) Date: Tue, 03 May 2005 13:19:30 -0700 Subject: [IronPython] Re: IronPython 0.7.4 released In-Reply-To: <1E1FC9DA1767ED44872F4E17AC17E8F701CD0F9C@df-chewy-msg.exchange.corp.microsoft.com> References: <1E1FC9DA1767ED44872F4E17AC17E8F701CD0F9C@df-chewy-msg.exchange.corp.microsoft.com> Message-ID: Martin Maly wrote: > Yes, it was part of getting the standard CPython's site.py to import > correctly by IronPython. The standard site.py would assume that it is > dealing with Jython if it detects 'java' as the prefix of the > sys.platform string. yep - but this cuts both ways ;-) sys.platform[:4] == 'java' actually helped unittest to run because it avoids looking for a cpython-specific traceback attribute. Anyway, it's better to have a distinct platform id and the required modification to unittest is trivial. Michael From mahs at telcopartners.com Tue May 3 22:22:41 2005 From: mahs at telcopartners.com (Michael Spencer) Date: Tue, 03 May 2005 13:22:41 -0700 Subject: [IronPython] Re: IronPython 0.7.4 released In-Reply-To: <4fcfd94a050503123766288bd5@mail.gmail.com> References: <1E1FC9DA1767ED44872F4E17AC17E8F701CD0F9C@df-chewy-msg.exchange.corp.microsoft.com> <4fcfd94a050503123766288bd5@mail.gmail.com> Message-ID: Daniel Santa Cruz wrote: > How can I determine which standard functions are currently implemented by > IronPython? > > Would: > >>>>import sys >>>>dir() > > > show me what we have? > > Thanks! > Daniel That will show the current namespace. Perhaps more useful to you is: >>> import __builtin__ >>> dir(__builtin__) ['ArithmeticError', 'AssertionError', 'AttributeError', 'DeprecationWarning', 'E OFError', 'Ellipsis', 'EnvironmentError', 'Equals', 'Exception', 'False', 'Float ingPointError', 'FutureWarning', 'GetHashCode', 'GetType', 'IOError', 'ImportErr or', 'IndentationError', 'IndexError', 'KeyError', 'KeyboardInterrupt', 'LookupE rror', 'MakeNew', 'MemoryError', 'NameError', 'None', 'NotImplemented', 'NotImpl ementedError', 'OSError', 'OverflowError', 'OverflowWarning', 'PendingDeprecatio nWarning', 'ReferenceError', 'RuntimeError', 'RuntimeWarning', 'StandardError', 'StopIteration', 'SyntaxError', 'SyntaxWarning', 'SystemError', 'SystemExit', 'T abError', 'ToString', 'True', 'TypeError', 'UnboundLocalError', 'UnicodeDecodeEr ror', 'UnicodeEncodeError', 'UnicodeError', 'UnicodeTranslateError', 'UserWarnin g', 'ValueError', 'Warning', 'WindowsError', 'ZeroDivisionError', '__debug__', ' __import__', '__new__', 'abs', 'apply', 'basestring', 'bool', 'buffer', 'callabl e', 'chr', 'classmethod', 'cmp', 'compile', 'complex', 'delattr', 'dict', 'dir', 'divmod', 'enumerate', 'eval', 'execfile', 'exit', 'file', 'filter', 'float', ' getattr', 'globals', 'hasattr', 'hash', 'help', 'hex', 'id', 'input', 'int', 'in tern', 'isinstance', 'issubclass', 'iter', 'len', 'list', 'long', 'map', 'max', 'min', 'nstr', 'object', 'oct', 'open', 'ord', 'pow', 'property', 'quit', 'range ', 'raw_input', 'reduce', 'reload', 'repr', 'reversed', 'round', 'setattr', 'sli ce', 'staticmethod', 'str', 'sum', 'super', 'tuple', 'type', 'unichr', 'unicode' , 'xrange', 'zip', 'zip2'] >>> Note, that not all the built-in functions behave identically to cpython's yet Michael From kirko at microsoft.com Wed May 4 00:01:52 2005 From: kirko at microsoft.com (Kirk Olynyk) Date: Tue, 3 May 2005 15:01:52 -0700 Subject: [IronPython] Accessing Microsoft.Win32 Message-ID: <310187D53C02434D8F2CF4CD951B734102BF9A69@RED-MSG-60.redmond.corp.microsoft.com> I have tried everything that I can think of to access the Microsoft.Win32 assembly, but I can't seem to get it. What is the canonical way of accomplishing this? Kirk -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarmer at thuban.org Wed May 4 00:02:29 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 3 May 2005 15:02:29 -0700 Subject: [IronPython] Accessing Microsoft.Win32 Message-ID: Have you tried: from Microsoft.Win32 import * dir() ...? ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Kirk Olynyk Sent: Tue 5/3/2005 3:01 PM I have tried everything that I can think of to access the Microsoft.Win32 assembly, but I can't seem to get it. What is the canonical way of accomplishing this? -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3855 bytes Desc: not available URL: From nicksjacobson at hotmail.com Wed May 4 03:17:26 2005 From: nicksjacobson at hotmail.com (Nick Jacobson) Date: Wed, 04 May 2005 01:17:26 +0000 Subject: [IronPython] Re: IronPython 0.7.4 released Message-ID: Michael Spencer wrote: << >>>import __builtin__ >>> dir(__builtin__) ['ArithmeticError', 'AssertionError', 'AttributeError', 'DeprecationWarning', 'E OFError', 'Ellipsis', 'EnvironmentError', 'Equals', 'Exception', 'False', 'Float ingPointError', 'FutureWarning', 'GetHashCode', 'GetType', 'IOError', 'ImportErr or', 'IndentationError', 'IndexError', 'KeyError', 'KeyboardInterrupt', 'LookupE rror', 'MakeNew', 'MemoryError', 'NameError', 'None', 'NotImplemented', 'NotImpl ementedError', 'OSError', 'OverflowError', 'OverflowWarning', 'PendingDeprecatio nWarning', 'ReferenceError', 'RuntimeError', 'RuntimeWarning', 'StandardError', 'StopIteration', 'SyntaxError', 'SyntaxWarning', 'SystemError', 'SystemExit', 'T abError', 'ToString', 'True', 'TypeError', 'UnboundLocalError', 'UnicodeDecodeEr ror', 'UnicodeEncodeError', 'UnicodeError', 'UnicodeTranslateError', 'UserWarnin g', 'ValueError', 'Warning', 'WindowsError', 'ZeroDivisionError', '__debug__', ' __import__', '__new__', 'abs', 'apply', 'basestring', 'bool', 'buffer', 'callabl e', 'chr', 'classmethod', 'cmp', 'compile', 'complex', 'delattr', 'dict', 'dir', 'divmod', 'enumerate', 'eval', 'execfile', 'exit', 'file', 'filter', 'float', ' getattr', 'globals', 'hasattr', 'hash', 'help', 'hex', 'id', 'input', 'int', 'in tern', 'isinstance', 'issubclass', 'iter', 'len', 'list', 'long', 'map', 'max', 'min', 'nstr', 'object', 'oct', 'open', 'ord', 'pow', 'property', 'quit', 'range ', 'raw_input', 'reduce', 'reload', 'repr', 'reversed', 'round', 'setattr', 'sli ce', 'staticmethod', 'str', 'sum', 'super', 'tuple', 'type', 'unichr', 'unicode' , 'xrange', 'zip', 'zip2'] >> What are nstr and zip2? --Nick _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From jimhug at exchange.microsoft.com Wed May 4 05:13:05 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Tue, 3 May 2005 20:13:05 -0700 Subject: [IronPython] Re: IronPython 0.7.4 released Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201BF34A4@df-fido-msg.exchange.corp.microsoft.com> Nick Jacobson wrote: > What are nstr and zip2? Two little hacks that I wrote a long time ago while playing around with different implementation and performance ideas. They don't belong in __builtins__ any more and will be removed. In case you're curious: nstr is an ascii string type that I was experimenting with to see how well two different kinds of strings would work in IronPython vs. everything being a Unicode System.String. This design didn't work very well, but I forgot to remove this reference from __builtins__. There's still a chance that this will be revisited before IronPython 1.0; however, I'm pretty committed to using the single CLS string type if at all possible. zip2 is a version of the zip function specialized for the most common case of two arguments. It should be a private implementation detail. I exposed it when looking at benchmarks to see if there were any noticeable performance benefits to get from calling it directly. Time to do some more house cleaning - Jim From jimhug at exchange.microsoft.com Wed May 4 05:23:09 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Tue, 3 May 2005 20:23:09 -0700 Subject: [IronPython] Developing a System.Web.Service.WebService Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201BF34A6@df-fido-msg.exchange.corp.microsoft.com> Anthony Tarlano wrote: > I was wondering if anyone has successfully created a WebService in > IronPython and deployed it using ASP.NET? > > If not I will make it a point to post my results after accomplishing > the task.. ;-) I haven't done it, but I'd love to see your results. I think that you're going to need to think out of the box to get this to work well. > One piece of information I need in order to begin is how I set the > namespace for a package? I.e. in C# you can say namespace > NicelyNamedSpace {... }, how do you do this with IronPython? You can't really do this in IronPython without a static compiler. We're planning to provide a static compiler sometime in the future, but it's not available today. I'm also afraid that you're going to run into trouble with the custom attributes that are used a lot for web services. We plan to support these with Python 2.4 decorator syntax, but that's not implemented yet either. Wish I could be more helpful - Jim From kfarmer at thuban.org Wed May 4 08:45:14 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 3 May 2005 23:45:14 -0700 Subject: [IronPython] Temp directory for IronPython? Message-ID: I'm noticing as I use IronPython that my disk is getting littered with site.* and snippets.* files. I realize this allows for different sets of snippets, but could a more centralized cache be used? IronPython/Cache// .. or the like ..... Gave up on trying to use the global environment variable settings to manage my PATH variable, and have migrated toward user-level. Disappointing story there, but something more directly addressable by the OS development teams. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimhug at exchange.microsoft.com Wed May 4 08:56:34 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Tue, 3 May 2005 23:56:34 -0700 Subject: [IronPython] Temp directory for IronPython? Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201BF34C0@df-fido-msg.exchange.corp.microsoft.com> It's just a bug that these go in the current directory. The site.dll file should be placed in the same directory as site.py as it is the logical equivalent of site.pyc. I don't know how hard this will be to implement. The snippets.dll file has no reason to be written to disk. This is only done for purposes of debugging the IronPython code generator. We should just not generate this file unless started in a debugInternals kind of mode. We'll look into both of these for the next release if they're easy and a little further in the future if they turn out to be hard. 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: Tuesday, May 03, 2005 11:45 PM To: Discussion of IronPython Subject: [IronPython] Temp directory for IronPython? I'm noticing as I use IronPython that my disk is getting littered with site.* and snippets.* files.? I realize this allows for different sets of snippets, but could a more centralized cache be used? IronPython/Cache// .. or the like ..... Gave up on trying to use the global environment variable settings to manage my PATH variable, and have migrated toward user-level.? Disappointing story there, but something more directly addressable by the OS development teams. From mailinglist.account at gmail.com Wed May 4 12:54:05 2005 From: mailinglist.account at gmail.com (Anthony Tarlano) Date: Wed, 4 May 2005 12:54:05 +0200 Subject: [IronPython] Re: IronPython 0.7.4 released In-Reply-To: <6C91A34F0BB48B40A86F1E146B7A049201BF34A4@df-fido-msg.exchange.corp.microsoft.com> References: <6C91A34F0BB48B40A86F1E146B7A049201BF34A4@df-fido-msg.exchange.corp.microsoft.com> Message-ID: Great job geeting 0.7.4 out the door!! Thanks for the heads up that it's possible to just grab the Lib directory from Python-2.3.5 and replace the IPython/bin/Lib directory to get the ball rolling... One big question comes to mind now that I have all those nice stdlib .py files.. Do you intend to adapt the python stdlib to work seamlessly in IronPython 1.0? If you don't think this is the plan then I will start a project to get this work done.. Please let me know as to not re-invent the wheel. Anthony On 5/4/05, Jim Hugunin wrote: > Nick Jacobson wrote: > > What are nstr and zip2? > > Two little hacks that I wrote a long time ago while playing around with > different implementation and performance ideas. They don't belong in > __builtins__ any more and will be removed. In case you're curious: > > nstr is an ascii string type that I was experimenting with to see how > well two different kinds of strings would work in IronPython vs. > everything being a Unicode System.String. This design didn't work very > well, but I forgot to remove this reference from __builtins__. There's > still a chance that this will be revisited before IronPython 1.0; > however, I'm pretty committed to using the single CLS string type if at > all possible. > > zip2 is a version of the zip function specialized for the most common > case of two arguments. It should be a private implementation detail. I > exposed it when looking at benchmarks to see if there were any > noticeable performance benefits to get from calling it directly. > > Time to do some more house cleaning - Jim > _______________________________________________ > 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 May 4 15:29:23 2005 From: mailinglist.account at gmail.com (Anthony Tarlano) Date: Wed, 4 May 2005 15:29:23 +0200 Subject: [IronPython] 0.7.4 doesn't allow more than one IronPythonConsole... Message-ID: I filed a bugas usual, but maybe you should consider a 0.7.4.1 release fixing this and the *[exe,pdb] file pollution problem asap Keep up the good work! Anthony -------------- next part -------------- An HTML attachment was scrubbed... URL: From firemoth at gmail.com Wed May 4 17:19:24 2005 From: firemoth at gmail.com (Timothy Fitz) Date: Wed, 4 May 2005 11:19:24 -0400 Subject: [IronPython] 0.7.4 doesn't allow more than one IronPythonConsole... In-Reply-To: References: Message-ID: <972ec5bd050504081963e01239@mail.gmail.com> On 5/4/05, Anthony Tarlano wrote: > I filed a bug as usual, but maybe you should consider a 0.7.4.1 release > fixing this and the *[exe,pdb] file pollution problem asap Is the exe "file pollution problem" really a problem? Conceptually, CPython and IronPython are doing the same thing here. Step 1 is compile to bytecode, CPython generates .pyc files, IronPython generates exe files (that are CLR code). Step 2 is run with a virtual machine. On a windows machine, python associates with .pyc and .py files, so both the pyc and exe files are "runnable", they both have the problem that an unsuspecting person might unintentionally run them, however exe files are more tempting to the average user. I think functionally that narrows the difference between CPython and Ironpython down to file extension names and their associated icons, no? Are there any plans to change this? If so to what? My initial thought was generate dlls, but that loses the double-click to run functionality. From mailinglist.account at gmail.com Wed May 4 18:27:09 2005 From: mailinglist.account at gmail.com (Anthony Tarlano) Date: Wed, 4 May 2005 18:27:09 +0200 Subject: [IronPython] 0.7.4 doesn't allow more than one IronPythonConsole... In-Reply-To: <972ec5bd050504081963e01239@mail.gmail.com> References: <972ec5bd050504081963e01239@mail.gmail.com> Message-ID: Timothy, Yes the pollution is really a problem. You see in CPython the .pyc files are at least contained to the package directory where the modules live, thus they follow the pigeon-hole principle (one-to-one). The current release puts at the very least 6 files ( site.{exe, pdb}, snippets.{exe,pdb}, .{exe,pdb}) upon a command like " IronPythonConsole.exe modulefile.py" in every directory that you use it... And if you are like me and are using the Lib directory of stdlibs from Python-2.3.5 you get types.{exe, pdb}, os.{exe, pdb}, etc.. Stop the madness!! Anthony On 5/4/05, Timothy Fitz wrote: > > On 5/4/05, Anthony Tarlano wrote: > > I filed a bug as usual, but maybe you should consider a 0.7.4.1release > > fixing this and the *[exe,pdb] file pollution problem asap > > Is the exe "file pollution problem" really a problem? Conceptually, > CPython and IronPython are doing the same thing here. Step 1 is > compile to bytecode, CPython generates .pyc files, IronPython > generates exe files (that are CLR code). Step 2 is run with a virtual > machine. On a windows machine, python associates with .pyc and .py > files, so both the pyc and exe files are "runnable", they both have > the problem that an unsuspecting person might unintentionally run > them, however exe files are more tempting to the average user. I think > functionally that narrows the difference between CPython and > Ironpython down to file extension names and their associated icons, > no? > > Are there any plans to change this? If so to what? My initial thought > was generate dlls, but that loses the double-click to run > functionality. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimhug at exchange.microsoft.com Wed May 4 23:03:50 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Wed, 4 May 2005 14:03:50 -0700 Subject: [IronPython] config files vs. env vars and site.py Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201BF3700@df-fido-msg.exchange.corp.microsoft.com> Right now, IronPython-0.7.* isn't well designed for building Python applications to be deployed. It's primarily a tool for developer use. Part of fixing this is making configuration nicer; however, I'm not sure that config files will be the right final answer. Here's how I see people wanting to deploy IronPython code. 1. A single pre-compiled self-contained MyPythonApp.exe. We will be providing a static compiler to build this based on walking the graph of imported modules and including compiled forms of any other Python modules you want to pass to it explicitly. From the outside this will be indistinguishable from any other CLI program. 2. As a self-contained MyPythonLibrary.dll to include in C#/VB/F#/... applications. This similarly wants the static compiler that produces a nicely pre-compiled self-contained bundle. 3. As an embedded scripting language in a CLI application. In this case the application will be in control through PythonEngine. Here, I think that the application should take on the responsibility for configuration based on its own config mechanisms and can explicitly set sys.path and perform other configuration before running any scripts. We want to make this as easy as possible, possibly with some helper methods on PythonEngine; however, I think that it's pretty easy right now for an embedding application. Unless you have a really compelling short-term need, I'd like to wait until we get the static compiler for cases 1 and 2 built and then see if there's still need for .config file support or not. I expect this will be available in a small number of months. 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: Tuesday, May 03, 2005 11:05 AM To: Discussion of IronPython Subject: RE: [IronPython] IronPython 0.7.4 released .. So how would I do such configuration for non-command-line programs?? Do I need to always front the executable with a bat file?? Such a requirement presents a big wart for those not living in the command line, and I don't see any good reason to let it remain.? I think this is a point where Python should hybridize to live well among its new neighbors. ? May I request .config file support for a future release?? Heck, I'd be happy to hack it in myself. ? Good news on the testing progress! ________________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Martin Maly Sent: Tue 5/3/2005 10:36 AM * site.py, IRONPYTHONPATH and IRONPYTHONSTARTUP environment variables (see below for more details) [...] variables into the global (per-machine or per-user) settings. Instead we use simple scripts to configure environment of the command line for the task at hand. Sdkvars.bat from the .NET SDK is an example. From odennison at gmail.com Wed May 4 23:17:27 2005 From: odennison at gmail.com (Oran Dennison) Date: Wed, 4 May 2005 13:17:27 -0800 Subject: [IronPython] config files vs. env vars and site.py In-Reply-To: <6C91A34F0BB48B40A86F1E146B7A049201BF3700@df-fido-msg.exchange.corp.microsoft.com> References: <6C91A34F0BB48B40A86F1E146B7A049201BF3700@df-fido-msg.exchange.corp.microsoft.com> Message-ID: <242c1a2a0505041417543d05a9@mail.gmail.com> As long as there's a programmatic way to set everything (perhaps with the helper methods on PythonEngine like Jim mentioned), you create any config-based scheme you want. I always prefer to build programmatic config control first, then call that from my config file parser(s). That way I'm not hard-wiring configuration to any particular file format, and I'm not a second-class citizen if I want to configure everything programmatically. Oran -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarmer at thuban.org Thu May 5 00:19:55 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 4 May 2005 15:19:55 -0700 Subject: [IronPython] config files vs. env vars and site.py Message-ID: I'm not all that worried about short-term -- C# is a very lovely language, and I'm holding out hopes to see C-omega either released or folded into C#. I've waited a couple years for generics, and I'll wait a couple years for sql, xml, and object streams as first-class constructs. I'm perfectly happy enough to wait for what are other more interesting milestones. But in the end, of course, is my compelling story: Python as a first-class language in .NET, suitable for mixed-language development in a variety of projects including ASP.NET. This means, in my opinion, adherence to the established .NET way, which by default includes using .config files rather than using environment variables. Even if the .config contains mere pointers to env vars or the pathname of the site.py file, that's a plus. Acting alongside of environment variables (perhaps as an override) would be appropriate and provide the migration path mentioned earlier. .config files are directly supported in the API, are basically expected by the rest of the .NET crowd, and the applications that use then have a richer set of tools for managing them. IronPython has been a great accomplishment, even in it's incomplete form (and put that ActiveState paper to shame). I'd hate to see Python's progress as a language into .NET-land be limited because of an implementation detail of the C-based interpreter. It doesn't have anything to do with the language, so has just that much less weight in persuading my opinion. Heck, if I had the time, I'd try my hand at it myself and feed it back to you (rights signed away, etc). It's just something I think would make IronPython much more compelling for those not already familiar with CPython. ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Jim Hugunin Sent: Wed 5/4/2005 2:03 PM To: Discussion of IronPython Subject: [IronPython] config files vs. env vars and site.py Right now, IronPython-0.7.* isn't well designed for building Python applications to be deployed. It's primarily a tool for developer use. Part of fixing this is making configuration nicer; however, I'm not sure that config files will be the right final answer. Here's how I see people wanting to deploy IronPython code. -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 5427 bytes Desc: not available URL: From kfarmer at thuban.org Thu May 5 00:21:10 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 4 May 2005 15:21:10 -0700 Subject: [IronPython] config files vs. env vars and site.py Message-ID: The proliferation of custom config files has been the bane of my existance, lately. :) And I just spent another night wrestling around with the propagation of environment variables. My boss keeps saying that computers and programming are hard. I don't see that as an excuse for keeping it that way. Isn't this why we've created great languages and much more universally supported file formats? ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Oran Dennison Sent: Wed 5/4/2005 2:17 PM As long as there's a programmatic way to set everything (perhaps with the helper methods on PythonEngine like Jim mentioned), you create any config-based scheme you want. -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3803 bytes Desc: not available URL: From kfarmer at thuban.org Thu May 5 00:40:04 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 4 May 2005 15:40:04 -0700 Subject: [IronPython] config files vs. env vars and site.py Message-ID: I suppose this conversation should make a distinction, which may make entire differences disappear. - the engine the implements the dynamic nature of the language - the compiler, which takes something written in the language and packages it into a language-neutral form - a shell which embeds the engine for on-the-fly usage I suppose I don't care strongly about the shell (IronPythonConsole), though I'd prefer to see it use .config files. I came to .NET after a great time in Python, and think improvements can be made to Python and its deployment to make life better. I care more about the compiler, which should probably conform to the mechanisms that csc, vbc, etc use. This would make them easier to target in VS2005, for example, in the way that one can hack in .NET 1.1 targetting. The engine I think should be invisible to outsiders. It's a helper for classes implemented using Python -- not a feature of either the language or the libraries created with it. Being invisible means, I think, that it not use environment variables or the like. It should have the exact same deployment story as a typical C# or VB.NET assembly. This distinction may be where the apparent disagreement stems from, and probably conforms relatively well to part of Jim's third point. (As a side point, I note that Java apparently did away with environment variable access some time back. I note the gnashing of teeth, but it hasn't brought the Java world crashing around everything.) ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Keith J. Farmer Sent: Wed 5/4/2005 3:19 PM I'm not all that worried about short-term -- C# is a very lovely language, and I'm holding out hopes to see C-omega either released or folded into C#. I've waited a couple years for generics, and I'll wait a couple years for sql, xml, and object streams as first-class constructs. I'm perfectly happy enough to wait for what are other more interesting milestones. But in the end, of course, is my compelling story: Python as a first-class language in .NET, suitable for mixed-language development in a variety of projects including ASP.NET. -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 5707 bytes Desc: not available URL: From kirko at microsoft.com Thu May 5 18:55:48 2005 From: kirko at microsoft.com (Kirk Olynyk) Date: Thu, 5 May 2005 09:55:48 -0700 Subject: [IronPython] Array Access Problem Message-ID: <310187D53C02434D8F2CF4CD951B734102C412EE@RED-MSG-60.redmond.corp.microsoft.com> I can't seem to change the members of an array. Is this a known problem? import sys sys.LoadAssemblyByName("System") sys.LoadAssemblyByName("System.Drawing") from System import* from System.Drawing import * apt = Array.CreateInstance(Point, 1) apt[0] = Point(1,2) print apt[0] apt[0].X = 0 # change the x-coordinate print apt[0] # check to see if it set -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimhug at exchange.microsoft.com Thu May 5 20:42:40 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Thu, 5 May 2005 11:42:40 -0700 Subject: [IronPython] Array Access Problem Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201C7F8BD@df-fido-msg.exchange.corp.microsoft.com> This is a known problem, but we don't have a good fix to it in IronPython. Here's how to set just the X value of a Point in an array today: apt[0] = Point(0, apt[0].Y) OR p = apt[0] p.X = 42 apt[0] = p I suspect that you're not very excited by either of these options. The problem is that Point is a value type/struct and thus needs to be boxed to be passed out to IronPython as an object. When it is boxed a new copy of the data in the Point is created and changes to this new copy won't change the original back in the array. This same problem also shows up when value types are stored in fields and you want to change them. Point is probably far and away the most common instance of this. I can't come up with any elegant ways to make this experience better. There are some inelegant ideas floating around in my head, but I keep hoping for an inspiration here... In case you're wondering why it's hard, Python has a strong invariant that: a[index].name == tmp = a[index] tmp.name My most elegant solution would be to break this invariant in IronPython when setting value types. This would add some additional complexity to the compiler, but not a huge amount. However, any time that I think about changing an invariant of the Python language I get rather nervous about the ramifications... 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: Thursday, May 05, 2005 9:56 AM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Array Access Problem I can't seem to change the members of an array. Is this a known problem? ? import sys ? sys.LoadAssemblyByName("System") sys.LoadAssemblyByName("System.Drawing") ? from System import* from System.Drawing import * ? apt = Array.CreateInstance(Point, 1) apt[0] = Point(1,2) print apt[0] apt[0].X = 0??? # change the x-coordinate print apt[0]??? # check to see if it set From sriramk at gmail.com Thu May 5 21:02:14 2005 From: sriramk at gmail.com (Sriram Krishnan) Date: Fri, 6 May 2005 00:32:14 +0530 Subject: [IronPython] Array Access Problem In-Reply-To: <6C91A34F0BB48B40A86F1E146B7A049201C7F8BD@df-fido-msg.exchange.corp.microsoft.com> Message-ID: <427a6dba.1f7eb160.031d.3922@mx.gmail.com> >However, any time that I think about changing an invariant of the Python language I get rather nervous about the > ramifications... One ramification that I can instantly think of is looping over an array of valuetypes. On more than one occasion, doing a foreach over an array of structs in C# has bitten me People would break their heads trying to find the bug with this piece of code (assuming that this change is implemented) for point in apt: point.X = point.X + 1 #do something with the point struct But frankly, I can't see how you can fix this.Valuetypes are going to take some getting used to for Pythonistas Thanks, Sriram From bob at redivi.com Fri May 6 00:15:02 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 5 May 2005 18:15:02 -0400 Subject: [IronPython] Array Access Problem In-Reply-To: <427a6dba.1f7eb160.031d.3922@mx.gmail.com> References: <427a6dba.1f7eb160.031d.3922@mx.gmail.com> Message-ID: <603777AA-9C1D-4907-B662-0E3108E7ACE6@redivi.com> On May 5, 2005, at 3:02 PM, Sriram Krishnan wrote: >> However, any time that I think about changing an invariant of the >> Python >> > language I get rather nervous about the > >> ramifications... >> > > One ramification that I can instantly think of is looping over an > array of > valuetypes. On more than one occasion, doing a foreach over an > array of > structs in C# has bitten me > > People would break their heads trying to find the bug with this > piece of > code (assuming that this change is implemented) > > for point in apt: > point.X = point.X + 1 #do something with the point struct > > But frankly, I can't see how you can fix this.Valuetypes are going > to take > some getting used to for Pythonistas There are ways you *could* fix the issue: (1) Don't have mutable value types, use a reference type that points to a value type (some kind of proxy) (2) Make value types immutable (or at least the ones you grab from collections) -bob From drew at astro.pas.rochester.edu Sat May 7 05:59:59 2005 From: drew at astro.pas.rochester.edu (Drew Moore) Date: Fri, 06 May 2005 23:59:59 -0400 Subject: [IronPython] Array Access Problem In-Reply-To: <6C91A34F0BB48B40A86F1E146B7A049201C7F8BD@df-fido-msg.exchange.corp.microsoft.com> References: <6C91A34F0BB48B40A86F1E146B7A049201C7F8BD@df-fido-msg.exchange.corp.microsoft.com> Message-ID: <427C3D3F.9080500@astro.pas.rochester.edu> Jim Hugunin wrote: >This is a known problem, but we don't have a good fix to it in IronPython. Here's how to set just the X value of a Point in an array today: > >apt[0] = Point(0, apt[0].Y) > >OR > >p = apt[0] >p.X = 42 >apt[0] = p > > It is a known problem in other .NET languages, correct? Not just Python? >I suspect that you're not very excited by either of these options. The problem is that Point is a value type/struct and thus needs to be boxed to be passed out to IronPython as an object. When it is boxed a new copy of the data in the Point is created and changes to this new copy won't change the original back in the array. > >This same problem also shows up when value types are stored in fields and you want to change them. Point is probably far and away the most common instance of this. > >I can't come up with any elegant ways to make this experience better. There are some inelegant ideas floating around in my head, but I keep hoping for an inspiration here... > >In case you're wondering why it's hard, Python has a strong invariant that: > > CPython does it "correctly." The "strong invariant' behavior described, in CPython does the right thing, yes? .NET, which tries to support both value types and reference types is the souce of the trouble, with the "boxing" and what-not. In .NET, the 'tmp' is not a reference to the original, it is a new boxed object.. an unexpected deep copy. I don't think its a weakness of Python, it is just a consequence of .NET trying to support two type paradigms. The dual paradigm mode enables value types, and also leads to such confusion. I'd say this is a pretty deep one, don't step into it or you'll never get out again. Just say, "that's what happens when you mix paradigms. Python doesn't do that." Me, I prefer C (pure value type paradigm) and/or Python (pure reference type paradigm) but languages that try to do both simultaneously confuse me --- of course, I am a bear of very little brain; I just have a hard time juggling both simultaneously. Python can't map onto both paradigms, and that is a GoodThing. Accept these ugly consequences of boxing which are consistent with other .NET languages and move on. Consistency is a GoodThing too. Python can't expose all of the confusion of the dual-paradigm .NET framework? oh well, it isn't the only one that can't. If the implementation is hard to explain.. (On the other hand, practicality beats purity, touche. but this topic makes me nervous too.) hey, doesn't this mean .NET is a terrible platform for dynamic languages? shouldn't someone write a "short, pithy article" about this? wait, no.... Maybe if we had an insider at Microsoft who could make the CLR a little more "Pythonic" and get rid of those darn value types altogether? ;-) my two cents. tongue-somewhat-in-cheekly-yours Drew From phiho.hoang at rogers.com Sat May 7 16:03:38 2005 From: phiho.hoang at rogers.com (PhiHo Hoang) Date: Sat, 7 May 2005 10:03:38 -0400 Subject: [IronPython] lambda form Message-ID: <017001c5530d$91696190$6601a8c0@DEV> Greetings, Does IronPython support lambda form ? Is this make_inc correct ? Thanks, PhiHo >>> def make_inc(n): ... return lambda x : x + n ... >>> f = make_inc(100) >>> f(1) IronPython.Objects.PythonNameError: name 'n' is not defined at IronPython.Objects.Frame.GetGlobal(String name) at input_98.lamda$0$f10(Object x) at IronPython.Objects.Function1.Call(Object arg0) at IronPython.Objects.Ops.Call(Object func, Object arg0) at input_100.Run(Frame frame) at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) at IronPython.Hosting.PythonEngine.RunInteractive() >>> From alleykat at gmail.com Sat May 7 16:33:55 2005 From: alleykat at gmail.com (Travis Watkins) Date: Sat, 7 May 2005 09:33:55 -0500 Subject: [IronPython] lambda form In-Reply-To: <017001c5530d$91696190$6601a8c0@DEV> References: <017001c5530d$91696190$6601a8c0@DEV> Message-ID: On 5/7/05, PhiHo Hoang wrote: > Greetings, > > Does IronPython support lambda form ? > > Is this make_inc correct ? > > Thanks, > > PhiHo > > >>> def make_inc(n): > ... return lambda x : x + n > ... > >>> f = make_inc(100) > >>> f(1) > IronPython.Objects.PythonNameError: name 'n' is not defined > at IronPython.Objects.Frame.GetGlobal(String name) > at input_98.lamda$0$f10(Object x) > at IronPython.Objects.Function1.Call(Object arg0) > at IronPython.Objects.Ops.Call(Object func, Object arg0) > at input_100.Run(Frame frame) > at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) > at IronPython.Hosting.PythonEngine.RunInteractive() > >>> > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > That works on CPython so I'd say it's a bug. -- Travis Watkins http://www.realistanew.com From march.liu at gmail.com Sat May 7 17:00:56 2005 From: march.liu at gmail.com (March Liu) Date: Sat, 7 May 2005 23:00:56 +0800 Subject: [IronPython] lambda form In-Reply-To: References: <017001c5530d$91696190$6601a8c0@DEV> Message-ID: lambda key word may remove from CPython 3.0. Maybe we can replace it by the other way as List Comprehensions, funcation Factory... 2005/5/7, Travis Watkins : > On 5/7/05, PhiHo Hoang wrote: > > Greetings, > > > > Does IronPython support lambda form ? > > > > Is this make_inc correct ? > > > > Thanks, > > > > PhiHo > > > > >>> def make_inc(n): > > ... return lambda x : x + n > > ... > > >>> f = make_inc(100) > > >>> f(1) > > IronPython.Objects.PythonNameError: name 'n' is not defined > > at IronPython.Objects.Frame.GetGlobal(String name) > > at input_98.lamda$0$f10(Object x) > > at IronPython.Objects.Function1.Call(Object arg0) > > at IronPython.Objects.Ops.Call(Object func, Object arg0) > > at input_100.Run(Frame frame) > > at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) > > at IronPython.Hosting.PythonEngine.RunInteractive() > > >>> > > _______________________________________________ > > users-ironpython.com mailing list > > users-ironpython.com at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > That works on CPython so I'd say it's a bug. > > -- > 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 > -- ????? http://blog.csdn.net/ccat ?? March.Liu From phiho.hoang at rogers.com Sat May 7 17:01:51 2005 From: phiho.hoang at rogers.com (PhiHo Hoang) Date: Sat, 7 May 2005 11:01:51 -0400 Subject: [IronPython] System.Exception: can't convert 66.6 to System.Int32 Message-ID: <01b001c55315$b3b0e360$6601a8c0@DEV> Greetings, Why 66.6 cannot be converted to System.Int32 ? Thanks, PhiHo >>> a [333, 1234.5, 1, 333, -1, 66.6] >>> a.sort() System.InvalidOperationException: Failed to compare two elements in the array. - --> System.Exception: can't convert 66.6 to System.Int32 at IronPython.Objects.Ops.ConvertTo(Object o, Type toType) at IronPython.Objects.Ops.Compare(Object x, Object y) at IronPython.Objects.List.DefaultPythonComparer.Compare(Object x, Object y) at System.Array.SorterObjectArray.QuickSort(Int32 left, Int32 right) --- End of inner exception stack trace --- at System.Array.SorterObjectArray.QuickSort(Int32 left, Int32 right) at System.Array.Sort(Array keys, Array items, Int32 index, Int32 length, IComparer comparer) at IronPython.Objects.List.sort() at ReflectOpt.IronPython.Objects.List.sort(Object ) at IronPython.Objects.BuiltinFunction.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 input_114.Run(Frame frame) at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) at IronPython.Hosting.PythonEngine.RunInteractive() >>> From jimhug at exchange.microsoft.com Sat May 7 20:06:51 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Sat, 7 May 2005 11:06:51 -0700 Subject: [IronPython] lambda form Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201C7FDED@df-fido-msg.exchange.corp.microsoft.com> March Liu wrote: > lambda key word may remove from CPython 3.0. Maybe we can replace it > by the other way as List Comprehensions, funcation Factory... I like to encourage people who come from a functional background to use list comprehensions instead of lambda when possible. I'm not sure that lambda should go away, but I do wonder if map, filter and reduce shouldn't be removed from builtins to more strongly encourage the use of list comprehensions or generator expressions instead. > 2005/5/7, Travis Watkins : > > On 5/7/05, PhiHo Hoang wrote: > > > >>> def make_inc(n): > > > ... return lambda x : x + n > > > ... > > > >>> f = make_inc(100) > > > >>> f(1) > > > IronPython.Objects.PythonNameError: name 'n' is not defined > > That works on CPython so I'd say it's a bug. As Travis says, the right presumption is that this is a bug especially since this works in recent versions of CPython. IronPython is behaving like CPython 2.1 and earlier by not supporting nested scopes. Here's this same example on CPython-2.0. Notice that it behaves just like IronPython. Python 2.0.1 (#18, Jun 22 2001, 02:26:03) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> def make_inc(n): ... return lambda x: x + n ... >>> f = make_inc(100) >>> f(1) Traceback (most recent call last): File "", line 1, in ? File "", line 2, in NameError: There is no variable named 'n' Today, IronPython is trying to be somewhere between Python 2.3 and 2.4 in features. The goal for the 1.0 release is to be fully compatible with Python 2.4. Therefore, even though this behavior does match an earlier version of CPython, it is a bug since it doesn't match either of our two target versions. This will take some work to fix so it might be a few releases before we get nested scopes properly working in IronPython. Thanks - Jim From jimhug at exchange.microsoft.com Sat May 7 20:15:26 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Sat, 7 May 2005 11:15:26 -0700 Subject: [IronPython] System.Exception: can't convert 66.6 to System.Int32 Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201C7FDEE@df-fido-msg.exchange.corp.microsoft.com> PhiHo Hoang wrote: > Why 66.6 cannot be converted to System.Int32 ? 66.6 can be both explicitly converted to an int and compared to one. >>> int(66.6) 66 >>> 12 < 66.6 True >>> 66.6 < 12 False It's a good thing that 66.6 won't be implicitly converted to an int since that would lose precision. > >>> a > [333, 1234.5, 1, 333, -1, 66.6] > >>> a.sort() > System.InvalidOperationException: Failed to compare two elements in the > array. - However, you're right that IronPython doesn't handle this correctly for sorting an array. We already have one bug for sorting mixed-type arrays (bug #63) but it's nice to add this case as well to the set we need to fix. Thanks - Jim From drew at astro.pas.rochester.edu Sun May 8 05:45:54 2005 From: drew at astro.pas.rochester.edu (Drew Moore) Date: Sat, 07 May 2005 23:45:54 -0400 Subject: [IronPython] Array Access Problem In-Reply-To: <603777AA-9C1D-4907-B662-0E3108E7ACE6@redivi.com> References: <427a6dba.1f7eb160.031d.3922@mx.gmail.com> <603777AA-9C1D-4907-B662-0E3108E7ACE6@redivi.com> Message-ID: <427D8B72.9030903@astro.pas.rochester.edu> Bob Ippolito wrote: > There are ways you *could* fix the issue: > > (1) Don't have mutable value types, use a reference type that points > to a value type (some kind of proxy) > (2) Make value types immutable (or at least the ones you grab from > collections) > I kinda like both of these options. Darn dual paradigm. One Pythonic phrase that comes to mind is "explicit is better than implicit." On #1 above, if the Python side required the user to write myobj = BoxedValue.Proxy() it would be obvious that the object is a proxy (perhaps an expensive performance-killing one) into the underlying struct. likewise myobj = BoxedValue.Copy() would make it obvious that you have a copy of the object, and you shouldn't be alarmed that modifications are not reflected in the underlying struct. (immutable value types would save the wall from your head.. the right spirit, but a wee bit harsh. Enforcing readability and expression in source code is the more Pythonic way isnt it, hmm?) Oh, "In the face of ambiguity, refuse the temptation to guess." How's that one grab ya? I'm still not sure exactly how to apply this to the collections issue, etc, but perhaps the spirit here is going in the right direction. Goal: Implement the Python/.NET interface such that it forces the code to express proxy or copy, then nobody gets confused when they look at the code. Other .NET languages might benefit from this Pythonic approach too... If a little more typing saves a lot of confusion, it is worth it. Details: ??? (margins not big enough, you know..) Drew PS: Bob, that threadedselectreactor in twisted2 is neat stuff! thanks again! I'm still trying to digest how it made a tricky problem so easy, 'cause it's a parallel to a problem I've been wrestling with at QVII. From phiho.hoang at rogers.com Sun May 8 14:10:23 2005 From: phiho.hoang at rogers.com (PhiHo Hoang) Date: Sun, 8 May 2005 08:10:23 -0400 Subject: [IronPython] lambda form References: <6C91A34F0BB48B40A86F1E146B7A049201C7FDED@df-fido-msg.exchange.corp.microsoft.com> Message-ID: <005e01c553c6$e9bc7800$6701a8c0@DEV> Jim Hugunin wrote: > March Liu wrote: > > lambda key word may remove from CPython 3.0. Maybe we can replace it > > by the other way as List Comprehensions, funcation Factory... > I like to encourage people who come from a functional background to use > list comprehensions instead of lambda when possible. I'm not sure that > lambda should go away, but I do wonder if map, filter and reduce > shouldn't be removed from builtins I would gladly trade this trio for defsyn ( and the crew ;-) > to more strongly encourage the use of > list comprehensions or generator expressions instead. Agreed. [SNIP] Thanks for looking into this lambda thingy. PhiHo From phiho.hoang at rogers.com Sun May 8 14:12:31 2005 From: phiho.hoang at rogers.com (PhiHo Hoang) Date: Sun, 8 May 2005 08:12:31 -0400 Subject: [IronPython] System.Exception: can't convert 66.6 to System.Int32 References: <6C91A34F0BB48B40A86F1E146B7A049201C7FDEE@df-fido-msg.exchange.corp.microsoft.com> Message-ID: <006901c553c7$3621cfb0$6701a8c0@DEV> Jim Hugunin wrote: > PhiHo Hoang wrote: > > Why 66.6 cannot be converted to System.Int32 ? > 66.6 can be both explicitly converted to an int and compared to one. > >>> int(66.6) > 66 > >>> 12 < 66.6 > True > >>> 66.6 < 12 > False > It's a good thing that 66.6 won't be implicitly converted to an int > since that would lose precision. > > >>> a > > [333, 1234.5, 1, 333, -1, 66.6] > > >>> a.sort() > > System.InvalidOperationException: Failed to compare two elements in > > the array. - > However, you're right that IronPython doesn't handle this correctly for > sorting an array. We already have one bug for sorting mixed-type arrays > (bug #63) but it's nice to add this case as well to the set we need to > fix. Talking of precision, for sorting, wouldn't it be more precise to convert int to float instead of float to int, when there is a mixture ? Thanks, PhiHo From alleykat at gmail.com Sun May 8 14:54:59 2005 From: alleykat at gmail.com (Travis Watkins) Date: Sun, 8 May 2005 07:54:59 -0500 Subject: [IronPython] System.Exception: can't convert 66.6 to System.Int32 In-Reply-To: <006901c553c7$3621cfb0$6701a8c0@DEV> References: <6C91A34F0BB48B40A86F1E146B7A049201C7FDEE@df-fido-msg.exchange.corp.microsoft.com> <006901c553c7$3621cfb0$6701a8c0@DEV> Message-ID: On 5/8/05, PhiHo Hoang wrote: > Jim Hugunin wrote: > > > PhiHo Hoang wrote: > > > Why 66.6 cannot be converted to System.Int32 ? > > 66.6 can be both explicitly converted to an int and compared to one. > > > >>> int(66.6) > > 66 > > >>> 12 < 66.6 > > True > > >>> 66.6 < 12 > > False > > > It's a good thing that 66.6 won't be implicitly converted to an int > > since that would lose precision. > > > > >>> a > > > [333, 1234.5, 1, 333, -1, 66.6] > > > >>> a.sort() > > > System.InvalidOperationException: Failed to compare two elements in > > > the array. - > > > However, you're right that IronPython doesn't handle this correctly for > > sorting an array. We already have one bug for sorting mixed-type arrays > > (bug #63) but it's nice to add this case as well to the set we need to > > fix. > > Talking of precision, for sorting, wouldn't it be more precise to > convert int to float instead of float to int, when there is a mixture ? > > Thanks, > > PhiHo > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > Yeah, you could probably convert all the ints to floats during the comparison then convert them back afterward. -- Travis Watkins http://www.realistanew.com From luismg at gmx.net Sun May 8 20:15:08 2005 From: luismg at gmx.net (Luis M. Gonzalez) Date: Sun, 8 May 2005 15:15:08 -0300 Subject: [IronPython] lambda form Message-ID: <000601c553f9$e6a87910$1302a8c0@luis> Regarding lambda, map and reduce, Guido Van Rossum has said several times that these built-ins are amongst its "Python regrets". This is what he said in a recent interview: - If you could change some things that have been done in the langage, what would it be ? Drop lambda, filter, map and reduce. Make range() behave like xrange(). Make keys() and many other methods and built-ins return iterators rather than lists. The interview is here: http://blogs.nuxeo.com/sections/blogs/tarek_ziade/2005_04_11_guido_van_rossum -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarmer at thuban.org Sun May 8 20:32:28 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Sun, 8 May 2005 11:32:28 -0700 Subject: [IronPython] Pythalon Message-ID: IronPython + Avalon experiment ... http://blogs.msdn.com/johngossman/archive/2005/05/08/415505.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From alleykat at gmail.com Sun May 8 20:35:02 2005 From: alleykat at gmail.com (Travis Watkins) Date: Sun, 8 May 2005 13:35:02 -0500 Subject: [IronPython] Pythalon In-Reply-To: References: Message-ID: On 5/8/05, Keith J. Farmer wrote: > > > > IronPython + Avalon experiment ? > > http://blogs.msdn.com/johngossman/archive/2005/05/08/415505.aspx > > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > Screenshot? -- Travis Watkins http://www.realistanew.com From kfarmer at thuban.org Sun May 8 21:18:47 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Sun, 8 May 2005 12:18:47 -0700 Subject: [IronPython] Pythalon Message-ID: Ask Gossman -- I just forward the URL. -----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 Screenshot? From firemoth at gmail.com Sun May 8 23:23:02 2005 From: firemoth at gmail.com (Timothy Fitz) Date: Sun, 8 May 2005 17:23:02 -0400 Subject: [IronPython] lambda form In-Reply-To: <000601c553f9$e6a87910$1302a8c0@luis> References: <000601c553f9$e6a87910$1302a8c0@luis> Message-ID: <972ec5bd0505081423df3d289@mail.gmail.com> On 5/8/05, Luis M. Gonzalez wrote: > Regarding lambda, map and reduce, Guido Van Rossum has said several times > that these built-ins are amongst its "Python regrets". > > This is what he said in a recent interview: > > - If you could change some things that have been done in the > langage, what would it be ? > > Drop lambda, filter, map and reduce. Make range() behave like xrange(). Make > keys() and many other methods and built-ins return iterators rather than > lists. With respect to IronPython, lambda, filter, map and reduce need to be implemented, for the same reasons lambda won't go away until python 3.0 if it ever does. While he Guido dislike lambda, the reasons are particularly about its implementation and current useage, and if a suitable anonymous function syntax is found he may accept it. From johngos at microsoft.com Mon May 9 01:22:03 2005 From: johngos at microsoft.com (John Gossman) Date: Sun, 8 May 2005 16:22:03 -0700 Subject: [IronPython] Pythalon Message-ID: <7B75DD93D78B6C4EAD2CB400F3C1F3050628E675@RED-MSG-51.redmond.corp.microsoft.com> Try this: http://www.johngossman.net/PythalonSample.html -----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: Sunday, May 08, 2005 12:19 PM To: Discussion of IronPython Subject: RE: [IronPython] Pythalon Ask Gossman -- I just forward the URL. -----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 Screenshot? _______________________________________________ users-ironpython.com mailing list users-ironpython.com at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From kbond at free.fr Mon May 9 07:42:18 2005 From: kbond at free.fr (kbond) Date: Mon, 09 May 2005 07:42:18 +0200 Subject: [IronPython] word Automation Message-ID: <427EF83A.3090708@free.fr> Hello, First congratulation of all, thank you for the tremendous work that you have already done. I am looking forward the day where I will be able to translate all my MS office automation in python scripts. Am I correct I say that iron python will allow it? So today I try to give it a try but unfortunatly withou success till now. I am trying to translate this simple vb.net module to iron python, is there someone reading this list that can help me? the VB Imports word = Microsoft.Office.Interop.word Module Module1 Sub Main() Dim oWord As Word.ApplicationClass 'Start Word and open the document. oWord = CreateObject("Word.Application") oWord.Visible = True oWord.Documents.Open("C:\tmp\Doc1.doc") 'Run the macros. 'oWord.Run("DoKbTest") 'oWord.Run("DoKbTestWithParameter", "Hello from VB .NET Client") 'Quit Word. oWord.Quit() System.Runtime.InteropServices.Marshal.ReleaseComObject(oWord) oWord = Nothing End Sub End Module Iron Python import sys sys.LoadAssemblyByName("Microsoft.Office.Interop.Word") import Microsoft.Office.Interop.Word as wordApp oWord = wordApp.ApplicationClass oWord = CreateObject("wordApp.Application") oWord.Visible = True oWord.Documents.Open("C:\tmp\Doc1.doc") oWord.Quit() System.Runtime.InteropServices.Marshal.ReleaseComObject(oWord) oWord = Nothing thank you From mailinglist.account at gmail.com Mon May 9 12:50:36 2005 From: mailinglist.account at gmail.com (Anthony Tarlano) Date: Mon, 9 May 2005 12:50:36 +0200 Subject: [IronPython] word Automation In-Reply-To: <427EF83A.3090708@free.fr> References: <427EF83A.3090708@free.fr> Message-ID: Hi, Yes it should work, but I don't have the correct assembly to be able to test it. You should remember that you should just translate the code from VB to IronPython. IronPython is a dynamically bound language, so you don't have to do things like declaring the local variable oWord (i.e. 'oWord = wordApp.ApplicationClass') In python an variable object is bound to a type upon assignment to an Rvalue object If you tell me how to get the assembly having "Microsoft.Office.Interop.Word" I will try it out for you and post back the code snippet. Anthony On 5/9/05, kbond wrote: > > Hello, > > First congratulation of all, thank you for the tremendous work that you > have already done. > I am looking forward the day where I will be able to translate all my MS > office automation in python scripts. > > Am I correct I say that iron python will allow it? > > So today I try to give it a try but unfortunatly withou success till now. > I am trying to translate this simple vb.net module to iron > python, is > there someone reading this list that can help me? > > the VB > > Imports word = Microsoft.Office.Interop.word > Module Module1 > > Sub Main() > Dim oWord As Word.ApplicationClass > > 'Start Word and open the document. > oWord = CreateObject("Word.Application") > oWord.Visible = True > oWord.Documents.Open("C:\tmp\Doc1.doc") > > 'Run the macros. > 'oWord.Run("DoKbTest") > 'oWord.Run("DoKbTestWithParameter", "Hello from VB .NET Client") > > 'Quit Word. > oWord.Quit() > System.Runtime.InteropServices.Marshal.ReleaseComObject(oWord) > oWord = Nothing > > End Sub > > End Module > > Iron Python > > import sys > sys.LoadAssemblyByName("Microsoft.Office.Interop.Word") > import Microsoft.Office.Interop.Word as wordApp > oWord = wordApp.ApplicationClass > > oWord = CreateObject("wordApp.Application") > oWord.Visible = True > oWord.Documents.Open("C:\tmp\Doc1.doc") > > oWord.Quit() > System.Runtime.InteropServices.Marshal.ReleaseComObject(oWord) > oWord = Nothing > > thank you > > _______________________________________________ > 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: From mailinglist.account at gmail.com Mon May 9 12:52:43 2005 From: mailinglist.account at gmail.com (Anthony Tarlano) Date: Mon, 9 May 2005 12:52:43 +0200 Subject: [IronPython] word Automation In-Reply-To: References: <427EF83A.3090708@free.fr> Message-ID: That should have read "you should not just translate the..." Anthony On 5/9/05, Anthony Tarlano wrote: > > Hi, > > Yes it should work, but I don't have the correct assembly to be able to > test it. > > You should remember that you should just translate the code from VB to > IronPython. IronPython is a dynamically bound language, so you don't have to > do things like declaring the local variable oWord (i.e. 'oWord = > wordApp.ApplicationClass') > > In python an variable object is bound to a type upon assignment to an > Rvalue object > > If you tell me how to get the assembly having " > Microsoft.Office.Interop.Word" I will try it out for you and post back the > code snippet. > > Anthony > > On 5/9/05, kbond wrote: > > > > Hello, > > > > First congratulation of all, thank you for the tremendous work that you > > have already done. > > I am looking forward the day where I will be able to translate all my MS > > office automation in python scripts. > > > > Am I correct I say that iron python will allow it? > > > > So today I try to give it a try but unfortunatly withou success till > > now. > > I am trying to translate this simple vb.net module to > > iron python, is > > there someone reading this list that can help me? > > > > the VB > > > > Imports word = Microsoft.Office.Interop.word > > Module Module1 > > > > Sub Main() > > Dim oWord As Word.ApplicationClass > > > > 'Start Word and open the document. > > oWord = CreateObject("Word.Application") > > oWord.Visible = True > > oWord.Documents.Open("C:\tmp\Doc1.doc") > > > > 'Run the macros. > > 'oWord.Run("DoKbTest") > > 'oWord.Run("DoKbTestWithParameter", "Hello from VB .NET Client") > > > > 'Quit Word. > > oWord.Quit() > > System.Runtime.InteropServices.Marshal.ReleaseComObject(oWord) > > oWord = Nothing > > > > End Sub > > > > End Module > > > > Iron Python > > > > import sys > > sys.LoadAssemblyByName("Microsoft.Office.Interop.Word") > > import Microsoft.Office.Interop.Word as wordApp > > oWord = wordApp.ApplicationClass > > > > oWord = CreateObject("wordApp.Application") > > oWord.Visible = True > > oWord.Documents.Open("C:\tmp\Doc1.doc") > > > > oWord.Quit() > > System.Runtime.InteropServices.Marshal.ReleaseComObject (oWord) > > oWord = Nothing > > > > thank you > > > > _______________________________________________ > > 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: From jvm_cop at spamcop.net Mon May 9 16:38:05 2005 From: jvm_cop at spamcop.net (J. Merrill) Date: Mon, 09 May 2005 10:38:05 -0400 Subject: [IronPython] config files vs. env vars and site.py In-Reply-To: <6C91A34F0BB48B40A86F1E146B7A049201BF3700@df-fido-msg.excha nge.corp.microsoft.com> Message-ID: <4.3.2.7.2.20050509095858.064bb898@mail.comcast.net> I'm somewhat surprised that neither your 1 and 2 suggest the possibility of my using compiled DLLs created from one or more Python modules. That is, if I am going to deploy a number of Python-coded executables (your 1) and/or DLLs for use by others (your 2), and each of them references the same set of N imported Python modules (some standard ones included in the IronPython distribution, some built by me or others), why should the code of those N modules have to be included (as MSI bytecode) in each of my EXEs and DLLs? That's not what would happen in CPython. I want the ability to write my source code the way we always have, referencing imported modules by name (without any reference to the physical location of the source file within my code), and later have a way to group together any number of Python modules into a .NET DLL assembly that's intended for use by IronPython code and not necessarily by non-Python code. (The pre-.NET term for that would be "to link them into a library.") I'll call the result a "Python-module-collection DLL" or PMCD in this discussion. When I compile something for use outside the Python environment (as an EXE or for-others DLL), I should be able to have the Python import statements reference the code of the Python modules I've included within PMCDs, and only include the MSI bytecode (in the resulting EXE/DLL) of those Python modules that aren't found in any PMCD that I tell the compiler to look at. That's the way other .NET languages work -- you compile while referencing other assemblies using e.g. a /r commandline parameter -- but with the Python-esque feature that if your code imports a Python module that isn't found in any of the referenced assemblies, instead of failing the compile (as would happen in C# or VB.Net) it will locate the module's source code and include the resulting MSI bytecode in the result. For full flexibility, I should be able to specify explicitly that I want to ignore the code for a particular module within a referenced PMCD (causing the source for that module to be compiled into my EXE/DLL), perhaps by placing a /r reference to particular a Python source module before a reference to a PMCD containing a module with the same name. It's desirable to be able to build an "all-in-one" EXE or DLL in some situations, but it's also handy to be able to distribute "library" functionality separately. Note that the manifest of any for-others EXEs/DLLs will reference the PMCDs explicitly for any externally-defined functionality, so AFAICT we're following all the normal .NET rules. All that's different is that you need not produce a full list of "referenced stuff" when you compile, provided that Python source modules are available for anything not otherwise visible to the compiler. At 05:03 PM 5/4/2005, Jim Hugunin wrote >Right now, IronPython-0.7.* isn't well designed for building Python applications to be deployed. It's primarily a tool for developer use. Part of fixing this is making configuration nicer; however, I'm not sure that config files will be the right final answer. Here's how I see people wanting to deploy IronPython code. > >1. A single pre-compiled self-contained MyPythonApp.exe. We will be providing a static compiler to build this based on walking the graph of imported modules and including compiled forms of any other Python modules you want to pass to it explicitly. From the outside this will be indistinguishable from any other CLI program. > >2. As a self-contained MyPythonLibrary.dll to include in C#/VB/F#/... applications. This similarly wants the static compiler that produces a nicely pre-compiled self-contained bundle. > >3. As an embedded scripting language in a CLI application. In this case the application will be in control through PythonEngine. Here, I think that the application should take on the responsibility for configuration based on its own config mechanisms and can explicitly set sys.path and perform other configuration before running any scripts. We want to make this as easy as possible, possibly with some helper methods on PythonEngine; however, I think that it's pretty easy right now for an embedding application. > >Unless you have a really compelling short-term need, I'd like to wait until we get the static compiler for cases 1 and 2 built and then see if there's still need for .config file support or not. I expect this will be available in a small number of months. > >Thanks - Jim J. Merrill / Analytical Software Corp From jvm_cop at spamcop.net Mon May 9 16:49:02 2005 From: jvm_cop at spamcop.net (J. Merrill) Date: Mon, 09 May 2005 10:49:02 -0400 Subject: [IronPython] Re: IronPython 0.7.4 released Message-ID: <4.3.2.7.2.20050509104857.0643ffe8@mail.comcast.net> Did an answer to this ever come (perhaps privately to you)? At 06:54 AM 5/4/2005, Anthony Tarlano wrote >Great job geeting 0.7.4 out the door!! > >Thanks for the heads up that it's possible to just grab the Lib >directory from Python-2.3.5 and replace the IPython/bin/Lib directory >to get the ball rolling... > >One big question comes to mind now that I have all those nice stdlib >.py files.. Do you intend to adapt the python stdlib to work >seamlessly in IronPython 1.0? > >If you don't think this is the plan then I will start a project to get >this work done.. Please let me know as to not re-invent the wheel. > >Anthony J. Merrill / Analytical Software Corp From mailinglist.account at gmail.com Mon May 9 18:00:48 2005 From: mailinglist.account at gmail.com (Anthony Tarlano) Date: Mon, 9 May 2005 18:00:48 +0200 Subject: [IronPython] Re: IronPython 0.7.4 released In-Reply-To: <4.3.2.7.2.20050509104804.063b0f28@mail.comcast.net> References: <6C91A34F0BB48B40A86F1E146B7A049201BF34A4@df-fido-msg.exchange.corp.microsoft.com> <4.3.2.7.2.20050509104804.063b0f28@mail.comcast.net> Message-ID: James, Yes, I did get a private response. Jim let me know that the issue is being discussed internally and when there has been an agreement on the way forward, which should be relatively soon, he will post that information to the mailing list. Anthony On 5/9/05, J. Merrill wrote: > > Did an answer to this ever come (perhaps privately to you)? > > At 06:54 AM 5/4/2005, Anthony Tarlano wrote > >Great job geeting 0.7.4 out the door!! > > > >Thanks for the heads up that it's possible to just grab the Lib > >directory from Python-2.3.5 and replace the IPython/bin/Lib directory > >to get the ball rolling... > > > >One big question comes to mind now that I have all those nice stdlib > >.py files.. Do you intend to adapt the python stdlib to work > >seamlessly in IronPython 1.0? > > > >If you don't think this is the plan then I will start a project to get > >this work done.. Please let me know as to not re-invent the wheel. > > > >Anthony > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimhug at exchange.microsoft.com Mon May 9 18:06:11 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Mon, 9 May 2005 09:06:11 -0700 Subject: [IronPython] lambda form Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201C7FE97@df-fido-msg.exchange.corp.microsoft.com> Timothy Fitz wrote: > On 5/8/05, Luis M. Gonzalez wrote: > > Regarding lambda, map and reduce, Guido Van Rossum has said several > times > > that these built-ins are amongst its "Python regrets". > > > > This is what he said in a recent interview: > > > > - If you could change some things that have been done in the > > langage, what would it be ? > > > > Drop lambda, filter, map and reduce. Make range() behave like xrange(). > Make > > keys() and many other methods and built-ins return iterators rather than > > lists. > > With respect to IronPython, lambda, filter, map and reduce need to be > implemented, for the same reasons lambda won't go away until python > 3.0 if it ever does. Of course IronPython implements these today and will continue to do so - at least until we get to start targeting Python 3.0. The main issue is timing. List comprehensions were implemented from the beginning, but we're still getting around to nested scopes. I think this is the right priority order. This doesn't mean that I'll stop encouraging people from using list comprehensions instead of filter and map. The one tangible impact of this preference is that I'm unlikely to work on very heavy duty optimizations to improve the performance of map/filter anytime in the near future. -Jim From johngos at microsoft.com Sun May 8 23:45:43 2005 From: johngos at microsoft.com (John Gossman) Date: Sun, 8 May 2005 14:45:43 -0700 Subject: [IronPython] Pythalon Message-ID: <7B75DD93D78B6C4EAD2CB400F3C1F3050628E66D@RED-MSG-51.redmond.corp.microsoft.com> Attached a small png. I was in the middle of the blog entry when I realized I didn't have a place to host pictures... I'm fixing that. -----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: Sunday, May 08, 2005 12:19 PM To: Discussion of IronPython Subject: RE: [IronPython] Pythalon Ask Gossman -- I just forward the URL. -----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 Screenshot? _______________________________________________ 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: untitled.PNG Type: image/png Size: 32655 bytes Desc: untitled.PNG URL: From jamesmerrill at usa.net Mon May 9 16:48:29 2005 From: jamesmerrill at usa.net (J. Merrill) Date: Mon, 09 May 2005 10:48:29 -0400 Subject: [IronPython] Re: IronPython 0.7.4 released In-Reply-To: References: <6C91A34F0BB48B40A86F1E146B7A049201BF34A4@df-fido-msg.exchange.corp.microsoft.com> <6C91A34F0BB48B40A86F1E146B7A049201BF34A4@df-fido-msg.exchange.corp.microsoft.com> Message-ID: <4.3.2.7.2.20050509104804.063b0f28@mail.comcast.net> Did an answer to this ever come (perhaps privately to you)? At 06:54 AM 5/4/2005, Anthony Tarlano wrote >Great job geeting 0.7.4 out the door!! > >Thanks for the heads up that it's possible to just grab the Lib >directory from Python-2.3.5 and replace the IPython/bin/Lib directory >to get the ball rolling... > >One big question comes to mind now that I have all those nice stdlib >.py files.. Do you intend to adapt the python stdlib to work >seamlessly in IronPython 1.0? > >If you don't think this is the plan then I will start a project to get >this work done.. Please let me know as to not re-invent the wheel. > >Anthony From kfarmer at thuban.org Mon May 9 22:22:00 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Mon, 9 May 2005 13:22:00 -0700 Subject: [IronPython] Pythalon Message-ID: So when do you add the turtle to Avalon? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2754 bytes Desc: not available URL: From yann.malet at naema.org Mon May 9 22:03:12 2005 From: yann.malet at naema.org (Yann) Date: Mon, 09 May 2005 22:03:12 +0200 Subject: [IronPython] Word Automation Message-ID: <427FC200.7000304@naema.org> Hello Anthony, Since I am not sure to understand you request: >>If you tell me how to get the assembly having "Microsoft.Office.Interop.Word" >>I will try it out for you and post back the code snippet. I googled to find some answers. Here it is what I found:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnoxpta/html/odc_oxppias.asp I hope that help you to help me... However I haven't done this I have just "add reference" to COM librairy "Microsoft Word 11.0 Object..." I have just check in my c:\WINDOWS\assembly and I can see Microsoft.Office.Interop.word. thank you for your help Regards From mailinglist.account at gmail.com Tue May 10 09:37:45 2005 From: mailinglist.account at gmail.com (Anthony Tarlano) Date: Tue, 10 May 2005 09:37:45 +0200 Subject: [IronPython] Word Automation In-Reply-To: <427FC200.7000304@naema.org> References: <427FC200.7000304@naema.org> Message-ID: Yann, I found the information that I needed concorning the Office 2003 primary interop assemblies (PIAs) at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dno2k3ta/html/OfficePrimaryInteropAssembliesFAQ.asp I have not had a chance to look into the PIA deeper, but I will try to get to is as soon as I find sometime.. Regards, Anthony On 5/9/05, Yann wrote: > > Hello Anthony, > > Since I am not sure to understand you request: > >>If you tell me how to get the assembly having " > Microsoft.Office.Interop.Word" > >>I will try it out for you and post back the code snippet. > > I googled to find some answers. > Here it is what I found: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnoxpta/html/odc_oxppias.asp > I hope that help you to help me... > However I haven't done this I have just "add reference" to COM librairy > "Microsoft Word 11.0 Object..." > I have just check in my c:\WINDOWS\assembly and I can see > Microsoft.Office.Interop.word. > > thank you for your help > > Regards > > _______________________________________________ > 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: From jimhug at exchange.microsoft.com Tue May 10 19:57:48 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Tue, 10 May 2005 10:57:48 -0700 Subject: [IronPython] Array Access Problem Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201C802CF@df-fido-msg.exchange.corp.microsoft.com> I think that value types are a real advantage of the Common Language Infrastructure (CLI) even though they make life more difficult for IronPython. They're an advantage because they're an essential concept for a number of data structures and people will use the notion of a value type whether or not you give it to them. In a case like that it's better to capture it explicitly so that tools and languages can reliably work with it. One example of value types is Numeric Python's arrays of complex numbers. It's vital for the performance of these arrays that they're encoded as arrays of C structs rather than arrays of pointers to small objects. If I wanted to implement these same arrays in Java I'd probably implement them as a double[2*N] where I'd then manually keep track of the different indices for the real and complex parts. The use of structs for complex numbers in Numeric Python arrays has never been a source of complaints. The reason is that complex numbers in Python are immutable and none of the issues we're discussing here are a problem for immutable data types. If you're interested in a deeper technical dive into value types, I'd recommend this blog: http://blogs.msdn.com/cbrumme/archive/2003/05/10/51425.aspx Since we need to live with value types as part of the cost of seamless interaction with the rest of the CLS world, I think that Bob's ideas are intriguing. After looking at them more closely, I'm pretty sure that mutable proxies would have even more potential for confusion that the current situation of always copying value types. The idea of treating value types as immutable from IronPython is really appealing even though that also has some significant unresolved issues. > Bob Ippolito wrote: > > (1) Don't have mutable value types, use a reference type that points > > to a value type (some kind of proxy) I don't think that this is possible to do in a consistent way and my suspicion is that doing this half-way would be more confusing than not doing it at all. Let's walk through the original example: >>> apt = Array.CreateInstance(Point, 1) This creates a true CLI array of Point structs >>> pt = Point(1,2) Today this makes a new Point struct and returns the boxed version of that struct. We could instead return a new instance of an imaginary new type, ValueProxy. This new instance is a standard reference type that holds a point as its data. This proxy will need to forward all field, property and method accesses to the contained Point struct. >>> apt[0] = pt What do we do here? We need to copy the data in pt into apt[0]. This is what it means to have an array of structs. No matter what we do with proxies or wrappers there's no way out of this copy. We could add some kind of pointer to the ValueProxy keeping track of the fact that there's a copy of this variable now held in apt[0]. This would need to be an arbitrarily large list of pointers. This list would also be easy to break with CLI code that directly modified apt or other containers holding on to the value types. >>> pt.X = 0 The only way this can modify apt[0] is if we keep the full list of references in ValueProxy. See above for why keeping that full list still wouldn't always work. >>> apt[0].X = 0 This example would work using the ValueProxy that pointed to apt[0]; however, when apt[0] is assigned to a variable the situation becomes as bad as it is for pt. >>> for pt in apt: >>> pt.X = 0 The for loop uses an Enumerator to loop through the points in apt. Without constructing a custom enumerator for arrays there's no way to get anything but copy semantics here. While we could build a custom enumerator for arrays this wouldn't solve the general case of value types being returned from methods. When I played with this example in C#, I discovered something interesting: Point[] pa = new Point[3]; foreach (Point p in pa) { pt.X = 10; } The code above generates an error from the C# compiler: "Cannot modify members of 'p' because it is a 'foreach iteration variable'" The C# compiler is treating these iteration variables as semi-immutable in order to minimize the confusion that can come from the copy semantics of value types. This seems like a promising idea... > > (2) Make value types immutable (or at least the ones you grab from > > collections) All of the problems with value types stem from their mutability. Nobody ever complains that int, double, char, etc. are value types because those are all immutable. For immutable objects there's no difference between pass by reference and pass by value. The CLR team's API Design Guidelines say this: - Do not create mutable value types. http://blogs.msdn.com/kcwalina/archive/2004/09/28/235232.aspx (or see here - http://peter.golde.org/2003/10/13.html#a16) In some ways, this would be just reflecting in IronPython this good design sense. One advantage of immutability is that it would make failures like the following much more obvious: >>> apt[0].X = 0 If value types were immutable this would throw. The exception message might give people enough information to get started tracking down the issue and modifying their code to work correctly. What are the problems with this approach? 1. C#/VB examples won't port very naturally to IronPython and the docs will need a section explaining the various workarounds to the fact that IronPython doesn't support this idiom. This isn't ideal, but I could easily live with this doc burden. 2. There's no way that I know of to make a value type 100% immutable without controlling its implementation. IronPython could block setting of fields and properties on value types, but there's no way to reliably detect and block all sets that came through methods. Just getting the properties and fields would probably cover 95% of the cases where people try to mutate a value type, but it seems pretty awkward to me to say that value types in IronPython are sort-of immutable unless there are mutating methods. The fact that this is what the C# compiler does for iteration variables is encouraging at least in that it's a precedent. 3. There might be things that are impossible to express with this restriction. I don't think that's true, particularly with the use of named parameters to initialize fields and properties in the value type's constructor. However, one of the principles of IronPython is that it should be able to use any CLS library and it's possible there's some weird library design with value types that wouldn't work if they were considered virtually immutable by IronPython. If we went down the immutable value type route, it would be interesting to look at different kinds of sugar that could be provided to make the impact on most programs less than it currently is. -Jim From firemoth at gmail.com Wed May 11 07:03:52 2005 From: firemoth at gmail.com (Timothy Fitz) Date: Wed, 11 May 2005 01:03:52 -0400 Subject: [IronPython] Array Access Problem In-Reply-To: <6C91A34F0BB48B40A86F1E146B7A049201C802CF@df-fido-msg.exchange.corp.microsoft.com> References: <6C91A34F0BB48B40A86F1E146B7A049201C802CF@df-fido-msg.exchange.corp.microsoft.com> Message-ID: <972ec5bd05051022036326a5c@mail.gmail.com> On 5/10/05, Jim Hugunin wrote: > >>> apt[0].X = 0 > If value types were immutable this would throw. The exception message > might give people enough information to get started tracking down the > issue and modifying their code to work correctly. I want to say this should be equivelant to apt[0] = Point(0, apt[0].Y) which would not break mutability issues. However this breaks with the current python trend (tuples could provide this functionality, but don't). To me, making apt[0].X = 0 require an explicitly new object is a almost a showstopper. Are there any other purely reference semantic languages on the CLI? Or are we treading on new ground? From jimhug at exchange.microsoft.com Wed May 11 07:26:59 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Tue, 10 May 2005 22:26:59 -0700 Subject: [IronPython] Array Access Problem Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201C80578@df-fido-msg.exchange.corp.microsoft.com> Timothy Fitz wrote: > On 5/10/05, Jim Hugunin wrote: > > >>> apt[0].X = 0 > > If value types were immutable this would throw. The exception message > > might give people enough information to get started tracking down the > > issue and modifying their code to work correctly. > > I want to say this should be equivelant to > apt[0] = Point(0, apt[0].Y) > which would not break mutability issues. However this breaks with the > current python trend (tuples could provide this functionality, but > don't). Because of the way that value types work, there's no difference between the results of apt[0].X = 0 and apt[0] = Point(0, apt[0].Y) The big question is how important it is that both of the following are equivalent. apt[0].X = 0 and tmp = apt[0]; tmp.X = 0 These two are different for value types in C# and VB. However, it's pretty weird to think about them being different in Python. It's easier for me to imagine supporting the version on the left if the version on the right will consistently throw claiming that tmp is immutable. This would still be confusing to people, but at least it would be very explicit. > To me, making apt[0].X = 0 require an explicitly new object is a > almost a showstopper. I'm not willing to go that far. It's a pretty rare case that you need to work with arrays of mutable value types with using CLS libraries. And the beauty of Python is that it's a great language for writing little helper routines to make the painful painless when needed. > Are there any other purely reference semantic > languages on the CLI? Or are we treading on new ground? That's a great question. I'm pretty sure that both J# and Jscript from MS have pure reference semantics and I'm sure there must be many other languages with this dilemma. I don't know what solutions other people have come up with. Does anyone else out there know? Has someone tried this in J# or Jscript to see how arrays of value types behave? Thanks - Jim From nicksjacobson at hotmail.com Wed May 11 08:08:20 2005 From: nicksjacobson at hotmail.com (Nick Jacobson) Date: Wed, 11 May 2005 06:08:20 +0000 Subject: [IronPython] 'out' parameters Message-ID: How will IronPython deal with functions that, in C#, use an 'out' variable? For example, in Microsoft.DirectX.Direct3D, this function exists: public bool CheckCooperativeLevel(out int result); If I call this from IronPython, there's no way that the value of result would be modified, right? But it needs to be changed within the function CheckCooperativeLevel, and I need to get the result back! Thanks, --Nick _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From richard.hsu at gmail.com Wed May 11 12:56:19 2005 From: richard.hsu at gmail.com (richard hsu) Date: Wed, 11 May 2005 16:26:19 +0530 Subject: [IronPython] Road Map for IronPython Message-ID: Hi All, Is there any published Road Map for IronPython ? Will it be fully CLI compliant ? I understand that using Enum type as bit field is not currently supported and will be done for v0.7.5 release. Similarly, what about other features that we have in C# ? Any document available which generally sums up IronPython's ambitions in the .NET world. Something like the blog entries of Stan Lippman and Herb Sutter regarding C++/CLI will do good for IronPython users like me. Regards, Richard. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martmaly at exchange.microsoft.com Wed May 11 17:01:08 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Wed, 11 May 2005 08:01:08 -0700 Subject: [IronPython] 'out' parameters Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701D9035A@df-chewy-msg.exchange.corp.microsoft.com> The return value and output parameters (if they are in total more than one) are returned as tuple: namespace N { public class C { public static int M(out int i, out int j, out int k) { i = 20; j = 30; k = 40; return 10; } } } Python: i = C.M() print i (10, 20, 30, 40) If there is just one output of the function (i.e. void function with one out parameter), the value comes back as a function return value. Martin -----Original Message----- From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Nick Jacobson Sent: Tuesday, May 10, 2005 11:08 PM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] 'out' parameters How will IronPython deal with functions that, in C#, use an 'out' variable? For example, in Microsoft.DirectX.Direct3D, this function exists: public bool CheckCooperativeLevel(out int result); If I call this from IronPython, there's no way that the value of result would be modified, right? But it needs to be changed within the function CheckCooperativeLevel, and I need to get the result back! Thanks, --Nick From jimhug at exchange.microsoft.com Wed May 11 18:18:54 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Wed, 11 May 2005 09:18:54 -0700 Subject: [IronPython] 'out' parameters Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201C805FF@df-fido-msg.exchange.corp.microsoft.com> Martin's response is right, but I'm afraid that the best way to use these return values might not be obvious to everyone. Python's tuple packing and unpacking operations are often used for multiple return values in standard Python libraries and IronPython should feel the same way. Here's how these calls should look in IronPython: ret, result = CheckCooperativeLevel() m, i, j, k = C.M() And for completeness, I'll add that 'ref' parameters are both passed to the function and returned as an additional return value. -Jim Martin Maly wrote: > The return value and output parameters (if they are in total more than > one) are returned as tuple: > > namespace N { > public class C { > public static int M(out int i, out int j, out int k) { > i = 20; > j = 30; > k = 40; > return 10; > } > } > } > > Python: > i = C.M() > print i > > (10, 20, 30, 40) > > If there is just one output of the function (i.e. void function with one > out parameter), the value comes back as a function return value. > > Martin > > -----Original Message----- > From: users-ironpython.com-bounces at lists.ironpython.com > [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of > Nick Jacobson > Sent: Tuesday, May 10, 2005 11:08 PM > To: users-ironpython.com at lists.ironpython.com > Subject: [IronPython] 'out' parameters > > How will IronPython deal with functions that, in C#, use an 'out' > variable? > > For example, in Microsoft.DirectX.Direct3D, this function exists: > > public bool CheckCooperativeLevel(out int result); > > > If I call this from IronPython, there's no way that the value of result > would be modified, right? But it needs to be changed within the > function > CheckCooperativeLevel, and I need to get the result back! > > Thanks, > > --Nick > > _______________________________________________ > 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 May 11 18:53:40 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Wed, 11 May 2005 09:53:40 -0700 Subject: [IronPython] Road Map for IronPython Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201C8062A@df-fido-msg.exchange.corp.microsoft.com> There's no published road map, but that's a frequent request and we need to do something about that soon. The plan is for IronPython to be fully CLI compatible which means that it should run on the Common Language Infrastructure. I think that you're asking about compliance with the Common Language Specification (CLS). IronPython absolutely plans to be a fully compliant CLS consumer which means that any well-designed library should be usable from IronPython. The only two bugs that I know about here today are: 1. enum's as bit fields not implemented 2. no way to call a method whose name is a Python keyword These will certainly be fixed and I'm sure that there are other bugs as a CLS consumer that IronPython will need to fix. There's another level of CLS compliance called CLS extender. IronPython supports some of this today. My hope is that we'll be a fully compliant CLS extender by the 1.0 release, but there are many more open questions here that we'll have to answer as we go along. -Jim ________________________________________ From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of richard hsu Sent: Wednesday, May 11, 2005 3:56 AM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Road Map for IronPython Hi All, ? Is there any published Road Map for IronPython ? Will it be fully CLI compliant ? ? I understand that using Enum type as bit field is not currently supported and will be done for v0.7.5 release. Similarly, what about other features that we have in C# ? Any document available which generally sums up IronPython's ambitions in the .NET world. Something like the blog entries of Stan Lippman and Herb Sutter regarding C++/CLI will do good for IronPython users like me. ? Regards, Richard. ? From kfarmer at thuban.org Wed May 11 19:28:04 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 11 May 2005 10:28:04 -0700 Subject: [IronPython] Road Map for IronPython Message-ID: I think part of the question involved time? eg, 1.0 = next 6 months, next year, ... Incidentally, does anyone here have an idea of the difficulty involved in creating a language module for VS? Being able to create a .proj, have access to intellisense, etc would be good for 3rd-party languages in general. ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Jim Hugunin Sent: Wed 5/11/2005 9:53 AM There's no published road map, but that's a frequent request and we need to do something about that soon. -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3749 bytes Desc: not available URL: From nicksjacobson at hotmail.com Wed May 11 20:23:21 2005 From: nicksjacobson at hotmail.com (Nick Jacobson) Date: Wed, 11 May 2005 18:23:21 +0000 Subject: [IronPython] Re: 'out' parameters Message-ID: Jim and Martin, Thanks for the reply, and it makes sense :) Unfortunately, a call to CheckCooperativeLevel() returns True, not a tuple. This is probably because there are two overloaded CheckCooperativeLevel methods in the Device class in the Microsoft.DirectX.Direct3D namespace. They are: public bool CheckCooperativeLevel(); public bool CheckCooperativeLevel(out int result); IronPython has no way of knowing I want the second and not the first. --Nick Jim wrote: << Martin's response is right, but I'm afraid that the best way to use these return values might not be obvious to everyone. Python's tuple packing and unpacking operations are often used for multiple return values in standard Python libraries and IronPython should feel the same way. Here's how these calls should look in IronPython: ret, result = CheckCooperativeLevel() m, i, j, k = C.M() And for completeness, I'll add that 'ref' parameters are both passed to the function and returned as an additional return value. -Jim >> Martin Maly wrote: >The return value and output parameters (if they are in total more than >one) are returned as tuple: > >namespace N { > public class C { > public static int M(out int i, out int j, out int k) { > i = 20; > j = 30; > k = 40; > return 10; > } > } >} > >Python: >i = C.M() >print i > >(10, 20, 30, 40) > >If there is just one output of the function (i.e. void function with one >out parameter), the value comes back as a function return value. > >Martin > >-----Original Message----- >From: users-ironpython.com-bounces at lists.ironpython.com >[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of >Nick Jacobson >Sent: Tuesday, May 10, 2005 11:08 PM >To: users-ironpython.com at lists.ironpython.com >Subject: [IronPython] 'out' parameters > >How will IronPython deal with functions that, in C#, use an 'out' >variable? > >For example, in Microsoft.DirectX.Direct3D, this function exists: > >public bool CheckCooperativeLevel(out int result); > > >If I call this from IronPython, there's no way that the value of result >would be modified, right? But it needs to be changed within the >function >CheckCooperativeLevel, and I need to get the result back! > >Thanks, > >--Nick > >_______________________________________________ >users-ironpython.com mailing list >users-ironpython.com at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee? Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From martmaly at exchange.microsoft.com Wed May 11 22:19:53 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Wed, 11 May 2005 13:19:53 -0700 Subject: [IronPython] Re: 'out' parameters Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701D9050B@df-chewy-msg.exchange.corp.microsoft.com> Nick, This is a very tricky case. Jim and I just discussed it and while we want to provide good solution to this case, it may take some time to come up with the right way to solve the problem because on syntactic level there is really no way to distinguish between the two methods. If you need short-term workaround solution (and I am fully aware that this is neither pretty nor it is very pythonic thing to do), you can write snippet in C# that will help you distinguish the methods. Something like: using Microsoft.DirectX.Direct3D; static class Call { static bool CheckCoopLevelOut(Device _this, out int result) { return _this.CheckCooperativeLevel(out result); } static bool CheckCoopLevel(Device _this) { return _this.CheckCooperativeLevel(); } } And call from Python: boolReturn, intResult = Call.CheckCoopLevelOut(device) boolReturn = Call.CheckCoopLevel(device) As I said, it is not pretty, but if it is blocking you from making progress (and finding other great bugs like this one) it may help. Do you want to file this as a bug on GotDotNet? Thanks and I hope this helps Martin > Nick Jacobson Wrote: > > Thanks for the reply, and it makes sense :) > > Unfortunately, a call to CheckCooperativeLevel() returns True, not a > tuple. > This is probably because there are two overloaded CheckCooperativeLevel > methods in the Device class in the Microsoft.DirectX.Direct3D namespace. > They are: > > public bool CheckCooperativeLevel(); > public bool CheckCooperativeLevel(out int result); > > IronPython has no way of knowing I want the second and not the first. > > --Nick From drew at astro.pas.rochester.edu Wed May 11 22:53:54 2005 From: drew at astro.pas.rochester.edu (Drew Moore) Date: Wed, 11 May 2005 16:53:54 -0400 Subject: [IronPython] Array Access Problem In-Reply-To: <6C91A34F0BB48B40A86F1E146B7A049201C80578@df-fido-msg.exchange.corp.microsoft.com> References: <6C91A34F0BB48B40A86F1E146B7A049201C80578@df-fido-msg.exchange.corp.microsoft.com> Message-ID: <428270E2.8070906@astro.pas.rochester.edu> Jim Hugunin wrote: > >Because of the way that value types work, there's no difference between >the results of > apt[0].X = 0 and apt[0] = Point(0, apt[0].Y) > >The big question is how important it is that both of the following are >equivalent. > apt[0].X = 0 and tmp = apt[0]; tmp.X = 0 > > Just curious, maybe I'm off base... Is concurrency a concern here? Can instances of value types be shared between threads? (Perhaps different languages?) If so, what if another thread is concurrently modifying a different member of the underlying struct? If the client code 'just changes one attribute', but in actuality the entire structure gets written back, it may make for some very hard-to-pin-down bugs. (if this might happen, maybe immutable value types aren't so bad.) Drew From jimhug at exchange.microsoft.com Wed May 11 23:34:07 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Wed, 11 May 2005 14:34:07 -0700 Subject: [IronPython] Array Access Problem Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201C807B9@df-fido-msg.exchange.corp.microsoft.com> Drew Moore wrote: > Jim Hugunin wrote: > > > >Because of the way that value types work, there's no difference between > >the results of > > apt[0].X = 0 and apt[0] = Point(0, apt[0].Y) > > > >The big question is how important it is that both of the following are > >equivalent. > > apt[0].X = 0 and tmp = apt[0]; tmp.X = 0 > > > Just curious, maybe I'm off base... > Is concurrency a concern here? The answer to this question is almost always yes no matter what the context ;-) > Can instances of value types be shared between threads? (Perhaps > different languages?) There aren't really instances of value types. That's part of the problem. Value types are parts of other instances - either items in an array or inlined fields in classes. The things that hold value types can be shared between threads and languages. > If so, what if another thread is concurrently modifying a different > member of the underlying struct? This is a good point. In that case there is a potential difference between my two examples above. The one on the left can only change the X part of the point, but the one on the right could in theory overwrite another thread's changes to the Y part of the point. > If the client code 'just changes one attribute', but in actuality the > entire structure gets written back, it may make for some very > hard-to-pin-down bugs. > (if this might happen, maybe immutable value types aren't so bad.) I don't see this as too much of a problem. If IronPython supports apt[0].X=0, then that will only be implemented in such a way that just the X part is modified. If we decided to require apt[0]=Point(0,apt[0].Y) then it should be pretty clear to the programmer that they're replacing both fields of the point simultaneously. I just tried this in J# to see if there was a clever idea to steal. J# behaves just like the current IronPython does with value types: Form f = new Form(); System.out.println(f.get_ClientSize()); f.get_ClientSize().set_Height(10); System.out.println(f.get_ClientSize()); f.set_ClientSize(new Size(100, 100)); System.out.println(f.get_ClientSize()); {Width=292, Height=266} <-- starting size {Width=292, Height=266} <-- height unchanged by set_Height {Width=100, Height=100} <-- changed by setting to new Size object -Jim From nicksjacobson at hotmail.com Wed May 11 23:43:04 2005 From: nicksjacobson at hotmail.com (Nick Jacobson) Date: Wed, 11 May 2005 21:43:04 +0000 Subject: [IronPython] Re: 'out' parameters Message-ID: Martin, I appreciate you giving this some thought. I can't think of an elegant solution either.. I found a method called TestCooperativeLevel that doesn't use an 'out' parameter to return the device's status. Instead, it throws a different Exception based on the device's status. Therefore it makes a good workaround. Also, I filed a bug report for this problem (bug #104). Thanks again for your help. --Nick Martin wrote: << Nick, This is a very tricky case. Jim and I just discussed it and while we want to provide good solution to this case, it may take some time to come up with the right way to solve the problem because on syntactic level there is really no way to distinguish between the two methods. If you need short-term workaround solution (and I am fully aware that this is neither pretty nor it is very pythonic thing to do), you can write snippet in C# that will help you distinguish the methods. Something like: using Microsoft.DirectX.Direct3D; static class Call { static bool CheckCoopLevelOut(Device _this, out int result) { return _this.CheckCooperativeLevel(out result); } static bool CheckCoopLevel(Device _this) { return _this.CheckCooperativeLevel(); } } And call from Python: boolReturn, intResult = Call.CheckCoopLevelOut(device) boolReturn = Call.CheckCoopLevel(device) As I said, it is not pretty, but if it is blocking you from making progress (and finding other great bugs like this one) it may help. Do you want to file this as a bug on GotDotNet? Thanks and I hope this helps Martin >> _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From kfarmer at thuban.org Thu May 12 00:54:08 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 11 May 2005 15:54:08 -0700 Subject: [IronPython] Array Access Problem Message-ID: In the case of multi-threaded use, shouldn't valuetype modifications be locked to prevent simultaneous writes? If so, couldn't IronPython encapsulate the change in a lock block in the background? ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Jim Hugunin Sent: Wed 5/11/2005 2:34 PM To: Discussion of IronPython Subject: RE: [IronPython] Array Access Problem > If so, what if another thread is concurrently modifying a different > member of the underlying struct? This is a good point. In that case there is a potential difference between my two examples above. The one on the left can only change the X part of the point, but the one on the right could in theory overwrite another thread's changes to the Y part of the point. -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3770 bytes Desc: not available URL: From kfarmer at thuban.org Thu May 12 01:03:48 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 11 May 2005 16:03:48 -0700 Subject: [IronPython] Array Access Problem Message-ID: I guess not.. lock protects reference types ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Keith J. Farmer Sent: Wed 5/11/2005 3:54 PM To: Discussion of IronPython Subject: RE: [IronPython] Array Access Problem In the case of multi-threaded use, shouldn't valuetype modifications be locked to prevent simultaneous writes? If so, couldn't IronPython encapsulate the change in a lock block in the background? ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Jim Hugunin Sent: Wed 5/11/2005 2:34 PM To: Discussion of IronPython Subject: RE: [IronPython] Array Access Problem > If so, what if another thread is concurrently modifying a different > member of the underlying struct? This is a good point. In that case there is a potential difference between my two examples above. The one on the left can only change the X part of the point, but the one on the right could in theory overwrite another thread's changes to the Y part of the point. -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 4058 bytes Desc: not available URL: From ironpython at bobs.org Thu May 12 04:51:17 2005 From: ironpython at bobs.org (Bob Arnson) Date: Wed, 11 May 2005 19:51:17 -0700 Subject: [IronPython] Road Map for IronPython In-Reply-To: Message-ID: <20050512025109.64E0917511A@merry.dreamhost.com> Language services are in the Visual Studio SDK realm (formerly VSIP SDK). There's a managed library for creating them. But it's not a do-it-in-a-weekend project to fully support a new language in Visual Studio. _____ 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, 11 May, 2005 10:28 To: Discussion of IronPython Subject: RE: [IronPython] Road Map for IronPython I think part of the question involved time? eg, 1.0 = next 6 months, next year, ... Incidentally, does anyone here have an idea of the difficulty involved in creating a language module for VS? Being able to create a .proj, have access to intellisense, etc would be good for 3rd-party languages in general. _____ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Jim Hugunin Sent: Wed 5/11/2005 9:53 AM There's no published road map, but that's a frequent request and we need to do something about that soon. -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3458 bytes Desc: not available URL: From kfarmer at thuban.org Thu May 12 05:31:06 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 11 May 2005 20:31:06 -0700 Subject: [IronPython] Road Map for IronPython Message-ID: I wouldn't expect it to be. But would it be a do-it-in-a month project, or a do-it-in-a-year-with-help project? ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Bob Arnson Sent: Wednesday, May 11, 2005 7:51 PM To: 'Discussion of IronPython' Subject: RE: [IronPython] Road Map for IronPython Language services are in the Visual Studio SDK realm (formerly VSIP SDK). There's a managed library for creating them. But it's not a do-it-in-a-weekend project to fully support a new language in Visual Studio. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ironpython at bobs.org Thu May 12 06:52:35 2005 From: ironpython at bobs.org (Bob Arnson) Date: Wed, 11 May 2005 21:52:35 -0700 Subject: [IronPython] Road Map for IronPython In-Reply-To: Message-ID: <20050512045226.4CD7317511A@merry.dreamhost.com> Closer to the former. Obviously, it's a highly iterative project, so releases can easily build up functionality in whatever order is important. Python projects with syntax highlighting would be easy. IntelliSense is harder, mostly because of Python's dynamic typing, not VS itself. I'm not sure what's involved with a debugger, though it's a lot easier to hook up a managed language into the existing managed debugger (than wiring up a custom native debugger). Build support would be writing an MSBuild task, once there's a compiler. http://msdn.microsoft.com/vstudio/extend/ is the SDK home page. You have to register to download it, but it's free to do so. Sometime soon there will be a documentation update my team did, which contains a bunch of updated topics on managed language services. _____ 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, 11 May, 2005 20:31 To: Discussion of IronPython Subject: RE: [IronPython] Road Map for IronPython I wouldn't expect it to be. But would it be a do-it-in-a month project, or a do-it-in-a-year-with-help project? _____ From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Bob Arnson Sent: Wednesday, May 11, 2005 7:51 PM To: 'Discussion of IronPython' Subject: RE: [IronPython] Road Map for IronPython Language services are in the Visual Studio SDK realm (formerly VSIP SDK). There's a managed library for creating them. But it's not a do-it-in-a-weekend project to fully support a new language in Visual Studio. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisan at gmail.com Thu May 12 07:08:09 2005 From: chrisan at gmail.com (Chris Anderson) Date: Wed, 11 May 2005 22:08:09 -0700 Subject: [IronPython] IronPython.Objects.List doesn't support GetHashCode() Message-ID: <3f4711f505051122088c8b1fd@mail.gmail.com> Is there any special reason why this is the case? The code currently reads: public override int GetHashCode() { throw Ops.TypeError("list object is unhashable"); } So it's obviously intentional? however, I'm trying to use a native Python list as a data source for UI binding, and the collection needs to support GetHashCode? Is there any harm in implementing this method to just return the object identity hash? (similiar issue is true for SyncRoot on List also) From firemoth at gmail.com Thu May 12 15:13:12 2005 From: firemoth at gmail.com (Timothy Fitz) Date: Thu, 12 May 2005 09:13:12 -0400 Subject: [IronPython] IronPython.Objects.List doesn't support GetHashCode() In-Reply-To: <3f4711f505051122088c8b1fd@mail.gmail.com> References: <3f4711f505051122088c8b1fd@mail.gmail.com> Message-ID: <972ec5bd050512061345219761@mail.gmail.com> On 5/12/05, Chris Anderson wrote: > Is there any special reason why this is the case? The code currently reads: > > public override int GetHashCode() { > throw Ops.TypeError("list object is unhashable"); > } > > So it's obviously intentional? however, I'm trying to use a native > Python list as a data source for UI binding, and the collection needs > to support GetHashCode? Is there any harm in implementing this method > to just return the object identity hash? Yes, there is harm in it. Try this in python hash([]) and you'll get the same TypeError. The reason is because lists shouldn't be hashed. List comparison is based on the items inside a list, not the instance of the list itself. For instance: from copy import deepcopy A = [1,2] B = deepcopy(A) assert A == B assert id(A) != id(B) Now if we were to generate a hash value from the contents of the list, which is how tuples work, this hash would become invalid if the list were mutated, which would cause tremendous problems for dictionaries. If we were to generate hash values from the id of a list, A and B, which are equivelant, would be hashed to seperate locations. This breaks the invariant that if A == B: d[A] = True; assert d[B]. In general, mutable objects should not provide hashing functions in python. If only it were that simple, The CLI library's arrays do provide GetHashCode. The difference here is that python provides two functions, id and hash. Hash is overridable by the class that you pass it, through the __hash__ member. id is provided by the implementation and guarantees simply that it will return a unique identifier for every object. C# does not have any analogue to id*, but instead provides GetHashCode for all objects. So the question is how do we resolve the difference? I'm not sure how useful hashing lists is, but from pure python one should be able to do this class T(list): __hash__ = id And this allows instances of T to be hashed, and instances of T are exactly like lists. In general when I need to do something like this, I use a subclass of dictionary that hashes the id of all objects, not just lists. Unfortunately I don't see a simple way to resolve this conflict when you're forced to use someone elses hash table. Timothy Fitz * = Sortof, turns out Object.GetHashCode performs the same as id although it's not guaranteed to and shouldn't be even remotely relied upon. From chrisan at gmail.com Thu May 12 15:26:49 2005 From: chrisan at gmail.com (Chris Anderson) Date: Thu, 12 May 2005 06:26:49 -0700 Subject: [IronPython] IronPython.Objects.List doesn't support GetHashCode() In-Reply-To: <972ec5bd050512061345219761@mail.gmail.com> References: <3f4711f505051122088c8b1fd@mail.gmail.com> <972ec5bd050512061345219761@mail.gmail.com> Message-ID: <3f4711f5050512062629435283@mail.gmail.com> I'll be the first to admit that I'm not the master of language design or hashtables... My understanding was that the hash of an object needed to be consistent over the life of the object (therefore providing a way for a hashtable to find the bucket for it) and relatively unique (basically, that given a number of objects they don't all hash to the same thing). I believe that simply returning "1" from GetHashCode() would work just fine - however it would mean that hashtables would effectively become linked lists or linear arrays (depending on their implementation). From that model, returning the base CLR GetHashCode implementation for object seems completely reasonable... The issue i'm running into is that internal data binding constructs in Avalon require that we push the data source for lists into a hashtable (so that we can manage concurrency in a reasonably performant fashion)... without hash support, i can never bind to lists or dictionaries from python. On 5/12/05, Timothy Fitz wrote: > On 5/12/05, Chris Anderson wrote: > Yes, there is harm in it. Try this in python hash([]) and you'll get > the same TypeError. The reason is because lists shouldn't be hashed. > List comparison is based on the items inside a list, not the instance > of the list itself. For instance: > > from copy import deepcopy > A = [1,2] > B = deepcopy(A) > assert A == B > assert id(A) != id(B) > > In general, mutable objects should not provide hashing functions in python. -------------- next part -------------- An HTML attachment was scrubbed... URL: From firemoth at gmail.com Thu May 12 15:44:40 2005 From: firemoth at gmail.com (Timothy Fitz) Date: Thu, 12 May 2005 09:44:40 -0400 Subject: [IronPython] IronPython.Objects.List doesn't support GetHashCode() In-Reply-To: <3f4711f5050512062629435283@mail.gmail.com> References: <3f4711f505051122088c8b1fd@mail.gmail.com> <972ec5bd050512061345219761@mail.gmail.com> <3f4711f5050512062629435283@mail.gmail.com> Message-ID: <972ec5bd05051206446db09fbc@mail.gmail.com> On 5/12/05, Chris Anderson wrote: > I believe that simply returning "1" from GetHashCode() would work just fine > - however it would mean that hashtables would effectively become linked > lists or linear arrays (depending on their implementation). From that model, > returning the base CLR GetHashCode implementation for object seems > completely reasonable... Returning 1 would work, yes. Returning Object.GetHashCode won't. I don't think suprising people with hash tables returning in linear time is good, but people coming from other CLI languages will expect it. > The issue i'm running into is that internal data binding constructs in > Avalon require that we push the data source for lists into a hashtable (so > that we can manage concurrency in a reasonably performant fashion)... > without hash support, i can never bind to lists or dictionaries from python. Not directly, but subclassing list and dict would work. class HashableList: def __hash__(self): return id(self) or clash HashableList: def __hash__(self): return 1 To adapt simply: HashableList(MyExistingList) Disclaimer, I'm not sure if this works in IronPython today. From chrisan at gmail.com Thu May 12 18:39:55 2005 From: chrisan at gmail.com (Chris Anderson) Date: Thu, 12 May 2005 09:39:55 -0700 Subject: [IronPython] IronPython.Objects.List doesn't support GetHashCode() In-Reply-To: <972ec5bd05051206446db09fbc@mail.gmail.com> References: <3f4711f505051122088c8b1fd@mail.gmail.com> <972ec5bd050512061345219761@mail.gmail.com> <3f4711f5050512062629435283@mail.gmail.com> <972ec5bd05051206446db09fbc@mail.gmail.com> Message-ID: <3f4711f5050512093919f6682d@mail.gmail.com> The problem with this model is that it requires you to subclass and use a special type. My goal is to enable simple usage in binding scenarios: _list.ItemsSource = range(5) This means that every list/dictionary/touple needs to support ICustomTypeDescriptor and GetHashCode/SyncRoot... The ICD requirement for object/dict is pretty solid, but I'll follow up with our databinding team to see if we can gracefully support non-hash supporting objects... I'm unclear as to why returning the default CLR implementation of GetHashCode would be bad? It's unique to the life of the object and never changes... it won't be based on the containing data in the list, but it also shouldn't break any hashtable... no? On 5/12/05, Timothy Fitz wrote: > > Not directly, but subclassing list and dict would work. > > class HashableList: > def __hash__(self): > return id(self) > > or > > clash HashableList: > def __hash__(self): > return 1 > > To adapt simply: > > HashableList(MyExistingList) > > Disclaimer, I'm not sure if this works in IronPython today. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimhug at exchange.microsoft.com Thu May 12 19:22:10 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Thu, 12 May 2005 10:22:10 -0700 Subject: [IronPython] IronPython.Objects.List doesn't support GetHashCode() Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201CF9011@df-fido-msg.exchange.corp.microsoft.com> SyncRoot should be supported on lists. This wasn't done only due to laziness on my part. GetHashCode is less clear. The property of GetHashCode that you're missing is that it must be consistent with Equals. This is required by both Python and the CLI. It's not possible to implement Python's notion of list equality and a correct GetHashCode at the same time. In Python, the standard design for collections is to make them compare equals based on the values they contain not on the identity of the objects. Consider the following: >>> a = [] >>> b = [] >>> a == b True >>> a is b False >>> a.append(1) >>> a == b False >>> b.append(1) >>> a == b True Lists compare equal when all of their members are equal. This is very useful behavior. If you want to test for reference equality, in Python you can always use 'is'. Because lists are mutable and yet compare equal based on value, the only legal hashcode would be a constant int. I think that Python wisely makes the design choice to throw in this case rather than turning dictionaries into linked lists. The standard CLI collections ignore their contents when testing for equality and compare based on reference equality. Because of this decision, they can default to the generic GetHashCode and Equals implementations. >>> from System.Collections import * >>> c = ArrayList() >>> d = ArrayList() >>> c == d False >>> c.Equals(d) False Personally, I think that the Python design rules are more useful for collection types because you can always fall back to using 'is' and an identity hashtable implementation when you want to check for object identity rather than object value. From what I understand of the purpose of your hashtables, I'd argue that they should clearly be identity based hashtables. These are quite easy to implement by providing a custom IEqualityComparer to IDictionary. It's about 10 lines of code. This is an interesting and subtle mismatch between the Python and CLI where I'm not sure what the best final solution is. I don't know if this is just a difference in philosophy in the design of Python's collections and the CLI collections or if there is a more clear distinction between the contract of GetHashCode and Python's __hash__. There are different ways to tackle this depending on the answer to that question. One option is to make GetHashCode and Equals on IronPython.Objects.List return CLI-style object versions, but then to provide two new Python-style methods that would provide the correct semantics from the IronPython side. Lots to think about - Jim ________________________________________ From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Chris Anderson Sent: Thursday, May 12, 2005 9:40 AM To: users-ironpython.com at lists.ironpython.com Subject: Re: [IronPython] IronPython.Objects.List doesn't support GetHashCode() The problem with this model is that it requires you to subclass and use a special type. My goal is to enable simple usage in binding scenarios: ? _list.ItemsSource = range(5) ? This means that every list/dictionary/touple needs to support ICustomTypeDescriptor and GetHashCode/SyncRoot... The ICD requirement for object/dict is pretty solid, but I'll follow up with our databinding team to see if we can gracefully support non-hash supporting objects... ? I'm unclear as to why returning the default CLR implementation of GetHashCode would be bad? It's unique to the life of the object and never changes... it won't be based on the containing data in the list, but it also shouldn't break any hashtable... no? ? On 5/12/05, Timothy Fitz wrote: Not directly, but subclassing list and dict would work. class HashableList: def __hash__(self): ?? return id(self) or clash HashableList: def __hash__(self): ?? return 1 To adapt simply: HashableList(MyExistingList) Disclaimer, I'm not sure if this works in IronPython today. From chrisan at windows.microsoft.com Thu May 12 06:12:54 2005 From: chrisan at windows.microsoft.com (Chris Anderson (WINDOWS)) Date: Wed, 11 May 2005 21:12:54 -0700 Subject: [IronPython] IronPython.Objects.List doesn't support GetHashCode() Message-ID: Is there any special reason why this is the case? The code currently reads: public override int GetHashCode() { throw Ops.TypeError("list object is unhashable"); } So it's obviously intentional... however, I'm trying to use a native Python list as a data source for UI binding, and the collection needs to support GetHashCode? Is there any harm in implementing this method to just return the object identity hash? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisan at gmail.com Fri May 13 23:05:58 2005 From: chrisan at gmail.com (Chris Anderson) Date: Fri, 13 May 2005 14:05:58 -0700 Subject: [IronPython] System.RuntimeType Message-ID: <3f4711f5050513140531de3e22@mail.gmail.com> I'm trying to get a System.RuntimeType in a simple Python script... today if i use the "type" keyword, i get a Python type object... I really want the equivalent of C#'s typeof operator. Specifically I want to be able to access the GetProperties(), GetMethods(), and GetEvents() on the type object... also I need to access the Assembly for a type to do some searching... Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From johngos at microsoft.com Fri May 13 23:09:34 2005 From: johngos at microsoft.com (John Gossman) Date: Fri, 13 May 2005 14:09:34 -0700 Subject: [IronPython] System.RuntimeType Message-ID: <7B75DD93D78B6C4EAD2CB400F3C1F30506395E33@RED-MSG-51.redmond.corp.microsoft.com> element.GetType().GetProperties() element.GetType().Assembly ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Chris Anderson Sent: Friday, May 13, 2005 2:06 PM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] System.RuntimeType I'm trying to get a System.RuntimeType in a simple Python script... today if i use the "type" keyword, i get a Python type object... I really want the equivalent of C#'s typeof operator. Specifically I want to be able to access the GetProperties(), GetMethods(), and GetEvents() on the type object... also I need to access the Assembly for a type to do some searching... Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisan at gmail.com Fri May 13 23:22:38 2005 From: chrisan at gmail.com (Chris Anderson) Date: Fri, 13 May 2005 14:22:38 -0700 Subject: [IronPython] System.RuntimeType In-Reply-To: <7B75DD93D78B6C4EAD2CB400F3C1F30506395E33@RED-MSG-51.redmond.corp.microsoft.com> References: <7B75DD93D78B6C4EAD2CB400F3C1F30506395E33@RED-MSG-51.redmond.corp.microsoft.com> Message-ID: <3f4711f505051314224e2b1231@mail.gmail.com> How would I do it without an instance available... I basically just want the runtime type for a specific type, not based on an instance. On 5/13/05, John Gossman wrote: > > element.GetType().GetProperties() > element.GetType().Assembly > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johngos at microsoft.com Fri May 13 23:38:13 2005 From: johngos at microsoft.com (John Gossman) Date: Fri, 13 May 2005 14:38:13 -0700 Subject: [IronPython] System.RuntimeType Message-ID: <7B75DD93D78B6C4EAD2CB400F3C1F305063E94EB@RED-MSG-51.redmond.corp.microsoft.com> Sorry, Ops.object2type(Button) Ops.object2type(Button).Assembly etc. Should have realized what you meant. ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Chris Anderson Sent: Friday, May 13, 2005 2:23 PM To: users-ironpython.com at lists.ironpython.com Subject: Re: [IronPython] System.RuntimeType How would I do it without an instance available... I basically just want the runtime type for a specific type, not based on an instance. On 5/13/05, John Gossman wrote: element.GetType().GetProperties() element.GetType().Assembly -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglist.account at gmail.com Sun May 15 16:12:51 2005 From: mailinglist.account at gmail.com (Anthony Tarlano) Date: Sun, 15 May 2005 16:12:51 +0200 Subject: [IronPython] word Automation In-Reply-To: <427EF83A.3090708@free.fr> References: <427EF83A.3090708@free.fr> Message-ID: Hello, I finally found sometime this weekend to check out IronPython's support for the Office2003 PIA's. Final impression is that somethings work, but most didn't. Here's a link to the bugI opened showing a small amount of interaction with the word application class via the console. Anthony On 5/9/05, kbond wrote: > > Hello, > > First congratulation of all, thank you for the tremendous work that you > have already done. > I am looking forward the day where I will be able to translate all my MS > office automation in python scripts. > > Am I correct I say that iron python will allow it? > > So today I try to give it a try but unfortunatly withou success till now. > I am trying to translate this simple vb.net module to iron > python, is > there someone reading this list that can help me? > > the VB > > Imports word = Microsoft.Office.Interop.word > Module Module1 > > Sub Main() > Dim oWord As Word.ApplicationClass > > 'Start Word and open the document. > oWord = CreateObject("Word.Application") > oWord.Visible = True > oWord.Documents.Open("C:\tmp\Doc1.doc") > > 'Run the macros. > 'oWord.Run("DoKbTest") > 'oWord.Run("DoKbTestWithParameter", "Hello from VB .NET Client") > > 'Quit Word. > oWord.Quit() > System.Runtime.InteropServices.Marshal.ReleaseComObject(oWord) > oWord = Nothing > > End Sub > > End Module > > Iron Python > > import sys > sys.LoadAssemblyByName("Microsoft.Office.Interop.Word") > import Microsoft.Office.Interop.Word as wordApp > oWord = wordApp.ApplicationClass > > oWord = CreateObject("wordApp.Application") > oWord.Visible = True > oWord.Documents.Open("C:\tmp\Doc1.doc") > > oWord.Quit() > System.Runtime.InteropServices.Marshal.ReleaseComObject(oWord) > oWord = Nothing > > thank you > > _______________________________________________ > 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: From kirko at microsoft.com Sun May 15 18:27:31 2005 From: kirko at microsoft.com (Kirk Olynyk) Date: Sun, 15 May 2005 09:27:31 -0700 Subject: [IronPython] Trouble with Single's Message-ID: <310187D53C02434D8F2CF4CD951B734102D6C61C@RED-MSG-60.redmond.corp.microsoft.com> It seems that IronPython is comfortable with double data types but not single's. To get around this I am forced to to a Convert.ToDouble(singleThingy) every time that I find one. Is there a plan to fix this? import sys sys.LoadAssemblyByName("System") sys.LoadAssemblyByName("System.Drawing") from System import * from System.Drawing import * pointF = PointF(1,1) # so far so good X = pointF.X + 1 # boom -------------- next part -------------- An HTML attachment was scrubbed... URL: From martmaly at exchange.microsoft.com Sun May 15 18:25:42 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Sun, 15 May 2005 09:25:42 -0700 Subject: [IronPython] Trouble with Single's Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701E34DAE@df-chewy-msg.exchange.corp.microsoft.com> Yes, there is plan to fix this. In some cases the Single type already works, but there are places where the support is still missing. Martin ________________________________________ From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Kirk Olynyk Sent: Sunday, May 15, 2005 9:28 AM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Trouble with Single's It seems that IronPython is comfortable with double data types but not single's. To get around this I am forced to to a Convert.ToDouble(singleThingy) every time that I find one. Is there a plan to fix this? ? ? ? import sys ? sys.LoadAssemblyByName("System") sys.LoadAssemblyByName("System.Drawing") ? from System???????? import * from System.Drawing import * ? pointF = PointF(1,1)??? # so far so good X = pointF.X + 1??????? # boom ? From martmaly at exchange.microsoft.com Tue May 17 23:15:09 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Tue, 17 May 2005 14:15:09 -0700 Subject: [IronPython] IronPython 0.7.5 released Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701ED1064@df-chewy-msg.exchange.corp.microsoft.com> Hello IronPython community, Today we have released IronPython 0.7.5. The bugs we fixed for this release are: * Can't Open 2 or more IronPythonConsoles * File share error when opening the file for reading multiple times * Generate assembly in the same directory as the Python source * Can't OR flags together - note that to use bitwise operations on enums, the [Flags] attribute must be set on the enum * sorted() not implemented * Failed to sort list with mixed types * Remove nstr and zip2 from __builtins__ * Can't raise a long to an exponent * dir and __dict__ malfunction * Old class cannot be instantiated when passing parameters by name class A: def __init__(self, height=20, width=30): self.area = height * width a = A(width = 2) * Old style class cannot override __getattr__ * Initialization of the map using lambda is incorrect * Method lookup broken again - this was a regression in our dynamic method resolution code reported by Microsoft Research * PythonEngine Execute method runs only discreet statements There are several people we want thank for providing feedback and reporting bugs. Our thanks go to: luismg Nicholas Jacobson Flexibal Anthony Tarlano John Gossman Chris Anderson Erin Renshaw Sumit Basu Vincent Risi In the next 3 weeks I expect to spend a lot of time working on regression tests because I will be spending lot of time on the airplanes (first to Hawaii and then to Prague, Czech Republic) where I can dedicate good uninterrupted amount of time to it. Whether you can expect a release in the next 3 weeks depends on how much time Jim will be able to dedicate to IronPython code base with all the other responsibilities he has. We hope that you will find this release useful. 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=03238F44-D75F-4 E82-BDBB-6F6FDCA011F0&displaylang=en From martmaly at exchange.microsoft.com Tue May 17 23:27:14 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Tue, 17 May 2005 14:27:14 -0700 Subject: [IronPython] IronPython and standard Python libraries Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701ED1073@df-chewy-msg.exchange.corp.microsoft.com> Hello, After reading Anthony's email on CPython's standard libraries I tried to import the libraries using IronPython to see how well IronPython does just importing the libraries. Out of 182 modules that I tried to import 116 imported successfully (which does not unfortunately mean that they would also run correctly) and 66 of the 182 standard Python's library modules fail to import. The most frequent recurrent theme of the import failures was missing built-in modules (struct, exception, errno, ...) or unimplemented features. The detailed results are below. As for other testing efforts, I am currently making progress on getting the test_builtin run. With few modifications we can run the test and the failures also often point to missing modules (and of course, valid bugs). As I said in the release announcement email, I will be spending my IronPython time over the next weeks pretty much exclusively trying to improve our pass-rate for the regression tests and to fix as many of the problems reported by the standard libraries. I hope by the time I am back the picture will look much brighter. Thanks Martin Running aifc.py ... FAIL Running anydbm.py ... PASS Running asynchat.py ... FAIL Running asyncore.py ... FAIL Running atexit.py ... PASS Running audiodev.py ... PASS Running base64.py ... PASS Running BaseHTTPServer.py ... FAIL Running Bastion.py ... PASS Running bdb.py ... FAIL Running binhex.py ... FAIL Running bisect.py ... PASS Running calendar.py ... PASS Running cgi.py ... PASS Running CGIHTTPServer.py ... FAIL Running cgitb.py ... PASS Running chunk.py ... PASS Running cmd.py ... PASS Running code.py ... FAIL Running codecs.py ... FAIL Running codeop.py ... PASS Running colorsys.py ... PASS Running commands.py ... PASS Running compileall.py ... FAIL Running ConfigParser.py ... FAIL Running Cookie.py ... FAIL Running copy.py ... FAIL Running copy_reg.py ... PASS Running csv.py ... FAIL Running dbhash.py ... FAIL Running difflib.py ... PASS Running dircache.py ... PASS Running dis.py ... PASS Running doctest.py ... FAIL Running DocXMLRPCServer.py ... FAIL Running dumbdbm.py ... PASS Running dummy_thread.py ... PASS Running dummy_threading.py ... FAIL Running FCNTL.py ... PASS Running filecmp.py ... FAIL Running fileinput.py ... PASS Running fnmatch.py ... PASS Running formatter.py ... PASS Running fpformat.py ... PASS Running ftplib.py ... FAIL Running getopt.py ... PASS Running getpass.py ... PASS Running gettext.py ... FAIL Running glob.py ... PASS Running gopherlib.py ... PASS Running gzip.py ... FAIL Running heapq.py ... PASS Running hmac.py ... PASS Running htmlentitydefs.py ... PASS Running htmllib.py ... PASS Running HTMLParser.py ... FAIL Running httplib.py ... FAIL Running ihooks.py ... FAIL Running imaplib.py ... FAIL Running imghdr.py ... PASS Running imputil.py ... FAIL Running inspect.py ... PASS Running keyword.py ... PASS Running linecache.py ... PASS Running locale.py ... PASS Running macpath.py ... PASS Running macurl2path.py ... PASS Running mailbox.py ... PASS Running mailcap.py ... PASS Running markupbase.py ... PASS Running mhlib.py ... FAIL Running mimetools.py ... PASS Running mimetypes.py ... PASS Running MimeWriter.py ... PASS Running mimify.py ... FAIL Running modulefinder.py ... FAIL Running multifile.py ... PASS Running mutex.py ... PASS Running netrc.py ... PASS Running new.py ... PASS Running nntplib.py ... PASS Running ntpath.py ... PASS Running nturl2path.py ... PASS Running opcode.py ... PASS Running optparse.py ... PASS Running os.py ... PASS Running os2emxpath.py ... PASS Running pdb.py ... FAIL Running pickle.py ... PASS Running pickletools.py ... FAIL Running pipes.py ... PASS Running pkgutil.py ... PASS Running platform.py ... FAIL Running popen2.py ... PASS Running poplib.py ... PASS Running posixfile.py ... PASS Running posixpath.py ... PASS Running pprint.py ... FAIL Running pre.py ... FAIL Running profile.py ... FAIL Running pstats.py ... FAIL Running pty.py ... FAIL Running pyclbr.py ... FAIL Running pydoc.py ... PASS Running py_compile.py ... PASS Running Queue.py ... PASS Running quopri.py ... PASS Running random.py ... PASS Running re.py ... PASS Running regex_syntax.py ... PASS Running repr.py ... PASS Running rexec.py ... FAIL Running rfc822.py ... PASS Running rlcompleter.py ... FAIL Running robotparser.py ... PASS Running sched.py ... PASS Running sets.py ... PASS Running sgmllib.py ... PASS Running shelve.py ... PASS Running shlex.py ... PASS Running shutil.py ... PASS Running SimpleHTTPServer.py ... PASS Running SimpleXMLRPCServer.py ... FAIL Running site.py ... PASS Running smtpd.py ... FAIL Running smtplib.py ... FAIL Running sndhdr.py ... PASS Running socket.py ... PASS Running SocketServer.py ... FAIL Running sre.py ... FAIL Running sre_compile.py ... PASS Running sre_constants.py ... PASS Running sre_parse.py ... PASS Running stat.py ... PASS Running statcache.py ... PASS Running statvfs.py ... PASS Running string.py ... PASS Running StringIO.py ... PASS Running stringold.py ... PASS Running stringprep.py ... FAIL Running sunau.py ... PASS Running sunaudio.py ... PASS Running symbol.py ... FAIL Running symtable.py ... FAIL Running tabnanny.py ... FAIL Running tarfile.py ... FAIL Running telnetlib.py ... FAIL Running tempfile.py ... PASS Running TERMIOS.py ... PASS Running textwrap.py ... PASS Running this.py ... PASS Running threading.py ... PASS Running timeit.py ... FAIL Running toaiff.py ... PASS Running token.py ... PASS Running tokenize.py ... PASS Running trace.py ... FAIL Running traceback.py ... PASS Running tty.py ... FAIL Running types.py ... PASS Running tzparse.py ... FAIL Running unittest.py ... PASS Running urllib.py ... PASS Running urllib2.py ... FAIL Running urlparse.py ... PASS Running UserDict.py ... PASS Running UserList.py ... PASS Running UserString.py ... PASS Running uu.py ... PASS Running warnings.py ... PASS Running wave.py ... FAIL Running weakref.py ... FAIL Running webbrowser.py ... PASS Running whichdb.py ... FAIL Running whrandom.py ... FAIL Running xdrlib.py ... FAIL Running xmllib.py ... FAIL Running xmlrpclib.py ... PASS Running zipfile.py ... FAIL Running _strptime.py ... FAIL Running __future__.py ... PASS Running __phello__.foo.py ... FAIL ---------------------------------------- Tests ran: 182 Success: 116 Failure: 66 ---------------------------------------- From mailinglist.account at gmail.com Tue May 17 23:38:01 2005 From: mailinglist.account at gmail.com (Anthony Tarlano) Date: Tue, 17 May 2005 23:38:01 +0200 Subject: [IronPython] IronPython and standard Python libraries In-Reply-To: <1E1FC9DA1767ED44872F4E17AC17E8F701ED1073@df-chewy-msg.exchange.corp.microsoft.com> References: <1E1FC9DA1767ED44872F4E17AC17E8F701ED1073@df-chewy-msg.exchange.corp.microsoft.com> Message-ID: Martin, Great post! Keep up the good work and don't forget to also have some _fun_ in Hawaii and Prague (great beer and since I live in Munich you can take my word for it ;-) Safe trip! Anthony On 5/17/05, Martin Maly wrote: > > Hello, > > After reading Anthony's email on CPython's standard libraries I tried to > import the libraries using IronPython to see how well IronPython does > just importing the libraries. Out of 182 modules that I tried to import > 116 imported successfully (which does not unfortunately mean that they > would also run correctly) and 66 of the 182 standard Python's library > modules fail to import. The most frequent recurrent theme of the import > failures was missing > built-in modules (struct, exception, errno, ...) or unimplemented > features. The detailed results are below. > > As for other testing efforts, I am currently making progress on getting > the test_builtin run. With few modifications we can run the test and the > failures also often point to missing modules (and of course, valid > bugs). > > As I said in the release announcement email, I will be spending my > IronPython time over the next weeks pretty much exclusively trying to > improve our pass-rate for the regression tests and to fix as many of the > problems reported by the standard libraries. I hope by the time I am > back the picture will look much brighter. > > Thanks > Martin > > Running aifc.py ... FAIL > Running anydbm.py ... PASS > Running asynchat.py ... FAIL > Running asyncore.py ... FAIL > Running atexit.py ... PASS > Running audiodev.py ... PASS > Running base64.py ... PASS > Running BaseHTTPServer.py ... FAIL > Running Bastion.py ... PASS > Running bdb.py ... FAIL > Running binhex.py ... FAIL > Running bisect.py ... PASS > Running calendar.py ... PASS > Running cgi.py ... PASS > Running CGIHTTPServer.py ... FAIL > Running cgitb.py ... PASS > Running chunk.py ... PASS > Running cmd.py ... PASS > Running code.py ... FAIL > Running codecs.py ... FAIL > Running codeop.py ... PASS > Running colorsys.py ... PASS > Running commands.py ... PASS > Running compileall.py ... FAIL > Running ConfigParser.py ... FAIL > Running Cookie.py ... FAIL > Running copy.py ... FAIL > Running copy_reg.py ... PASS > Running csv.py ... FAIL > Running dbhash.py ... FAIL > Running difflib.py ... PASS > Running dircache.py ... PASS > Running dis.py ... PASS > Running doctest.py ... FAIL > Running DocXMLRPCServer.py ... FAIL > Running dumbdbm.py ... PASS > Running dummy_thread.py ... PASS > Running dummy_threading.py ... FAIL > Running FCNTL.py ... PASS > Running filecmp.py ... FAIL > Running fileinput.py ... PASS > Running fnmatch.py ... PASS > Running formatter.py ... PASS > Running fpformat.py ... PASS > Running ftplib.py ... FAIL > Running getopt.py ... PASS > Running getpass.py ... PASS > Running gettext.py ... FAIL > Running glob.py ... PASS > Running gopherlib.py ... PASS > Running gzip.py ... FAIL > Running heapq.py ... PASS > Running hmac.py ... PASS > Running htmlentitydefs.py ... PASS > Running htmllib.py ... PASS > Running HTMLParser.py ... FAIL > Running httplib.py ... FAIL > Running ihooks.py ... FAIL > Running imaplib.py ... FAIL > Running imghdr.py ... PASS > Running imputil.py ... FAIL > Running inspect.py ... PASS > Running keyword.py ... PASS > Running linecache.py ... PASS > Running locale.py ... PASS > Running macpath.py ... PASS > Running macurl2path.py ... PASS > Running mailbox.py ... PASS > Running mailcap.py ... PASS > Running markupbase.py ... PASS > Running mhlib.py ... FAIL > Running mimetools.py ... PASS > Running mimetypes.py ... PASS > Running MimeWriter.py ... PASS > Running mimify.py ... FAIL > Running modulefinder.py ... FAIL > Running multifile.py ... PASS > Running mutex.py ... PASS > Running netrc.py ... PASS > Running new.py ... PASS > Running nntplib.py ... PASS > Running ntpath.py ... PASS > Running nturl2path.py ... PASS > Running opcode.py ... PASS > Running optparse.py ... PASS > Running os.py ... PASS > Running os2emxpath.py ... PASS > Running pdb.py ... FAIL > Running pickle.py ... PASS > Running pickletools.py ... FAIL > Running pipes.py ... PASS > Running pkgutil.py ... PASS > Running platform.py ... FAIL > Running popen2.py ... PASS > Running poplib.py ... PASS > Running posixfile.py ... PASS > Running posixpath.py ... PASS > Running pprint.py ... FAIL > Running pre.py ... FAIL > Running profile.py ... FAIL > Running pstats.py ... FAIL > Running pty.py ... FAIL > Running pyclbr.py ... FAIL > Running pydoc.py ... PASS > Running py_compile.py ... PASS > Running Queue.py ... PASS > Running quopri.py ... PASS > Running random.py ... PASS > Running re.py ... PASS > Running regex_syntax.py ... PASS > Running repr.py ... PASS > Running rexec.py ... FAIL > Running rfc822.py ... PASS > Running rlcompleter.py ... FAIL > Running robotparser.py ... PASS > Running sched.py ... PASS > Running sets.py ... PASS > Running sgmllib.py ... PASS > Running shelve.py ... PASS > Running shlex.py ... PASS > Running shutil.py ... PASS > Running SimpleHTTPServer.py ... PASS > Running SimpleXMLRPCServer.py ... FAIL > Running site.py ... PASS > Running smtpd.py ... FAIL > Running smtplib.py ... FAIL > Running sndhdr.py ... PASS > Running socket.py ... PASS > Running SocketServer.py ... FAIL > Running sre.py ... FAIL > Running sre_compile.py ... PASS > Running sre_constants.py ... PASS > Running sre_parse.py ... PASS > Running stat.py ... PASS > Running statcache.py ... PASS > Running statvfs.py ... PASS > Running string.py ... PASS > Running StringIO.py ... PASS > Running stringold.py ... PASS > Running stringprep.py ... FAIL > Running sunau.py ... PASS > Running sunaudio.py ... PASS > Running symbol.py ... FAIL > Running symtable.py ... FAIL > Running tabnanny.py ... FAIL > Running tarfile.py ... FAIL > Running telnetlib.py ... FAIL > Running tempfile.py ... PASS > Running TERMIOS.py ... PASS > Running textwrap.py ... PASS > Running this.py ... PASS > Running threading.py ... PASS > Running timeit.py ... FAIL > Running toaiff.py ... PASS > Running token.py ... PASS > Running tokenize.py ... PASS > Running trace.py ... FAIL > Running traceback.py ... PASS > Running tty.py ... FAIL > Running types.py ... PASS > Running tzparse.py ... FAIL > Running unittest.py ... PASS > Running urllib.py ... PASS > Running urllib2.py ... FAIL > Running urlparse.py ... PASS > Running UserDict.py ... PASS > Running UserList.py ... PASS > Running UserString.py ... PASS > Running uu.py ... PASS > Running warnings.py ... PASS > Running wave.py ... FAIL > Running weakref.py ... FAIL > Running webbrowser.py ... PASS > Running whichdb.py ... FAIL > Running whrandom.py ... FAIL > Running xdrlib.py ... FAIL > Running xmllib.py ... FAIL > Running xmlrpclib.py ... PASS > Running zipfile.py ... FAIL > Running _strptime.py ... FAIL > Running __future__.py ... PASS > Running __phello__.foo.py ... FAIL > ---------------------------------------- > Tests ran: 182 > Success: 116 > Failure: 66 > ---------------------------------------- > _______________________________________________ > 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: From mailinglist.account at gmail.com Wed May 18 00:02:10 2005 From: mailinglist.account at gmail.com (Anthony Tarlano) Date: Wed, 18 May 2005 00:02:10 +0200 Subject: [IronPython] StringIO??? Message-ID: Martin, I think that while fixing the 'assemblies in the same directory' bug, a new critter may have been introduced... StringIO used to work in IP-0.7.4, now using IP.0.7.5 I see the following trackback.. IronPython 0.7.5 on .NET 2.0.40607.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO System.MissingMethodException: Method not found: 'Boolean System.Collections.Gen eric.IDictionary`2.TryGetValue(!0, !1 ByRef)'. at IronPython.Objects.Importer.TryGetExistingModule(String fullName, Object& ret) at IronPython.Objects.Importer.Import(PythonModule mod, String fullName, List from) at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) at input_0.Run(Frame frame) at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) at IronPython.Hosting.PythonEngine.RunInteractive() >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From martmaly at exchange.microsoft.com Wed May 18 00:07:56 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Tue, 17 May 2005 15:07:56 -0700 Subject: [IronPython] StringIO??? Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701ED10AD@df-chewy-msg.exchange.corp.microsoft.com> Strange that someone reported similar thing on GotDotNet forums. I believe that the cause is an old version of .Net. You need .Net 2.0 Beta 2 to run IronPython: IronPython 0.7.5 on .NET 2.0.50215.44 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO >>> You can get Beta 2 from here: http://www.microsoft.com/downloads/details.aspx?familyid=7ABD8C8F-287E-4 C7E-9A4A-A4ECFF40FC8E&displaylang=en ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Anthony Tarlano Sent: Tuesday, May 17, 2005 3:02 PM To: Discussion of IronPython Subject: [IronPython] StringIO??? Martin, I think that while fixing the 'assemblies in the same directory' bug, a new critter may have been introduced... StringIO used to work in IP-0.7.4, now using IP.0.7.5 I see the following trackback.. IronPython 0.7.5 on .NET 2.0.40607.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO System.MissingMethodException: Method not found: 'Boolean System.Collections.Gen eric.IDictionary`2.TryGetValue(!0, !1 ByRef)'. at IronPython.Objects.Importer.TryGetExistingModule(String fullName, Object& ret) at IronPython.Objects.Importer.Import(PythonModule mod, String fullName, List from) at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) at input_0.Run(Frame frame) at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) at IronPython.Hosting.PythonEngine.RunInteractive() >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From martmaly at exchange.microsoft.com Wed May 18 00:21:31 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Tue, 17 May 2005 15:21:31 -0700 Subject: [IronPython] word Automation Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701ED10C4@df-chewy-msg.exchange.corp.microsoft.com> With some code changes in IronPython (the changes are not in 0.7.5) I was able to get this working as far as making word app visible. However I was not yet successful with the Documents collection access. The object returned from the Documents property (and this was just a quick look, I am going to investiagate further when I am back) didn't have much type information with it so IronPython didn't know how to use it. Thanks for the bug and I hope to have some answers soon. Martin ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Anthony Tarlano Sent: Sunday, May 15, 2005 7:13 AM To: Discussion of IronPython Subject: Re: [IronPython] word Automation Hello, I finally found sometime this weekend to check out IronPython's support for the Office2003 PIA's. Final impression is that somethings work, but most didn't. Here's a link to the bug I opened showing a small amount of interaction with the word application class via the console. Anthony -------------- next part -------------- An HTML attachment was scrubbed... URL: From jddoty at gmail.com Wed May 18 01:36:18 2005 From: jddoty at gmail.com (John Doty) Date: Tue, 17 May 2005 16:36:18 -0700 Subject: [IronPython] IronPython and standard Python libraries In-Reply-To: <1E1FC9DA1767ED44872F4E17AC17E8F701ED1073@df-chewy-msg.exchange.corp.microsoft.com> References: <1E1FC9DA1767ED44872F4E17AC17E8F701ED1073@df-chewy-msg.exchange.corp.microsoft.com> Message-ID: On 5/17/05, Martin Maly wrote: > Hello, > > After reading Anthony's email on CPython's standard libraries I tried to > import the libraries using IronPython to see how well IronPython does > just importing the libraries. Out of 182 modules that I tried to import > 116 imported successfully (which does not unfortunately mean that they > would also run correctly) and 66 of the 182 standard Python's library > modules fail to import. The most frequent recurrent theme of the import > failures was missing > built-in modules (struct, exception, errno, ...) or unimplemented > features. The detailed results are below. ... > Running socket.py ... PASS ... This is interesting. Did somebody go and port _socket? If not, how did you run this test battery? (If so, looks like I wasted my Sunday afternoon...) thanks, john From martmaly at exchange.microsoft.com Wed May 18 01:55:22 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Tue, 17 May 2005 16:55:22 -0700 Subject: [IronPython] IronPython and standard Python libraries Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701ED115E@df-chewy-msg.exchange.corp.microsoft.com> As I said, what I did was merely import the files. I did not run them. That will be the next step. > -----Original Message----- > From: users-ironpython.com-bounces at lists.ironpython.com > [mailto:users-ironpython.com-bounces at lists.ironpython.com] On > Behalf Of John Doty > Sent: Tuesday, May 17, 2005 4:36 PM > To: Discussion of IronPython > Subject: Re: [IronPython] IronPython and standard Python libraries > > On 5/17/05, Martin Maly wrote: > > Hello, > > > > After reading Anthony's email on CPython's standard > libraries I tried > > to import the libraries using IronPython to see how well IronPython > > does just importing the libraries. Out of 182 modules that > I tried to > > import > > 116 imported successfully (which does not unfortunately > mean that they > > would also run correctly) and 66 of the 182 standard > Python's library > > modules fail to import. The most frequent recurrent theme of the > > import failures was missing built-in modules (struct, exception, > > errno, ...) or unimplemented features. The detailed results > are below. > ... > > Running socket.py ... PASS > ... > > This is interesting. Did somebody go and port _socket? If > not, how did you run this test battery? (If so, looks like I > wasted my Sunday > afternoon...) > > thanks, > john > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From jddoty at gmail.com Wed May 18 02:29:57 2005 From: jddoty at gmail.com (John Doty) Date: Tue, 17 May 2005 17:29:57 -0700 Subject: [IronPython] Double-Import Bug Message-ID: Is this bug known? In file foo.py: import bar At the IronPython console: >>> import foo [[ Giant exception stack trace ]] >>> import foo >>> That is, if a module fails to import, a second attempt to import does not throw an exception. I think this is because Importer.LoadFromSource puts the module into sys.modules before calling the import function, but does not remove it if the import function fails. thanks, john From curt at hagenlocher.org Wed May 18 04:42:01 2005 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 17 May 2005 19:42:01 -0700 Subject: [IronPython] Double-Import Bug Message-ID: <200505180242.TAA02675@dopey.hagenlocher.org> > Is this bug known? > That is, if a module fails to import, a second attempt to import does > not throw an exception. I think this is because > Importer.LoadFromSource puts the module into sys.modules before > calling the import function, but does not remove it if the import > function fails. I believe that this behavior is consistent with that of CPython. -- Curt Hagenlocher curt at hagenlocher.org From bob at redivi.com Wed May 18 04:03:42 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 17 May 2005 22:03:42 -0400 Subject: [IronPython] Double-Import Bug In-Reply-To: <200505180242.TAA02675@dopey.hagenlocher.org> References: <200505180242.TAA02675@dopey.hagenlocher.org> Message-ID: <89055516-BC03-416D-94D5-BA890E7878C5@redivi.com> On May 17, 2005, at 10:42 PM, Curt Hagenlocher wrote: >> Is this bug known? >> That is, if a module fails to import, a second attempt to import does >> not throw an exception. I think this is because >> Importer.LoadFromSource puts the module into sys.modules before >> calling the import function, but does not remove it if the import >> function fails. >> > > I believe that this behavior is consistent with that of CPython. Consistent with CPython < 2.4. The behavior has changed. -bob From alleykat at gmail.com Wed May 18 04:24:08 2005 From: alleykat at gmail.com (Travis Watkins) Date: Tue, 17 May 2005 21:24:08 -0500 Subject: [IronPython] Double-Import Bug In-Reply-To: <200505180242.TAA02675@dopey.hagenlocher.org> References: <200505180242.TAA02675@dopey.hagenlocher.org> Message-ID: On 5/17/05, Curt Hagenlocher wrote: > > Is this bug known? > > That is, if a module fails to import, a second attempt to import does > > not throw an exception. I think this is because > > Importer.LoadFromSource puts the module into sys.modules before > > calling the import function, but does not remove it if the import > > function fails. > > I believe that this behavior is consistent with that of CPython. > > -- > Curt Hagenlocher > curt at hagenlocher.org >From CPython: >>> import foo Traceback (most recent call last): File "", line 1, in ? File "foo.py", line 1, in ? import bar ImportError: No module named bar >>> import foo Traceback (most recent call last): File "", line 1, in ? File "foo.py", line 1, in ? import bar ImportError: No module named bar >>> -- Travis Watkins http://www.realistanew.com From curt at hagenlocher.org Wed May 18 06:23:39 2005 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 17 May 2005 21:23:39 -0700 Subject: [IronPython] Double-Import Bug Message-ID: <200505180423.VAA02812@dopey.hagenlocher.org> > On May 17, 2005, at 10:42 PM, Curt Hagenlocher wrote: > > > I believe that this behavior is consistent with that of CPython. > > Consistent with CPython < 2.4. The behavior has changed. Figures. I'm still using 1.5.2 :) -- Curt Hagenlocher curt at hagenlocher.org From bob at redivi.com Wed May 18 05:38:01 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 17 May 2005 23:38:01 -0400 Subject: [IronPython] Double-Import Bug In-Reply-To: <200505180423.VAA02812@dopey.hagenlocher.org> References: <200505180423.VAA02812@dopey.hagenlocher.org> Message-ID: On May 18, 2005, at 12:23 AM, Curt Hagenlocher wrote: >> On May 17, 2005, at 10:42 PM, Curt Hagenlocher wrote: >> >> >>> I believe that this behavior is consistent with that of CPython. >>> >> >> Consistent with CPython < 2.4. The behavior has changed. >> > > Figures. I'm still using 1.5.2 :) And you have a version of Windows new enough to run .NET 2.0? Amazing :) -bob From curt at hagenlocher.org Wed May 18 07:17:58 2005 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 17 May 2005 22:17:58 -0700 Subject: [IronPython] Double-Import Bug Message-ID: <200505180517.WAA02887@dopey.hagenlocher.org> Bob Ippolito writes: > On May 18, 2005, at 12:23 AM, Curt Hagenlocher wrote: >> Figures. I'm still using 1.5.2 :) > > And you have a version of Windows new enough to run .NET 2.0? > Amazing :) Hey, 1.5.2 works just fine on Windows 2003! -- Curt Hagenlocher curt at hagenlocher.org From msurel at comcast.net Wed May 18 13:45:18 2005 From: msurel at comcast.net (msurel at comcast.net) Date: Wed, 18 May 2005 11:45:18 +0000 Subject: [IronPython] Double-Import Bug Message-ID: <051820051145.28560.428B2ACE0006EBBA00006F902200737478040A9D9A9C03@comcast.net> http://zephyrfalcon.org/weblog2/arch_e10_00590.html http://www.voidspace.org.uk/python/articles/upgrading_python.html#id25 Some people claim that 1.5.2 is the One True Python. I only started using it at 2.2, so my brain may be a little warped in that regard... > Bob Ippolito writes: > > > On May 18, 2005, at 12:23 AM, Curt Hagenlocher wrote: > > >> Figures. I'm still using 1.5.2 :) > > > > And you have a version of Windows new enough to run .NET 2.0? > > Amazing :) > > Hey, 1.5.2 works just fine on Windows 2003! > > -- > Curt Hagenlocher > curt at hagenlocher.org > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From Keith_Tingle at payformance.com Wed May 18 15:07:24 2005 From: Keith_Tingle at payformance.com (Keith Tingle) Date: Wed, 18 May 2005 09:07:24 -0400 Subject: [IronPython] (no subject) Message-ID: I would like to embed a scripting language in a C# application. First looked at VSA, but found that support for VSA was dropped by Microsoft. Next looked at Lua, which works well but is not entirely managed code, which I am told is bad. IronPython appears ideal until we realized it requires the 2.0 version of the .NET JDK, Can anyone recommend an embeddable .NET scripting language that is entirely managed code? Something like Sleep (http://sleep.hick.org) but for .NET? We do not need a tremendous amount of functionality just something to drive a GUI, and do not mind some instability as long as I have source. Thanks for any help! Confidentiality statement *************************************************************************** Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copy, use, disclosure, or distribution is prohibited. If you are not the intended recipient, or not an agent of the intended recipient responsible for delivering this message, please contact the sender by reply e-mail and destroy all copies of the original message.* From riltim at gmail.com Wed May 18 16:01:29 2005 From: riltim at gmail.com (Tim Riley) Date: Wed, 18 May 2005 10:01:29 -0400 Subject: [IronPython] (no subject) In-Reply-To: References: Message-ID: I'm not sure if this is exactly what you're looking for but take a look at boo. http://boo.codehaus.org/ On 5/18/05, Keith Tingle wrote: > I would like to embed a scripting language in a C# application. > > First looked at VSA, but found that support for VSA was dropped by > Microsoft. > > Next looked at Lua, which works well but is not entirely managed code, which > I am told is bad. > > IronPython appears ideal until we realized it requires the 2.0 version of > the .NET JDK, > > Can anyone recommend an embeddable .NET scripting language that is entirely > managed code? Something like Sleep (http://sleep.hick.org) but for .NET? > > We do not need a tremendous amount of functionality just something to drive > a GUI, and do not mind some instability as long as I have source. > > Thanks for any help! > Confidentiality statement > *************************************************************************** > Notice: This e-mail message, including any attachments, is for the sole > use of the intended recipient(s) and may contain confidential and > privileged information. Any unauthorized review, copy, use, disclosure, > or distribution is prohibited. If you are not the intended recipient, > or not an agent of the intended recipient responsible for delivering this > message, please contact the sender by reply e-mail and destroy all copies > of the original message.* > _______________________________________________ > 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 May 18 17:47:23 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Wed, 18 May 2005 08:47:23 -0700 Subject: [IronPython] Double-Import Bug Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201CF9CA8@df-fido-msg.exchange.corp.microsoft.com> Bob Ippolito wrote: > > On May 17, 2005, at 10:42 PM, Curt Hagenlocher wrote: > > >> Is this bug known? > >> That is, if a module fails to import, a second attempt to import does > >> not throw an exception. I think this is because > >> Importer.LoadFromSource puts the module into sys.modules before > >> calling the import function, but does not remove it if the import > >> function fails. > >> > > > > I believe that this behavior is consistent with that of CPython. > > Consistent with CPython < 2.4. The behavior has changed. Thanks for the report and the version clarification. This wasn't a known bug but it is now. IronPython was mostly written before CPython 2.4 came out. We're currently going through the regression tests from CPython 2.3 so that we can improve correctness before we take the time to implement new 2.4 features. Before we release IronPython 1.0 we plan to be running the regression tests for 2.4 if not 2.5. Thanks - Jim From mailinglist.account at gmail.com Wed May 18 18:25:40 2005 From: mailinglist.account at gmail.com (Anthony Tarlano) Date: Wed, 18 May 2005 18:25:40 +0200 Subject: [IronPython] StringIO??? In-Reply-To: References: <1E1FC9DA1767ED44872F4E17AC17E8F701ED10AD@df-chewy-msg.exchange.corp.microsoft.com> Message-ID: Martin, Just as a F.Y.I, IP-0.7.5 did fix it the problem, but as you can also see from below IP-0.7.4 with Beta 1 did work before. ---- IP-0.7.5 with Beta 2 IronPython 0.7.5 on .NET 2.0.50215.44 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO >>> dir(StringIO) ['ValueError', 'ImportError', 'RuntimeError', 'basestring', 'isinstance', 'Strin gIO', 'None', 'False', 'open', 'EINVAL', '__name__', 'str', 'min', 'max', 'len', 'IOError', 'test', 'StopIteration', '__all__', '_', '__builtins__', '__file__'] >>> ---- IP-0.7.5 with Beta 1 IronPython 0.7.5 on .NET 2.0.40607.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO System.MissingMethodException: Method not found: 'Boolean System.Collections.Gen eric.IDictionary`2.TryGetValue(!0, !1 ByRef)'. at IronPython.Objects.Importer.TryGetExistingModule(String fullName, Object& ret) at IronPython.Objects.Importer.Import(PythonModule mod, String fullName, List from) at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) at input_0.Run(Frame frame) at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) at IronPython.Hosting.PythonEngine.RunInteractive() >>> ---- IP-0.7.4 with Beta 1 IronPython 0.7.4 on .NET 2.0.40607.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO >>> On 5/18/05, Anthony Tarlano wrote: > > Martin, > > Yes indeed it is strange since it worked just fine with the previous > build. I will upgrade and let you know if that fixes the problem. > > Thanks, > > Anthony > > On 5/18/05, Martin Maly wrote: > > > > Strange that someone reported similar thing on GotDotNet forums. I > > believe that the cause is an old version of .Net. > > You need .Net 2.0 Beta 2 to run IronPython: > > IronPython 0.7.5 on .NET *2.0.50215.44* > > Copyright (c) Microsoft Corporation. All rights reserved. > > >>> import StringIO > > >>> > > You can get Beta 2 from here: > > http://www.microsoft.com/downloads/details.aspx?familyid=7ABD8C8F-287E-4C7E-9A4A-A4ECFF40FC8E&displaylang=en > > > > ------------------------------ > > *From:* users-ironpython.com-bounces at lists.ironpython.com [mailto: > > users-ironpython.com-bounces at lists.ironpython.com] *On Behalf Of *Anthony > > Tarlano > > *Sent:* Tuesday, May 17, 2005 3:02 PM > > *To:* Discussion of IronPython > > *Subject:* [IronPython] StringIO??? > > > > Martin, > > > > I think that while fixing the 'assemblies in the same directory' bug, a > > new critter may have been introduced... > > > > StringIO used to work in IP-0.7.4, now using IP.0.7.5 I see the > > following trackback.. > > > > IronPython 0.7.5 on .NET 2.0.40607.42 > > Copyright (c) Microsoft Corporation. All rights reserved. > > >>> import StringIO > > System.MissingMethodException: Method not found: 'Boolean > > System.Collections.Gen > > eric.IDictionary`2.TryGetValue(!0, !1 ByRef)'. > > at IronPython.Objects.Importer.TryGetExistingModule(String fullName, > > Object& > > ret) > > at IronPython.Objects.Importer.Import(PythonModule mod, String fullName, > > List > > from) > > at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) > > at input_0.Run(Frame frame) > > at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) > > at IronPython.Hosting.PythonEngine.RunInteractive() > > >>> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirko at microsoft.com Wed May 18 20:34:51 2005 From: kirko at microsoft.com (Kirk Olynyk) Date: Wed, 18 May 2005 11:34:51 -0700 Subject: [IronPython] Trouble building 0.7.5 Message-ID: <310187D53C02434D8F2CF4CD951B734102E15C52@RED-MSG-60.redmond.corp.microsoft.com> I encounter an error when building 0.7.5 (earlier version build fine) 'IronPython.Objects.Dict.IEnumerable.GetEnumerator()': containing type does not implement interface 'System.Collections.IEnumerable''; File:Dict.cs; Line: 189 'IronPython.Objects.CustomDict.IEnumerable.GetEnumerator()': containing type does not implement interface 'System.Collections.IEnumerable'; File:Dict.cs; Line:902 Is this unique to me? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbond at free.fr Wed May 18 20:35:50 2005 From: kbond at free.fr (kbond at free.fr) Date: Wed, 18 May 2005 20:35:50 +0200 (CEST) Subject: [IronPython] StringIO??? Message-ID: <1116441350.428b8b06bddd6@webmail.naema.org> Hello, I do have a problem to import StringIO. I have seen that you are explaining this error my not having the latest version of the .Net framework. How can I check the version of the .Net framewaork installed on my computer? I think it is the beta 2 but I am not sure. Thank you for your help. Here it is the error I am getting: with the latest build O.7.5 IronPython 0.7.5 on .NET 2.0.50215.44 Copyright (c) Microsoft Corporation. All rights reserved. >>> () >>> import StringIO IronPython.Objects.PythonImportError: No module named StringIO at IronPython.Modules.__builtin__.__import__(String name, Object globals, Obj ect locals, Object fromList) at ReflectOpt.IronPython.Modules.__builtin__.__import__(Object , Object , Obj ect , Object ) at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1, Object a rg2, Object arg3) at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object arg2, Object arg3) at IronPython.Objects.Importer.Import(PythonModule mod, String fullName, List from) at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) at input_1.Run(Frame frame) at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) at IronPython.Hosting.PythonEngine.RunInteractive() >>> with the latest build O.7.4 IronPython 0.7.4 on .NET 2.0.50215.44 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO IronPython.Objects.PythonImportError: No module named StringIO at IronPython.Modules.__builtin__.__import__(String name, Object globals, Obj ect locals, Object fromList) at ReflectOpt.IronPython.Modules.__builtin__.__import__(Object , Object , Obj ect , Object ) at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1, Object a rg2, Object arg3) at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object arg2, Object arg3) at IronPython.Objects.Importer.Import(PythonModule mod, String fullName, List from) at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) at input_0.Run(Frame frame) at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) at IronPython.Hosting.PythonEngine.RunInteractive() >>> Martin, Just as a F.Y.I, IP-0.7.5 did fix it the problem, but as you can also see from below IP-0.7.4 with Beta 1 did work before. ---- IP-0.7.5 with Beta 2 IronPython 0.7.5 on .NET 2.0.50215.44 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO >>> dir(StringIO) ['ValueError', 'ImportError', 'RuntimeError', 'basestring', 'isinstance', 'Strin gIO', 'None', 'False', 'open', 'EINVAL', '__name__', 'str', 'min', 'max', 'len', 'IOError', 'test', 'StopIteration', '__all__', '_', '__builtins__', '__file__'] >>> ---- IP-0.7.5 with Beta 1 IronPython 0.7.5 on .NET 2.0.40607.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO System.MissingMethodException: Method not found: 'Boolean System.Collections.Gen eric.IDictionary`2.TryGetValue(!0, !1 ByRef)'. at IronPython.Objects.Importer.TryGetExistingModule(String fullName, Object& ret) at IronPython.Objects.Importer.Import(PythonModule mod, String fullName, List from) at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) at input_0.Run(Frame frame) at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) at IronPython.Hosting.PythonEngine.RunInteractive() >>> ---- IP-0.7.4 with Beta 1 IronPython 0.7.4 on .NET 2.0.40607.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO >>> On 5/18/05, Anthony Tarlano wrote: > > Martin, > > Yes indeed it is strange since it worked just fine with the previous > build. I will upgrade and let you know if that fixes the problem. > > Thanks, > > Anthony > > On 5/18/05, Martin Maly wrote: > > > > Strange that someone reported similar thing on GotDotNet forums. I > > believe that the cause is an old version of .Net. > > You need .Net 2.0 Beta 2 to run IronPython: > > IronPython 0.7.5 on .NET *2.0.50215.44* > > Copyright (c) Microsoft Corporation. All rights reserved. > > >>> import StringIO > > >>> > > You can get Beta 2 from here: > > http://www.microsoft.com/downloads/details.aspx?familyid=7ABD8C8F-287E-4C7E-9A4A-A4ECFF40FC8E&displaylang=en > > > > ------------------------------ > > *From:* users-ironpython.com-bounces at lists.ironpython.com [mailto: > > users-ironpython.com-bounces at lists.ironpython.com] *On Behalf Of *Anthony > > Tarlano > > *Sent:* Tuesday, May 17, 2005 3:02 PM > > *To:* Discussion of IronPython > > *Subject:* [IronPython] StringIO??? > > > > Martin, > > > > I think that while fixing the 'assemblies in the same directory' bug, a > > new critter may have been introduced... > > > > StringIO used to work in IP-0.7.4, now using IP.0.7.5 I see the > > following trackback.. > > > > IronPython 0.7.5 on .NET 2.0.40607.42 > > Copyright (c) Microsoft Corporation. All rights reserved. > > >>> import StringIO > > System.MissingMethodException: Method not found: 'Boolean > > System.Collections.Gen > > eric.IDictionary`2.TryGetValue(!0, !1 ByRef)'. > > at IronPython.Objects.Importer.TryGetExistingModule(String fullName, > > Object& > > ret) > > at IronPython.Objects.Importer.Import(PythonModule mod, String fullName, > > List > > from) > > at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) > > at input_0.Run(Frame frame) > > at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) > > at IronPython.Hosting.PythonEngine.RunInteractive() > > >>> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://listserver.dreamhost.com/pipermail/users-ironpython.com/attachments/20050518/f6e9809f/attachment-0001.htm From mailinglist.account at gmail.com Wed May 18 21:55:36 2005 From: mailinglist.account at gmail.com (Anthony Tarlano) Date: Wed, 18 May 2005 21:55:36 +0200 Subject: [IronPython] StringIO??? In-Reply-To: <1116441350.428b8b06bddd6@webmail.naema.org> References: <1116441350.428b8b06bddd6@webmail.naema.org> Message-ID: Kbond, You need to replace the Lib directory in IronPython-0.7.5 with the standard library modules Lib directory from Python2.3.. Once you have done this you will have StringIO.. As for your ? you can use the version string contained on the first interpeter line "IronPython 0.7.5 on .NET 2.0.50215.44" to determine the .NET version or look in the "Add/Remove Programs" window in the ControlPanel. You are all set since you have beta 2. Anthony On 5/18/05, kbond at free.fr wrote: > > Hello, > > I do have a problem to import StringIO. > I have seen that you are explaining this error my not having the latest > version > of the .Net framework. > How can I check the version of the .Net framewaork installed on my > computer? > I think it is the beta 2 but I am not sure. > Thank you for your help. > > Here it is the error I am getting: > > with the latest build O.7.5 > > IronPython 0.7.5 on .NET 2.0.50215.44 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> > () > >>> import StringIO > IronPython.Objects.PythonImportError: No module named StringIO > at IronPython.Modules.__builtin__.__import__(String name, Object globals, > Obj > ect locals, Object fromList) > at ReflectOpt.IronPython.Modules.__builtin__.__import__(Object , Object , > Obj > ect , Object ) > at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1, > Object a > rg2, Object arg3) > at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, > Object > arg2, Object arg3) > at IronPython.Objects.Importer.Import(PythonModule mod, String fullName, > List > from) > at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) > at input_1.Run(Frame frame) > at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) > at IronPython.Hosting.PythonEngine.RunInteractive() > >>> > > with the latest build O.7.4 > > IronPython 0.7.4 on .NET 2.0.50215.44 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> import StringIO > IronPython.Objects.PythonImportError: No module named StringIO > at IronPython.Modules.__builtin__.__import__(String name, Object globals, > Obj > ect locals, Object fromList) > at ReflectOpt.IronPython.Modules.__builtin__.__import__(Object , Object , > Obj > ect , Object ) > at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1, > Object a > rg2, Object arg3) > at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, > Object > arg2, Object arg3) > at IronPython.Objects.Importer.Import(PythonModule mod, String fullName, > List > from) > at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) > at input_0.Run(Frame frame) > at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) > at IronPython.Hosting.PythonEngine.RunInteractive() > >>> > > Martin, > > Just as a F.Y.I, IP-0.7.5 did fix it the problem, but as you can also see > from below IP-0.7.4 with Beta 1 did work before. > > ---- IP-0.7.5 with Beta 2 > IronPython 0.7.5 on .NET 2.0.50215.44 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> import StringIO > >>> dir(StringIO) > ['ValueError', 'ImportError', 'RuntimeError', 'basestring', 'isinstance', > 'Strin > gIO', 'None', 'False', 'open', 'EINVAL', '__name__', 'str', 'min', 'max', > 'len', > 'IOError', 'test', 'StopIteration', '__all__', '_', '__builtins__', > '__file__'] > > >>> > > ---- IP-0.7.5 with Beta 1 > IronPython 0.7.5 on .NET 2.0.40607.42 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> import StringIO > System.MissingMethodException: Method not found: 'Boolean > System.Collections.Gen > eric.IDictionary`2.TryGetValue(!0, !1 ByRef)'. > at IronPython.Objects.Importer.TryGetExistingModule(String fullName, > Object& > ret) > at IronPython.Objects.Importer.Import(PythonModule mod, String fullName, > List > from) > at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) > at input_0.Run(Frame frame) > at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) > at IronPython.Hosting.PythonEngine.RunInteractive() > >>> > > ---- IP-0.7.4 with Beta 1 > IronPython 0.7.4 on .NET 2.0.40607.42 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> import StringIO > >>> > > On 5/18/05, Anthony Tarlano > > wrote: > > > > Martin, > > > > Yes indeed it is strange since it worked just fine with the previous > > build. I will upgrade and let you know if that fixes the problem. > > > > Thanks, > > > > Anthony > > > > On 5/18/05, Martin Maly > > wrote: > > > > > > Strange that someone reported similar thing on GotDotNet forums. I > > > believe that the cause is an old version of .Net. > > > You need .Net 2.0 Beta 2 to run IronPython: > > > IronPython 0.7.5 on .NET *2.0.50215.44* > > > Copyright (c) Microsoft Corporation. All rights reserved. > > > >>> import StringIO > > > >>> > > > You can get Beta 2 from here: > > > > > http://www.microsoft.com/downloads/details.aspx?familyid=7ABD8C8F-287E-4C7E-9A4A-A4ECFF40FC8E&displaylang=en > > > > > > ------------------------------ > > > *From:* users-ironpython.com-bounces at lists.ironpython.com[mailto: > > > users-ironpython.com-bounces at lists.ironpython.com] > *On Behalf Of *Anthony > > > Tarlano > > > *Sent:* Tuesday, May 17, 2005 3:02 PM > > > *To:* Discussion of IronPython > > > *Subject:* [IronPython] StringIO??? > > > > > > Martin, > > > > > > I think that while fixing the 'assemblies in the same directory' bug, > a > > > new critter may have been introduced... > > > > > > StringIO used to work in IP-0.7.4, now using IP.0.7.5 I see the > > > following trackback.. > > > > > > IronPython 0.7.5 on .NET 2.0.40607.42 > > > Copyright (c) Microsoft Corporation. All rights reserved. > > > >>> import StringIO > > > System.MissingMethodException: Method not found: 'Boolean > > > System.Collections.Gen > > > eric.IDictionary`2.TryGetValue(!0, !1 ByRef)'. > > > at IronPython.Objects.Importer.TryGetExistingModule(String fullName, > > > Object& > > > ret) > > > at IronPython.Objects.Importer.Import(PythonModule mod, String > fullName, > > > List > > > from) > > > at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) > > > at input_0.Run(Frame frame) > > > at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) > > > at IronPython.Hosting.PythonEngine.RunInteractive() > > > >>> > > > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > http://listserver.dreamhost.com/pipermail/users-ironpython.com/attachments/20050518/f6e9809f/attachment-0001.htm > _______________________________________________ > 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: From jimhug at exchange.microsoft.com Wed May 18 22:10:42 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Wed, 18 May 2005 13:10:42 -0700 Subject: [IronPython] Trouble building 0.7.5 Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201CF9DDC@df-fido-msg.exchange.corp.microsoft.com> IronPython-0.7.5 requires .NET 2.0 beta 2 (or later). I'm sorry that we didn't catch this sooner and at the very least made this prominent in the release notes. We should also modify the config file so that a nice error will be produced if you try to run on an earlier version. I suspect your error is the compile-time equivalent of the other bugs reported running 0.7.5 on 2.0 beta 1. This change was accidental and not a deliberate attempt to force people to upgrade; nevertheless, at this stage of the project I suspect that more of this sort of thing will happen from time to time. That's part of the price of 0.7.x software. We'll try to at least give you better warning in the future. If you're running on Windows, I STRONGLY encourage you to upgrade to .NET 2.0 beta 2. A ton of bugs have been fixed and this is a much higher quality release as we get closer to RTM. If you're running on a different CLI implementation I'd like to know if there were things that you could do with 0.7.4 that were broken by 0.7.5. I can't promise a quick fix, but I'd like to at least investigate any issues to see if there's something we could do. 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: Wednesday, May 18, 2005 11:35 AM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Trouble building 0.7.5 I encounter an error when building 0.7.5 (earlier version build fine) ? 'IronPython.Objects.Dict.IEnumerable.GetEnumerator()': containing type does not implement interface 'System.Collections.IEnumerable''; File:Dict.cs; Line: 189 'IronPython.Objects.CustomDict.IEnumerable.GetEnumerator()': containing type does not implement interface 'System.Collections.IEnumerable'; File:Dict.cs; Line:902 ? Is this unique to me? From kfarmer at thuban.org Thu May 19 05:03:34 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 18 May 2005 20:03:34 -0700 Subject: [IronPython] [0.7.5] exception on exit Message-ID: I installed 0.7.5, and started it up using the following batch file, after setting PATH. I was running using a non-Admin account. FePy.cmd -------- IronPythonConsole.exe %1 %2 %3 %4 %5 %6 %7 %8 %9 I got an exception trying to exit. It triggered the send-to-Microsoft dialog, which I did. C:\>FePy C:\>IronPythonConsole.exe IronPython 0.7.5 on .NET 2.0.50215.44 Copyright (c) Microsoft Corporation. All rights reserved. >>> ^Z Unhandled Exception: System.IO.IOException: I/O error occurred. at System.Reflection.Module._InternalSavePEFile(String fileName, Int32 entryPoint, Int32 isExe, Boolean isManifestFile) at System.Reflection.Module.InternalSavePEFile(String fileName, MethodToken entryPoint, Int32 isExe, Boolean isManifestFile) at System.Reflection.Emit.ModuleBuilder.SaveNoLock(String fileName, Boolean isAssemblyFile, PortableExecutableKinds portableExecutableKind, ImageFileMachine imageFileMachine) at System.Reflection.Emit.ModuleBuilder.Save(String fileName, Boolean isAssemblyFile, PortableExecutableKinds portableExecutableKind, ImageFileMachine imageFileMachine) at System.Reflection.Emit.AssemblyBuilder.SaveNoLock(String assemblyFileName, PortableExecutableKinds portableExecutableKind, ImageFileMachine imageFileMachine) at System.Reflection.Emit.AssemblyBuilder.Save(String assemblyFileName, PortableExecutableKinds portableExecutableKind, ImageFileMachine imageFileMachine) at IronPython.AST.SnippetMaker.DumpAssembly() at IronPython.Hosting.PythonEngine.DumpDebugInfo() at IronPythonConsole.PythonCommandLine.RunInteractive(PythonEngine engine) at IronPythonConsole.PythonCommandLine.Main(String[] rawArgs) From kfarmer at thuban.org Thu May 19 05:07:08 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 18 May 2005 20:07:08 -0700 Subject: [IronPython] [0.7.5] ... and the Monkey says ... Message-ID: Just FYI: C:\>MonoPy C:\>mono "C:\Program Files\IronPython-0.7.5\bin\IronPythonConsole.exe" ** (C:\Program Files\IronPython-0.7.5\bin\IronPythonConsole.exe:616): WARNING **: Missing method TryGetValue in assembly C:\Program Files\IronPython-0.7.5\bin\IronPython.dll, type IDictionary`2 IronPython 0.7.5 on .NET 2.0.50215.16 Copyright (c) Microsoft Corporation. All rights reserved. >>> ^Z Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object in <0x00000> in <0x0000b> IronPython.Objects.Dict:items () in <0x00028> IronPython.Objects.ReflectedMethodBase:DumpReflectedCalls () in <0x0000a> IronPython.Hosting.PythonEngine:DumpDebugInfo () in <0x00072> IronPythonConsole.PythonCommandLine:RunInteractive (IronPython.Hosting.PythonEngine engine) in <0x000a5> IronPythonConsole.PythonCommandLine:Main (System.String[] rawArgs) C:\> ... and ... >>> from System.Collections.Generic import * ** (C:\Program Files\IronPython-0.7.5\bin\IronPythonConsole.exe:3124): WARNING **: Missing method TryGetValue in assembly C:\Program Files\IronPython-0.7.5\bin\IronPython.dll, type IDictionary`2 System.NullReferenceException: Object reference not set to an instance of an object in <0x00000> in <0x0001c> IronPython.Objects.Importer:Import (IronPython.Objects.PythonModule mod, System.String fullName, IronPython.Objects.List from) in <0x00082> IronPython.Objects.Ops:ImportStar (IronPython.Objects.PythonModule mod, System.String fullName) in <0x00031> input_0:Run (IronPython.Objects.Frame frame) in <0x0025a> IronPython.Hosting.PythonEngine:DoOneInteractive (IronPython.Objects.Frame topFrame) in <0x0004c> IronPython.Hosting.PythonEngine:RunInteractive () >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From martmaly at exchange.microsoft.com Thu May 19 05:57:12 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Wed, 18 May 2005 20:57:12 -0700 Subject: [IronPython] StringIO??? Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701ED15A4@df-chewy-msg.exchange.corp.microsoft.com> Or what you can also do is point IronPython to your StringIO.py directory: import sys sys.path.append( ) import StringIO Martin ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Anthony Tarlano Sent: Wednesday, May 18, 2005 12:56 PM To: Discussion of IronPython Subject: Re: [IronPython] StringIO??? Kbond, You need to replace the Lib directory in IronPython-0.7.5 with the standard library modules Lib directory from Python2.3.. Once you have done this you will have StringIO.. As for your ? you can use the version string contained on the first interpeter line "IronPython 0.7.5 on .NET 2.0.50215.44" to determine the .NET version or look in the "Add/Remove Programs" window in the ControlPanel. You are all set since you have beta 2. Anthony On 5/18/05, kbond at free.fr wrote: Hello, I do have a problem to import StringIO. I have seen that you are explaining this error my not having the latest version of the .Net framework. How can I check the version of the .Net framewaork installed on my computer? I think it is the beta 2 but I am not sure. Thank you for your help. Here it is the error I am getting: with the latest build O.7.5 IronPython 0.7.5 on .NET 2.0.50215.44 Copyright (c) Microsoft Corporation. All rights reserved. >>> () >>> import StringIO IronPython.Objects.PythonImportError: No module named StringIO at IronPython.Modules.__builtin__.__import__(String name, Object globals, Obj ect locals, Object fromList) at ReflectOpt.IronPython.Modules.__builtin__.__import__(Object , Object , Obj ect , Object ) at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1, Object a rg2, Object arg3) at IronPython.Objects.Ops.Call (Object func, Object arg0, Object arg1, Object arg2, Object arg3) at IronPython.Objects.Importer.Import(PythonModule mod, String fullName, List from) at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) at input_1.Run(Frame frame) at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) at IronPython.Hosting.PythonEngine.RunInteractive() >>> with the latest build O.7.4 IronPython 0.7.4 on .NET 2.0.50215.44 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO IronPython.Objects.PythonImportError: No module named StringIO at IronPython.Modules.__builtin__.__import_ _(String name, Object globals, Obj ect locals, Object fromList) at ReflectOpt.IronPython.Modules.__builtin__.__import__(Object , Object , Obj ect , Object ) at IronPython.Objects.BuiltinFunction.Call(Object arg0, Object arg1, Object a rg2, Object arg3) at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object arg2, Object arg3) at IronPython.Objects.Importer.Import(PythonModule mod, String fullName, List from) at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) at input_0.Run(Frame frame) at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) at IronPython.Hosting.PythonEngine.RunInteractive () >>> Martin, Just as a F.Y.I, IP-0.7.5 did fix it the problem, but as you can also see from below IP-0.7.4 with Beta 1 did work before. ---- IP-0.7.5 with Beta 2 IronPython 0.7.5 on .NET 2.0.50215.44 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO >>> dir(StringIO) ['ValueError', 'ImportError', 'RuntimeError', 'basestring', 'isinstance', 'Strin gIO', 'None', 'False', 'open', 'EINVAL', '__name__', 'str', 'min', 'max', 'len', 'IOError', 'test', 'StopIteration', '__all__', '_', '__builtins__', '__file__'] >>> ---- IP-0.7.5 with Beta 1 IronPython 0.7.5 on .NET 2.0.40607.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO System.MissingMethodException: Method not found: 'Boolean System.Collections.Gen eric.IDictionary`2.TryGetValue(!0, !1 ByRef)'. at IronPython.Objects.Importer.TryGetExistingModule(String fullName, Object& ret) at IronPython.Objects.Importer.Import(PythonModule mod, String fullName, List from) at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) at input_0.Run(Frame frame) at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) at IronPython.Hosting.PythonEngine.RunInteractive () >>> ---- IP-0.7.4 with Beta 1 IronPython 0.7.4 on .NET 2.0.40607.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO >>> On 5/18/05, Anthony Tarlano < mailinglist.account at gmail.com> wrote: > > Martin, > > Yes indeed it is strange since it worked just fine with the previous > build. I will upgrade and let you know if that fixes the problem. > > Thanks, > > Anthony > > On 5/18/05, Martin Maly wrote: > > > > Strange that someone reported similar thing on GotDotNet forums. I > > believe that the cause is an old version of .Net. > > You need .Net 2.0 Beta 2 to run IronPython: > > IronPython 0.7.5 on .NET *2.0.50215.44* > > Copyright (c) Microsoft Corporation. All rights reserved. > > >>> import StringIO > > >>> > > You can get Beta 2 from here: > > http://www.microsoft.com/downloads/details.aspx?familyid=7ABD8C8F-287E-4 C7E-9A4A-A4ECFF40FC8E&displaylang=en > > > > ------------------------------ > > *From:* users-ironpython.com-bounces at lists.ironpython.com [mailto: > > users-ironpython.com-bounces at lists.ironpython.com] *On Behalf Of *Anthony > > Tarlano > > *Sent:* Tuesday, May 17, 2005 3:02 PM > > *To:* Discussion of IronPython > > *Subject:* [IronPython] StringIO??? > > > > Martin, > > > > I think that while fixing the 'assemblies in the same directory' bug, a > > new critter may have been introduced... > > > > StringIO used to work in IP-0.7.4, now using IP.0.7.5 I see the > > following trackback.. > > > > IronPython 0.7.5 on .NET 2.0.40607.42 > > Copyright (c) Microsoft Corporation. All rights reserved. > > >>> import StringIO > > System.MissingMethodException: Method not found: 'Boolean > > System.Collections.Gen > > eric.IDictionary`2.TryGetValue(!0, !1 ByRef)'. > > at IronPython.Objects.Importer.TryGetExistingModule(String fullName, > > Object& > > ret) > > at IronPython.Objects.Importer.Import (PythonModule mod, String fullName, > > List > > from) > > at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) > > at input_0.Run(Frame frame) > > at IronPython.Hosting.PythonEngine.DoOneInteractive (Frame topFrame) > > at IronPython.Hosting.PythonEngine.RunInteractive() > > >>> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://listserver.dreamhost.com/pipermail/users-ironpython.com/attachmen ts/20050518/f6e9809f/attachment-0001.htm _______________________________________________ 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: From martmaly at exchange.microsoft.com Thu May 19 06:01:11 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Wed, 18 May 2005 21:01:11 -0700 Subject: [IronPython] [0.7.5] exception on exit Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701ED15A5@df-chewy-msg.exchange.corp.microsoft.com> This is because at the end of executin IronPython saves the compiled code into snippets.dll into current directory (that would be C:\ I guess) which you may not have access to as non-admin. Do you think that may be it? M. > -----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: Wednesday, May 18, 2005 8:04 PM > To: Discussion of IronPython > Subject: [IronPython] [0.7.5] exception on exit > > I installed 0.7.5, and started it up using the following > batch file, after setting PATH. I was running using a > non-Admin account. > > FePy.cmd > -------- > IronPythonConsole.exe %1 %2 %3 %4 %5 %6 %7 %8 %9 > > I got an exception trying to exit. It triggered the > send-to-Microsoft dialog, which I did. > > C:\>FePy > > C:\>IronPythonConsole.exe > IronPython 0.7.5 on .NET 2.0.50215.44 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> ^Z > > Unhandled Exception: System.IO.IOException: I/O error occurred. > at System.Reflection.Module._InternalSavePEFile(String fileName, > Int32 entryPoint, Int32 isExe, Boolean isManifestFile) > at System.Reflection.Module.InternalSavePEFile(String > fileName, MethodToken entryPoint, Int32 isExe, Boolean isManifestFile) > at System.Reflection.Emit.ModuleBuilder.SaveNoLock(String > fileName, Boolean isAssemblyFile, PortableExecutableKinds > portableExecutableKind, ImageFileMachine imageFileMachine) > at System.Reflection.Emit.ModuleBuilder.Save(String > fileName, Boolean isAssemblyFile, PortableExecutableKinds > portableExecutableKind, ImageFileMachine imageFileMachine) > at System.Reflection.Emit.AssemblyBuilder.SaveNoLock(String > assemblyFileName, PortableExecutableKinds > portableExecutableKind, ImageFileMachine imageFileMachine) > at System.Reflection.Emit.AssemblyBuilder.Save(String > assemblyFileName, PortableExecutableKinds > portableExecutableKind, ImageFileMachine imageFileMachine) > at IronPython.AST.SnippetMaker.DumpAssembly() > at IronPython.Hosting.PythonEngine.DumpDebugInfo() > at IronPythonConsole.PythonCommandLine.RunInteractive(PythonEngine > engine) > at IronPythonConsole.PythonCommandLine.Main(String[] rawArgs) > > > _______________________________________________ > 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 Thu May 19 06:03:04 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Wed, 18 May 2005 21:03:04 -0700 Subject: [IronPython] StringIO??? Message-ID: <1E1FC9DA1767ED44872F4E17AC17E8F701ED15A6@df-chewy-msg.exchange.corp.microsoft.com> Yes, that make sense. Between 0.7.4 and 0.7.5 Jim made few changes in the code that use features of .Net framework not available in Beta 1, and only available in Beta 2. M. ________________________________ From: Anthony Tarlano [mailto:mailinglist.account at gmail.com] Sent: Wednesday, May 18, 2005 9:26 AM To: Martin Maly; Discussion of IronPython Subject: Re: [IronPython] StringIO??? Martin, Just as a F.Y.I, IP-0.7.5 did fix it the problem, but as you can also see from below IP-0.7.4 with Beta 1 did work before. ---- IP-0.7.5 with Beta 2 IronPython 0.7.5 on .NET 2.0.50215.44 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO >>> dir(StringIO) ['ValueError', 'ImportError', 'RuntimeError', 'basestring', 'isinstance', 'Strin gIO', 'None', 'False', 'open', 'EINVAL', '__name__', 'str', 'min', 'max', 'len', 'IOError', 'test', 'StopIteration', '__all__', '_', '__builtins__', '__file__'] >>> ---- IP-0.7.5 with Beta 1 IronPython 0.7.5 on .NET 2.0.40607.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO System.MissingMethodException: Method not found: 'Boolean System.Collections.Gen eric.IDictionary`2.TryGetValue(!0, !1 ByRef)'. at IronPython.Objects.Importer.TryGetExistingModule(String fullName, Object& ret) at IronPython.Objects.Importer.Import(PythonModule mod, String fullName, List from) at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) at input_0.Run(Frame frame) at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) at IronPython.Hosting.PythonEngine.RunInteractive() >>> ---- IP-0.7.4 with Beta 1 IronPython 0.7.4 on .NET 2.0.40607.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO >>> On 5/18/05, Anthony Tarlano wrote: Martin, Yes indeed it is strange since it worked just fine with the previous build. I will upgrade and let you know if that fixes the problem. Thanks, Anthony On 5/18/05, Martin Maly < martmaly at exchange.microsoft.com > wrote: Strange that someone reported similar thing on GotDotNet forums. I believe that the cause is an old version of .Net. You need .Net 2.0 Beta 2 to run IronPython: IronPython 0.7.5 on .NET 2.0.50215.44 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO >>> You can get Beta 2 from here: http://www.microsoft.com/downloads/details.aspx?familyid=7ABD8C8F-287E-4 C7E-9A4A-A4ECFF40FC8E&displaylang=en ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Anthony Tarlano Sent: Tuesday, May 17, 2005 3:02 PM To: Discussion of IronPython Subject: [IronPython] StringIO??? Martin, I think that while fixing the 'assemblies in the same directory' bug, a new critter may have been introduced... StringIO used to work in IP-0.7.4, now using IP.0.7.5 I see the following trackback.. IronPython 0.7.5 on .NET 2.0.40607.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import StringIO System.MissingMethodException: Method not found: 'Boolean System.Collections.Gen eric.IDictionary`2.TryGetValue(!0, !1 ByRef)'. at IronPython.Objects.Importer.TryGetExistingModule(String fullName, Object& ret) at IronPython.Objects.Importer.Import(PythonModule mod, String fullName, List from) at IronPython.Objects.Ops.Import(PythonModule mod, String fullName) at input_0.Run(Frame frame) at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) at IronPython.Hosting.PythonEngine.RunInteractive() >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jddoty at gmail.com Thu May 19 06:16:40 2005 From: jddoty at gmail.com (John Doty) Date: Wed, 18 May 2005 21:16:40 -0700 Subject: [IronPython] Classes don't have doc strings Message-ID: I have noticed that python-defined classes don't have doc strings. foo.py: class foo(object): "Test one two" def __init__(self): pass >>> import foo >>> print foo.foo.__doc__ IronPython.Objects.PythonAttributeError: type object 'foo' has no attribute '__doc__' at IronPython.Objects.Ops.GetAttr(Object o, String name) at input_1.Run(Frame frame) at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) at IronPython.Hosting.PythonEngine.RunInteractive() >>> Is this known? I modified the code gen for classes to emit a __doc__ member when it finds a doc string in the body, in a manner similar to the way it is done for functions. (But I have a feeling I've done it wrong, because I don't entirely understand the way the code gen works right now.) thanks, john From kfarmer at thuban.org Thu May 19 07:22:12 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 18 May 2005 22:22:12 -0700 Subject: [IronPython] [0.7.5] exception on exit Message-ID: Yeah, that's it. Perhaps it's time to use %temp%\currentDirectory, or isolated storage? -----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: Wednesday, May 18, 2005 9:01 PM To: Discussion of IronPython Subject: RE: [IronPython] [0.7.5] exception on exit This is because at the end of executin IronPython saves the compiled code into snippets.dll into current directory (that would be C:\ I guess) which you may not have access to as non-admin. Do you think that may be it? From mailinglist.account at gmail.com Thu May 19 09:41:34 2005 From: mailinglist.account at gmail.com (Anthony Tarlano) Date: Thu, 19 May 2005 09:41:34 +0200 Subject: [IronPython] Classes don't have doc strings In-Reply-To: References: Message-ID: John, It's a known bug. You should think about adding your comment to the existing __doc__ bug over at GDN. http://gotdotnet.com/workspaces/bugtracker/bugdetails.aspx?id=ad7acff7-ab1e-4bcb-99c0-57ac5a3a9742&bugid=9c2b6240-5c85-4155-8ecb-d072e7ad899e Anthony On 5/19/05, John Doty wrote: > > I have noticed that python-defined classes don't have doc strings. > > foo.py: > > class foo(object): > "Test one two" > def __init__(self): > pass > > >>> import foo > >>> print foo.foo.__doc__ > IronPython.Objects.PythonAttributeError: type object 'foo' has no > attribute '__doc__' > at IronPython.Objects.Ops.GetAttr(Object o, String name) > at input_1.Run(Frame frame) > at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) > at IronPython.Hosting.PythonEngine.RunInteractive() > >>> > > Is this known? > > I modified the code gen for classes to emit a __doc__ member when it > finds a doc string in the body, in a manner similar to the way it is > done for functions. (But I have a feeling I've done it wrong, because > I don't entirely understand the way the code gen works right now.) > > thanks, > john > _______________________________________________ > 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: From vargaz at gmail.com Thu May 19 13:30:22 2005 From: vargaz at gmail.com (Zoltan Varga) Date: Thu, 19 May 2005 13:30:22 +0200 Subject: [IronPython] [0.7.5] ... and the Monkey says ... In-Reply-To: References: Message-ID: <295e750a05051904306dfe47ad@mail.gmail.com> Hi, I you run IronPython on mono, things don't seem to work, and you think it is due to a mono bug (like this one), then please report it at our bug tracking system: http://bugzilla.ximian.com thanks Zoltan On 5/19/05, Keith J. Farmer wrote: > > > > Just FYI: > > > > C:\>MonoPy > > > > C:\>mono "C:\Program Files\IronPython-0.7.5\bin\IronPythonConsole.exe" > > > > > > ** (C:\Program > Files\IronPython-0.7.5\bin\IronPythonConsole.exe:616): > WARNING **: Missing method TryGetValue in assembly C:\Program > Files\IronPython-0.7.5\bin\IronPython.dll, type IDictionary`2 > > IronPython 0.7.5 on .NET 2.0.50215.16 > > Copyright (c) Microsoft Corporation. All rights reserved. > > >>> ^Z > > > > Unhandled Exception: System.NullReferenceException: Object reference not set > to an instance of an object > > in <0x00000> > > in <0x0000b> IronPython.Objects.Dict:items () > > in <0x00028> > IronPython.Objects.ReflectedMethodBase:DumpReflectedCalls > () > > in <0x0000a> IronPython.Hosting.PythonEngine:DumpDebugInfo > () > > in <0x00072> > IronPythonConsole.PythonCommandLine:RunInteractive > (IronPython.Hosting.PythonEngine engine) > > in <0x000a5> IronPythonConsole.PythonCommandLine:Main > (System.String[] rawArgs) > > > > C:\> > > > > ? and ? > > > > >>> from System.Collections.Generic import * > > > > ** (C:\Program > Files\IronPython-0.7.5\bin\IronPythonConsole.exe:3124): > WARNING **: Missing method TryGetValue in assembly C:\Program > Files\IronPython-0.7.5\bin\IronPython.dll, type IDictionary`2 > > System.NullReferenceException: Object reference not set to an instance of an > object > > in <0x00000> > > in <0x0001c> IronPython.Objects.Importer:Import > (IronPython.Objects.PythonModule mod, System.String fullName, > IronPython.Objects.List from) > > in <0x00082> IronPython.Objects.Ops:ImportStar > (IronPython.Objects.PythonModule mod, System.String fullName) > > in <0x00031> input_0:Run (IronPython.Objects.Frame frame) > > in <0x0025a> > IronPython.Hosting.PythonEngine:DoOneInteractive > (IronPython.Objects.Frame topFrame) > > in <0x0004c> IronPython.Hosting.PythonEngine:RunInteractive > () > > >>> > > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > From Larry.Jones at aspentech.com Thu May 19 20:34:29 2005 From: Larry.Jones at aspentech.com (Jones, Larry) Date: Thu, 19 May 2005 13:34:29 -0500 Subject: [IronPython] Trouble building 0.7.5 Message-ID: <781C4D11561D1A4FA1D631415302FB8306A9139E@houmail1.corp.aspentech.com> I had planned to install version 0.7.5; however, this requires the .NET 2.0 beta 2 which requires the Windows Installer 3.0 which requires XP SP2 which our corporate IT department has not yet "released" for installation. Any ideas? (I currently plan to utilize 0.7.4.) Thanks for all the great work! ---- Larry Jones -----Original Message----- From: Jim Hugunin [mailto:jimhug at exchange.microsoft.com] Sent: Wednesday, May 18, 2005 3:11 PM To: Discussion of IronPython Subject: RE: [IronPython] Trouble building 0.7.5 IronPython-0.7.5 requires .NET 2.0 beta 2 (or later). I'm sorry that we didn't catch this sooner and at the very least made this prominent in the release notes. We should also modify the config file so that a nice error will be produced if you try to run on an earlier version. I suspect your error is the compile-time equivalent of the other bugs reported running 0.7.5 on 2.0 beta 1. This change was accidental and not a deliberate attempt to force people to upgrade; nevertheless, at this stage of the project I suspect that more of this sort of thing will happen from time to time. That's part of the price of 0.7.x software. We'll try to at least give you better warning in the future. If you're running on Windows, I STRONGLY encourage you to upgrade to .NET 2.0 beta 2. A ton of bugs have been fixed and this is a much higher quality release as we get closer to RTM. If you're running on a different CLI implementation I'd like to know if there were things that you could do with 0.7.4 that were broken by 0.7.5. I can't promise a quick fix, but I'd like to at least investigate any issues to see if there's something we could do. 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: Wednesday, May 18, 2005 11:35 AM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Trouble building 0.7.5 I encounter an error when building 0.7.5 (earlier version build fine) ? 'IronPython.Objects.Dict.IEnumerable.GetEnumerator()': containing type does not implement interface 'System.Collections.IEnumerable''; File:Dict.cs; Line: 189 'IronPython.Objects.CustomDict.IEnumerable.GetEnumerator()': containing type does not implement interface 'System.Collections.IEnumerable'; File:Dict.cs; Line:902 ? Is this unique to me? _______________________________________________ users-ironpython.com mailing list users-ironpython.com at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you receive this email in error please immediately notify the sender and permanently delete the original copy and any copy of any e-mail, and any printout thereof. From jimhug at exchange.microsoft.com Thu May 19 21:49:54 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Thu, 19 May 2005 12:49:54 -0700 Subject: [IronPython] [0.7.5] exception on exit Message-ID: <6C91A34F0BB48B40A86F1E146B7A049201D74CDB@df-fido-msg.exchange.corp.microsoft.com> This saving of snippets.dll is only done for purposes of debugging the IronPython code generator. The right solution is for us to add an engine-debug switch and only dump this file when that's enabled. Unless you're planning to look at the IL in snippets.dll there's no reason for us to dump this file. Thanks - Jim Keith J. Farmer wrote: > Yeah, that's it. > > Perhaps it's time to use %temp%\currentDirectory, or isolated storage? > > -----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: Wednesday, May 18, 2005 9:01 PM > To: Discussion of IronPython > Subject: RE: [IronPython] [0.7.5] exception on exit > > This is because at the end of executin IronPython saves the compiled > code into snippets.dll into current directory (that would be C:\ I > guess) which you may not have access to as non-admin. Do you think that > may be it? From kfarmer at thuban.org Thu May 19 22:13:36 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Thu, 19 May 2005 13:13:36 -0700 Subject: [IronPython] [0.7.5] exception on exit Message-ID: Ah.. I was thinking it may have been an analog to leaving pyc files alongside their source py. It was fun reflecting through the snippets. ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Jim Hugunin Sent: Thu 5/19/2005 12:49 PM To: Discussion of IronPython Subject: RE: [IronPython] [0.7.5] exception on exit This saving of snippets.dll is only done for purposes of debugging the IronPython code generator. The right solution is for us to add an engine-debug switch and only dump this file when that's enabled. Unless you're planning to look at the IL in snippets.dll there's no reason for us to dump this file. -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3815 bytes Desc: not available URL: From rocco_2003_ at libero.it Fri May 20 10:01:32 2005 From: rocco_2003_ at libero.it (rocco) Date: Fri, 20 May 2005 10:01:32 +0200 Subject: [IronPython] Trouble building 0.7.5 References: <781C4D11561D1A4FA1D631415302FB8306A9139E@houmail1.corp.aspentech.com> Message-ID: <007701c55d12$25fb7c40$18d8fea9@nome5w8khys987> ----- Original Message ----- From: "Jones, Larry" To: "'Discussion of IronPython'" Sent: Thursday, May 19, 2005 8:34 PM Subject: RE: [IronPython] Trouble building 0.7.5 >I had planned to install version 0.7.5; however, this requires the .NET 2.0 >beta 2 which requires the Windows Installer 3.0 which requires XP SP2 which >our corporate IT department has not yet "released" for installation. >Any ideas? (I currently plan to utilize 0.7.4.) It's possible to download the Windows Installer 3.0 also without XP SP2. Insist and say no to the control that is required. It works Rocco Pellegrini >>Thanks for all the great work! ---- Larry Jones -----Original Message----- From: Jim Hugunin [mailto:jimhug at exchange.microsoft.com] Sent: Wednesday, May 18, 2005 3:11 PM To: Discussion of IronPython Subject: RE: [IronPython] Trouble building 0.7.5 IronPython-0.7.5 requires .NET 2.0 beta 2 (or later). I'm sorry that we didn't catch this sooner and at the very least made this prominent in the release notes. We should also modify the config file so that a nice error will be produced if you try to run on an earlier version. I suspect your error is the compile-time equivalent of the other bugs reported running 0.7.5 on 2.0 beta 1. This change was accidental and not a deliberate attempt to force people to upgrade; nevertheless, at this stage of the project I suspect that more of this sort of thing will happen from time to time. That's part of the price of 0.7.x software. We'll try to at least give you better warning in the future. If you're running on Windows, I STRONGLY encourage you to upgrade to .NET 2.0 beta 2. A ton of bugs have been fixed and this is a much higher quality release as we get closer to RTM. If you're running on a different CLI implementation I'd like to know if there were things that you could do with 0.7.4 that were broken by 0.7.5. I can't promise a quick fix, but I'd like to at least investigate any issues to see if there's something we could do. 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: Wednesday, May 18, 2005 11:35 AM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Trouble building 0.7.5 I encounter an error when building 0.7.5 (earlier version build fine) 'IronPython.Objects.Dict.IEnumerable.GetEnumerator()': containing type does not implement interface 'System.Collections.IEnumerable''; File:Dict.cs; Line: 189 'IronPython.Objects.CustomDict.IEnumerable.GetEnumerator()': containing type does not implement interface 'System.Collections.IEnumerable'; File:Dict.cs; Line:902 Is this unique to me? _______________________________________________ users-ironpython.com mailing list users-ironpython.com at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you receive this email in error please immediately notify the sender and permanently delete the original copy and any copy of any e-mail, and any printout thereof. _______________________________________________ users-ironpython.com mailing list users-ironpython.com at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From nyamatongwe at gmail.com Fri May 20 14:15:46 2005 From: nyamatongwe at gmail.com (Neil Hodgson) Date: Fri, 20 May 2005 22:15:46 +1000 Subject: [IronPython] Implementing an interface Message-ID: <50862ebd0505200515404ab32@mail.gmail.com> I have an interface defined in C# that I would like to implement in IronPython 0.7.5. Similar code works in Jython. The interface looks like: public interface IDocumentChangeListener { void StateAltered(); void InvalidateAll(); void InvalidateRange(int a, int b); }; Trying to implement the interface in IronPython like this fails: class IDCLForward(IDocumentChangeListener): def __init__(self, form): self.form = form def StateAltered(self): print "IDCL altered" self.form.StateAltered() # ... with a trace: System.ArgumentException: Parent type was not extensible by the given type. at System.Reflection.Emit.TypeBuilder.SetParent(Type parent) at IronPython.AST.NewTypeMaker.CreateNewType() at IronPython.AST.NewTypeMaker.GetNewType(String mod, String name, Tuple bases, IDictionary`2 dict) at IronPython.Objects.UserType..ctor(String mod, String name, Tuple bases, IDictionary`2 dict) at IronPython.Objects.Ops.MakeClass(String mod, String name, Tuple bases, IDictionary`2 vars) at __main__.Initialize() in C:\os\sinkworld\tentacle\csharp\TentacleP.py:line 24 ... ======================================== Sliding in a concrete C# class between the interface and IronPython class helps avoid stack traces but does not lead to the IronPython class being called. public class IDCL : IDocumentChangeListener { public IDCL() { } public virtual void StateAltered() { Console.Error.WriteLine("StateAltered"); } public virtual void InvalidateAll() { Console.Error.WriteLine("InvalidateAll"); } public virtual void InvalidateRange(int a, int b) { Console.Error.WriteLine("InvalidateRange"); } }; class IDCLForward(IDCL): def __init__(self, form): self.form = form ======================================== Jython likes to have the interface __init__ed but this also upsets IronPython. class IDCLForward(IDCL): def __init__(self, form): IDCL.__init__(self) self.form = form IronPython.Objects.PythonAttributeError: type object 'SinkWorld.IDCL' has no attribute '__init__' at IronPython.Objects.Ops.GetAttr(Object o, String name) at __main__.__init__$f0(Object self, Object form) in C:\os\sinkworld\tentacle\csharp\TentacleP.py:line 26 ======================================== What should I do to make this work? Neil From Larry.Jones at aspentech.com Fri May 20 18:49:43 2005 From: Larry.Jones at aspentech.com (Jones, Larry) Date: Fri, 20 May 2005 12:49:43 -0400 Subject: [IronPython] Trouble building 0.7.5 Message-ID: <781C4D11561D1A4FA1D631415302FB8306A913A1@houmail1.corp.aspentech.com> Thanks! I'll try it. ---- Larry Jones -----Original Message----- From: rocco [mailto:rocco_2003_ at libero.it] Sent: Friday, May 20, 2005 3:02 AM To: Discussion of IronPython Subject: Re: [IronPython] Trouble building 0.7.5 ----- Original Message ----- From: "Jones, Larry" To: "'Discussion of IronPython'" Sent: Thursday, May 19, 2005 8:34 PM Subject: RE: [IronPython] Trouble building 0.7.5 >I had planned to install version 0.7.5; however, this requires the .NET 2.0 >beta 2 which requires the Windows Installer 3.0 which requires XP SP2 which >our corporate IT department has not yet "released" for installation. >Any ideas? (I currently plan to utilize 0.7.4.) It's possible to download the Windows Installer 3.0 also without XP SP2. Insist and say no to the control that is required. It works Rocco Pellegrini >>Thanks for all the great work! ---- Larry Jones -----Original Message----- From: Jim Hugunin [mailto:jimhug at exchange.microsoft.com] Sent: Wednesday, May 18, 2005 3:11 PM To: Discussion of IronPython Subject: RE: [IronPython] Trouble building 0.7.5 IronPython-0.7.5 requires .NET 2.0 beta 2 (or later). I'm sorry that we didn't catch this sooner and at the very least made this prominent in the release notes. We should also modify the config file so that a nice error will be produced if you try to run on an earlier version. I suspect your error is the compile-time equivalent of the other bugs reported running 0.7.5 on 2.0 beta 1. This change was accidental and not a deliberate attempt to force people to upgrade; nevertheless, at this stage of the project I suspect that more of this sort of thing will happen from time to time. That's part of the price of 0.7.x software. We'll try to at least give you better warning in the future. If you're running on Windows, I STRONGLY encourage you to upgrade to .NET 2.0 beta 2. A ton of bugs have been fixed and this is a much higher quality release as we get closer to RTM. If you're running on a different CLI implementation I'd like to know if there were things that you could do with 0.7.4 that were broken by 0.7.5. I can't promise a quick fix, but I'd like to at least investigate any issues to see if there's something we could do. 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: Wednesday, May 18, 2005 11:35 AM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Trouble building 0.7.5 I encounter an error when building 0.7.5 (earlier version build fine) 'IronPython.Objects.Dict.IEnumerable.GetEnumerator()': containing type does not implement interface 'System.Collections.IEnumerable''; File:Dict.cs; Line: 189 'IronPython.Objects.CustomDict.IEnumerable.GetEnumerator()': containing type does not implement interface 'System.Collections.IEnumerable'; File:Dict.cs; Line:902 Is this unique to me? _______________________________________________ users-ironpython.com mailing list users-ironpython.com at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you receive this email in error please immediately notify the sender and permanently delete the original copy and any copy of any e-mail, and any printout thereof. _______________________________________________ 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 This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you receive this email in error please immediately notify the sender and permanently delete the original copy and any copy of any e-mail, and any printout thereof. From sumitb at microsoft.com Sun May 22 04:30:01 2005 From: sumitb at microsoft.com (Sumit Basu) Date: Sat, 21 May 2005 19:30:01 -0700 Subject: [IronPython] getting at the global __dict__ from a module? Message-ID: Does anyone know how to get at the global __dict__ from inside a module (without passing it in as an argument, of course)? __dict__ is special in some way: when you do a dir() at toplevel you don't see it; looking at globals() gives you the same info. Am I missing something? -Sumit -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimhug at exchange.microsoft.com Sun May 22 18:40:53 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Sun, 22 May 2005 09:40:53 -0700 Subject: [IronPython] Implementing an interface Message-ID: <1DFB396200705E46B5338CA4B2E25BDE0A8655@DF-BANDIT-MSG.exchange.corp.microsoft.com> Neil Hodgson wrote: > I have an interface defined in C# that I would like to implement in > IronPython 0.7.5. Similar code works in Jython. The interface looks Implementing an interface in Python is one of the best ways to interoperate with a strongly typed language. As you noted, this works very well in Jython. Unfortunately, this isn't implemented yet in IronPython 0.7.5. This is a very high priority and it should be available in the next couple of weeks. Thanks - Jim From jimhug at exchange.microsoft.com Sun May 22 18:51:02 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Sun, 22 May 2005 09:51:02 -0700 Subject: [IronPython] getting at the global __dict__ from a module? Message-ID: <1DFB396200705E46B5338CA4B2E25BDE0A8656@DF-BANDIT-MSG.exchange.corp.microsoft.com> The dictionary you get back from globals() is the __dict__ from the current module. __dict__ is a special field which holds the dictionary which holds all of the rest of the data on a module. Another good way to get this dictionary is for the module to import itself and then look up the __dict__ member of itself. As I was testing this, I learned that this won't work in IronPython 0.7.5. That's another bug we need to fix. In theory, and in CPython, you should be able to do this. We'll make this work very soon. -- foo.py -- import sys dict = sys.modules[__name__].__dict__ ---- Thanks - Jim ________________________________________ From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Sumit Basu Sent: Saturday, May 21, 2005 7:30 PM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] getting at the global __dict__ from a module? Does anyone know how to get at the global __dict__ from inside a module (without passing it in as an argument, of course)??? __dict__ is special in some way: when you do a dir() at toplevel you don't see it; looking at globals() gives you the same info.? Am I missing something? ? -Sumit From jon at jcosby.com Sun May 22 20:38:12 2005 From: jon at jcosby.com (Jon Cosby) Date: Sun, 22 May 2005 11:38:12 -0700 (PDT) Subject: [IronPython] (no subject) Message-ID: <1209.4.243.47.189.1116787092.squirrel@secure.alienhosting.com> Is there something preventing me from importing from the standard Python library in IronPython 0.6? I can import my own modules, but get a "NotImplementedException" when importing from the standard library. Jon Cosby >>> import sys >>> sys.path ['F:\\Projects\\IronPython\\bin', 'C:\\Python23\\Lib', 'F:\\Projects\\IronPython\\bin\\Projects'] >>> import myscript >>> import os System.NotImplementedException: EmitDel: IronPython.AST.NameExpr at IronPython.AST.Expr.EmitDel(CodeGen cg) in f:\Projects\IronPython\IronPython\AST\Expr.cs:line 42 at IronPython.AST.DelStmt.Emit(CodeGen cg) in f:\Projects\IronPython\IronPython\AST\Stmt.cs:line 681 at IronPython.AST.SuiteStmt.Emit(CodeGen cg) in f:\Projects\IronPython\IronPython\AST\Stmt.cs:line 65 at IronPython.AST.IfStmt.Emit(CodeGen cg) in f:\Projects\IronPython\IronPython\AST\Stmt.cs:line 117 at IronPython.AST.SuiteStmt.Emit(CodeGen cg) in f:\Projects\IronPython\IronPython\AST\Stmt.cs:line 65 at IronPython.AST.ModuleDef.Generate(String sourceFileName) in f:\Projects\IronPython\IronPython\AST\ModuleDef.cs:line 71 at IronPython.Objects.Importer.LoadFromSource(String fullName, String filename, List __path__) in f:\Projects\IronPython\IronPython\Objects\module.cs:line 260 at IronPython.Objects.Importer.LoadFromPath(String name, String fullName, List path) in f:\Projects\IronPython\IronPython\Objects\module.cs:line 246 at IronPython.Objects.Importer.LoadTop(String name) in f:\Projects\IronPython\IronPython\Objects\module.cs:line 210 at IronPython.Objects.Importer.ImportOne(String fullName, Boolean keepTop) in f:\Projects\IronPython\IronPython\Objects\module.cs:line 193 at IronPython.Objects.module.Import(String fullName, Boolean keepTop) in f:\Projects\IronPython\IronPython\Objects\module.cs:line 98 at IronPython.Objects.Ops.Import(module mod, String fullName) in f:\Projects\IronPython\IronPython\Objects\Ops.cs:line 1562 at input_3.Run(Frame frame) at IronPythonConsole.IronPython.DoInteractive() in f:\Projects\IronPython\IronPythonConsole\IronPython.cs:line 193 From martmaly at exchange.microsoft.com Mon May 23 04:46:02 2005 From: martmaly at exchange.microsoft.com (Martin Maly) Date: Sun, 22 May 2005 19:46:02 -0700 Subject: [IronPython] (no subject) Message-ID: <1DFB396200705E46B5338CA4B2E25BDE0A8685@DF-BANDIT-MSG.exchange.corp.microsoft.com> This is a bug that has been fixed in one of the 0.7.* releases. You can get newest version (0.7.5) of IronPython from http://workspaces.gotdotnet.com/ironpython Martin > -----Original Message----- > From: users-ironpython.com-bounces at lists.ironpython.com > [mailto:users-ironpython.com-bounces at lists.ironpython.com] On > Behalf Of Jon Cosby > Sent: Sunday, May 22, 2005 11:38 AM > To: users-ironpython.com at lists.ironpython.com > Subject: [IronPython] (no subject) > > Is there something preventing me from importing from the > standard Python library in IronPython 0.6? I can import my > own modules, but get a "NotImplementedException" when > importing from the standard library. > > > Jon Cosby > > >>> import sys > >>> sys.path > ['F:\\Projects\\IronPython\\bin', 'C:\\Python23\\Lib', > 'F:\\Projects\\IronPython\\bin\\Projects'] > >>> import myscript > >>> import os > System.NotImplementedException: EmitDel: IronPython.AST.NameExpr > at IronPython.AST.Expr.EmitDel(CodeGen cg) in > f:\Projects\IronPython\IronPython\AST\Expr.cs:line 42 > at IronPython.AST.DelStmt.Emit(CodeGen cg) in > f:\Projects\IronPython\IronPython\AST\Stmt.cs:line 681 > at IronPython.AST.SuiteStmt.Emit(CodeGen cg) in > f:\Projects\IronPython\IronPython\AST\Stmt.cs:line 65 > at IronPython.AST.IfStmt.Emit(CodeGen cg) in > f:\Projects\IronPython\IronPython\AST\Stmt.cs:line 117 > at IronPython.AST.SuiteStmt.Emit(CodeGen cg) in > f:\Projects\IronPython\IronPython\AST\Stmt.cs:line 65 > at IronPython.AST.ModuleDef.Generate(String > sourceFileName) in > f:\Projects\IronPython\IronPython\AST\ModuleDef.cs:line 71 > at IronPython.Objects.Importer.LoadFromSource(String > fullName, String filename, List __path__) in > f:\Projects\IronPython\IronPython\Objects\module.cs:line 260 > at IronPython.Objects.Importer.LoadFromPath(String name, > String fullName, List path) in > f:\Projects\IronPython\IronPython\Objects\module.cs:line 246 > at IronPython.Objects.Importer.LoadTop(String name) in > f:\Projects\IronPython\IronPython\Objects\module.cs:line 210 > at IronPython.Objects.Importer.ImportOne(String fullName, Boolean > keepTop) in f:\Projects\IronPython\IronPython\Objects\module.cs:line > 193 > at IronPython.Objects.module.Import(String fullName, > Boolean keepTop) in > f:\Projects\IronPython\IronPython\Objects\module.cs:line 98 > at IronPython.Objects.Ops.Import(module mod, String > fullName) in > f:\Projects\IronPython\IronPython\Objects\Ops.cs:line 1562 > at input_3.Run(Frame frame) > at IronPythonConsole.IronPython.DoInteractive() in > f:\Projects\IronPython\IronPythonConsole\IronPython.cs:line 193 > > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From redmoon17 at gmail.com Mon May 23 12:15:28 2005 From: redmoon17 at gmail.com (Chu Kevin) Date: Mon, 23 May 2005 18:15:28 +0800 Subject: [IronPython] (no subject) In-Reply-To: <1209.4.243.47.189.1116787092.squirrel@secure.alienhosting.com> References: <1209.4.243.47.189.1116787092.squirrel@secure.alienhosting.com> Message-ID: <41d7f4a9050523031531b2b0ae@mail.gmail.com> use 0.75,it can import most standard lib 2005/5/23, Jon Cosby : > Is there something preventing me from importing from the standard Python > library in IronPython 0.6? I can import my own modules, but get a > "NotImplementedException" when importing from the standard library. > > Jon Cosby > > >>> import sys > >>> sys.path > ['F:\\Projects\\IronPython\\bin', 'C:\\Python23\\Lib', > 'F:\\Projects\\IronPython\\bin\\Projects'] > >>> import myscript > >>> import os > System.NotImplementedException: EmitDel: IronPython.AST.NameExpr > at IronPython.AST.Expr.EmitDel(CodeGen cg) in > f:\Projects\IronPython\IronPython\AST\Expr.cs:line 42 > at IronPython.AST.DelStmt.Emit(CodeGen cg) in > f:\Projects\IronPython\IronPython\AST\Stmt.cs:line 681 > at IronPython.AST.SuiteStmt.Emit(CodeGen cg) in > f:\Projects\IronPython\IronPython\AST\Stmt.cs:line 65 > at IronPython.AST.IfStmt.Emit(CodeGen cg) in > f:\Projects\IronPython\IronPython\AST\Stmt.cs:line 117 > at IronPython.AST.SuiteStmt.Emit(CodeGen cg) in > f:\Projects\IronPython\IronPython\AST\Stmt.cs:line 65 > at IronPython.AST.ModuleDef.Generate(String sourceFileName) in > f:\Projects\IronPython\IronPython\AST\ModuleDef.cs:line 71 > at IronPython.Objects.Importer.LoadFromSource(String fullName, String > filename, List __path__) in > f:\Projects\IronPython\IronPython\Objects\module.cs:line 260 > at IronPython.Objects.Importer.LoadFromPath(String name, String > fullName, List path) in > f:\Projects\IronPython\IronPython\Objects\module.cs:line 246 > at IronPython.Objects.Importer.LoadTop(String name) in > f:\Projects\IronPython\IronPython\Objects\module.cs:line 210 > at IronPython.Objects.Importer.ImportOne(String fullName, Boolean > keepTop) in f:\Projects\IronPython\IronPython\Objects\module.cs:line > 193 > at IronPython.Objects.module.Import(String fullName, Boolean keepTop) > in f:\Projects\IronPython\IronPython\Objects\module.cs:line 98 > at IronPython.Objects.Ops.Import(module mod, String fullName) in > f:\Projects\IronPython\IronPython\Objects\Ops.cs:line 1562 > at input_3.Run(Frame frame) > at IronPythonConsole.IronPython.DoInteractive() in > f:\Projects\IronPython\IronPythonConsole\IronPython.cs:line 193 > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From sumitb at microsoft.com Tue May 24 00:36:30 2005 From: sumitb at microsoft.com (Sumit Basu) Date: Mon, 23 May 2005 15:36:30 -0700 Subject: [IronPython] Contains() doesn't work anymore for sys.modules? Message-ID: IronPython.Objects.Dict dictionaries seem to be changed in a strange way in 0.7.5... In IronPython-0.7.4, >>> sys.modules.Contains("site") True in IronPython-0.7.5 >>>sys.modules.Contains("site") >>> sys.modules.Contains("site") IronPython.Objects.PythonValueError: bad args to this method at IronPython.Objects.ReflectedMethodBase.Call(Object[] args) at IronPython.Objects.Ops.Call(Object func, Object arg0) at input_36.Run(Frame frame) at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) at IronPython.Hosting.PythonEngine.RunInteractive() Looking at the doc string, it seems to want some sort of key-value pair - but Contains should just take a key, no? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimhug at exchange.microsoft.com Tue May 24 00:49:10 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Mon, 23 May 2005 15:49:10 -0700 Subject: [IronPython] Contains() doesn't work anymore for sys.modules? Message-ID: <1DFB396200705E46B5338CA4B2E25BDE0A8909@DF-BANDIT-MSG.exchange.corp.microsoft.com> The underlying implementation of module dictionaries changed from IDictionary to IDictionary. If you're trying to use the CLS methods, you'd want ContainsKey. However, this might easily change again as it should be an internal decision. In fact, it's probably a bug in IronPython that these methods are exposed on module dictionaries at all. You should be doing this in the Pythonic way: 'site' in sys.modules Or if you really want to call a method sys.modules.has_key('site') When possible you should stick with standard Python-style code as it will both be most compatible with other versions of IronPython but also between IronPython and CPython. To what degree IronPython should force you to do this is still an open question, and not one I want to get into today... Thanks - Jim ________________________________________ From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Sumit Basu Sent: Monday, May 23, 2005 3:37 PM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Contains() doesn't work anymore for sys.modules? IronPython.Objects.Dict dictionaries seem to be changed in a strange way in 0.7.5... ? In IronPython-0.7.4, ? >>> sys.modules.Contains("site") True ? in IronPython-0.7.5 ? >>>sys.modules.Contains("site") >>> sys.modules.Contains("site") IronPython.Objects.PythonValueError: bad args to this method ?? at IronPython.Objects.ReflectedMethodBase.Call(Object[] args) ?? at IronPython.Objects.Ops.Call(Object func, Object arg0) ?? at input_36.Run(Frame frame) ?? at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) ?? at IronPython.Hosting.PythonEngine.RunInteractive() ? Looking at the doc string, it seems to want some sort of key-value pair - but Contains should just take a key, no? From redmoon17 at gmail.com Wed May 25 06:50:10 2005 From: redmoon17 at gmail.com (Chu Kevin) Date: Wed, 25 May 2005 12:50:10 +0800 Subject: [IronPython] run in mono? Message-ID: <41d7f4a905052421501a96dcdf@mail.gmail.com> IronPython can support Mono? From alleykat at gmail.com Wed May 25 06:52:19 2005 From: alleykat at gmail.com (Travis Watkins) Date: Tue, 24 May 2005 23:52:19 -0500 Subject: [IronPython] run in mono? In-Reply-To: <41d7f4a905052421501a96dcdf@mail.gmail.com> References: <41d7f4a905052421501a96dcdf@mail.gmail.com> Message-ID: On 5/24/05, Chu Kevin wrote: > IronPython can support Mono? 0.6 works, mono hasn't implemented enough of .NET 2.0 for 0.7 to work -- Travis Watkins http://www.realistanew.com From miguel at ximian.com Wed May 25 06:56:07 2005 From: miguel at ximian.com (Miguel de Icaza) Date: Wed, 25 May 2005 00:56:07 -0400 Subject: [IronPython] run in mono? In-Reply-To: References: <41d7f4a905052421501a96dcdf@mail.gmail.com> Message-ID: <1116996968.6189.205.camel@linux.site> Hello, > > IronPython can support Mono? > > 0.6 works, mono hasn't implemented enough of .NET 2.0 for 0.7 to work Mono 1.1.7 has implemented the missing bits to run 0.7, you can download Mono 1.1.7 from: www.mono-project.com/Downloads I have not tried later versions, but we welcome bug reports. Miguel. From mtaylor at alias.com Wed May 25 22:20:50 2005 From: mtaylor at alias.com (Michael Taylor) Date: Wed, 25 May 2005 16:20:50 -0400 Subject: [IronPython] [0.7.5] ... and the Monkey says ... In-Reply-To: References: Message-ID: <05329796-0240-4C7B-859B-3059A3F72FEB@alias.com> Hey Did this bug get logged? The Mono folk seem interested in this project, so we should take them up on their offer of help. I'm willing to do a little testing and bug logging if it would help. Let me know! Cheers! /\/\ike On May 18, 2005, at 11:07 PM, Keith J. Farmer wrote: > Just FYI: > > > > C:\>MonoPy > > > > C:\>mono "C:\Program Files\IronPython-0.7.5\bin\IronPythonConsole.exe" > > > > > > ** (C:\Program Files\IronPython-0.7.5\bin\IronPythonConsole.exe: > 616): WARNING **: Missing method TryGetValue in assembly C:\Program > Files\IronPython-0.7.5\bin\IronPython.dll, type IDictionary`2 > > IronPython 0.7.5 on .NET 2.0.50215.16 > > Copyright (c) Microsoft Corporation. All rights reserved. > > >>> ^Z > > > > Unhandled Exception: System.NullReferenceException: Object > reference not set to an instance of an object > > in <0x00000> > > in <0x0000b> IronPython.Objects.Dict:items () > > in <0x00028> > IronPython.Objects.ReflectedMethodBase:DumpReflectedCalls () > > in <0x0000a> IronPython.Hosting.PythonEngine:DumpDebugInfo () > > in <0x00072> IronPythonConsole.PythonCommandLine:RunInteractive > (IronPython.Hosting.PythonEngine engine) > > in <0x000a5> IronPythonConsole.PythonCommandLine:Main (System.String > [] rawArgs) > > > > C:\> > > > > ? and ? > > > > >>> from System.Collections.Generic import * > > > > ** (C:\Program Files\IronPython-0.7.5\bin\IronPythonConsole.exe: > 3124): WARNING **: Missing method TryGetValue in assembly C: > \Program Files\IronPython-0.7.5\bin\IronPython.dll, type IDictionary`2 > > System.NullReferenceException: Object reference not set to an > instance of an object > > in <0x00000> > > in <0x0001c> IronPython.Objects.Importer:Import > (IronPython.Objects.PythonModule mod, System.String fullName, > IronPython.Objects.List from) > > in <0x00082> IronPython.Objects.Ops:ImportStar > (IronPython.Objects.PythonModule mod, System.String fullName) > > in <0x00031> input_0:Run (IronPython.Objects.Frame frame) > > in <0x0025a> IronPython.Hosting.PythonEngine:DoOneInteractive > (IronPython.Objects.Frame topFrame) > > in <0x0004c> IronPython.Hosting.PythonEngine:RunInteractive () > > >>> > > > > _______________________________________________ > 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: From kfarmer at thuban.org Wed May 25 23:38:55 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 25 May 2005 14:38:55 -0700 Subject: [IronPython] [0.7.5] ... and the Monkey says ... Message-ID: Not by me.. Perhaps Miguel did? NB: the first item seemed to be a security issue related to saving snippets.dll. The second item (the import bug) would be the one to verify. ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Michael Taylor Sent: Wed 5/25/2005 1:20 PM Did this bug get logged? The Mono folk seem interested in this project, so we should take them up on their offer of help. I'm willing to do a little testing and bug logging if it would help. Let me know! -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3493 bytes Desc: not available URL: From eikeon at eikeon.com Thu May 26 00:32:13 2005 From: eikeon at eikeon.com (Daniel Krech) Date: Wed, 25 May 2005 18:32:13 -0400 Subject: [IronPython] run in mono? In-Reply-To: <1116996968.6189.205.camel@linux.site> References: <41d7f4a905052421501a96dcdf@mail.gmail.com> <1116996968.6189.205.camel@linux.site> Message-ID: <1149C2A3-F762-416B-B762-0B736D4A4DEA@eikeon.com> FYI, Installing Mono 1.1.7 from the downloads page onto OS X 10.4.1 I get the following: dsl092-168-155:~/Desktop/IronPython-0.7.5/bin eikeon$ mono IronPythonConsole.exe ** (IronPythonConsole.exe:2970): WARNING **: Missing method TryGetValue in assembly /Users/eikeon/Desktop/IronPython-0.7.5/bin/ IronPython.dll, type IDictionary`2 IronPython 0.7.5 on .NET 2.0.50215.16 Copyright (c) Microsoft Corporation. All rights reserved. >>> print "Hello" ** (IronPythonConsole.exe:2970): WARNING **: Missing method TryGetValue in assembly /Users/eikeon/Desktop/IronPython-0.7.5/bin/ IronPython.dll, type IDictionary`2 System.NullReferenceException: Object reference not set to an instance of an object in <0x00000> in <0x00038> IronPython.Objects.ReflectedType:TryGetAttr (System.Object self, System.String name, System.Object ret) in <0x00034> IronPython.Objects.ReflectedType:TryGetAttr (System.Object self, System.String name, System.Object ret) in <0x00058> IronPython.Objects.DynamicType:GetAttr (System.Object self, System.String name) in <0x00200> IronPython.Objects.Ops:GetAttr (System.Object o, System.String name) in <0x00020> IronPython.Objects.Ops:CheckSoftspace (System.Object f) in <0x00018> IronPython.Objects.Ops:WriteSoftspace (System.Object f) in <0x00024> IronPython.Objects.Ops:PrintWithDestNoNewline (System.Object dest, System.Object o) in <0x0001c> IronPython.Objects.Ops:PrintWithDest (System.Object dest, System.Object o) in <0x00020> IronPython.Objects.Ops:Print (System.Object o) in <0x00048> input_0:Run (IronPython.Objects.Frame frame) in <0x0033c> IronPython.Hosting.PythonEngine:DoOneInteractive (IronPython.Objects.Frame topFrame) in <0x00064> IronPython.Hosting.PythonEngine:RunInteractive () >>> On May 25, 2005, at 12:56 AM, Miguel de Icaza wrote: > Hello, > > >>> IronPython can support Mono? >>> >> >> 0.6 works, mono hasn't implemented enough of .NET 2.0 for 0.7 to work >> > > Mono 1.1.7 has implemented the missing bits to run 0.7, you can > download > Mono 1.1.7 from: > > www.mono-project.com/Downloads > > I have not tried later versions, but we welcome bug reports. > > Miguel. > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From mtaylor at alias.com Thu May 26 02:29:19 2005 From: mtaylor at alias.com (Michael Taylor) Date: Wed, 25 May 2005 20:29:19 -0400 Subject: [IronPython] [0.7.5] ... and the Monkey says ... In-Reply-To: <295e750a05051904306dfe47ad@mail.gmail.com> References: <295e750a05051904306dfe47ad@mail.gmail.com> Message-ID: <580814C4-3672-4A3C-B89E-DE5AA69D0E2C@alias.com> Logged at Ximian as bug 75048. Looks like the 2.0 Dictionary implementation in mono isn't complete yet. Cheers! /\/\ike Taylor On May 19, 2005, at 7:30 AM, Zoltan Varga wrote: > Hi, > > I you run IronPython on mono, things don't seem to work, and you > think it is due to a > mono bug (like this one), then please report it at our bug tracking > system: > > http://bugzilla.ximian.com > > thanks > > Zoltan > > On 5/19/05, Keith J. Farmer wrote: > >> >> >> >> Just FYI: >> >> >> >> C:\>MonoPy >> >> >> >> C:\>mono "C:\Program Files\IronPython-0.7.5\bin >> \IronPythonConsole.exe" >> >> >> >> >> >> ** (C:\Program >> Files\IronPython-0.7.5\bin\IronPythonConsole.exe:616): >> WARNING **: Missing method TryGetValue in assembly C:\Program >> Files\IronPython-0.7.5\bin\IronPython.dll, type IDictionary`2 >> >> IronPython 0.7.5 on .NET 2.0.50215.16 >> >> Copyright (c) Microsoft Corporation. All rights reserved. >> >> >>>>> ^Z >>>>> >> >> >> >> Unhandled Exception: System.NullReferenceException: Object >> reference not set >> to an instance of an object >> >> in <0x00000> >> >> in <0x0000b> IronPython.Objects.Dict:items () >> >> in <0x00028> >> IronPython.Objects.ReflectedMethodBase:DumpReflectedCalls >> () >> >> in <0x0000a> IronPython.Hosting.PythonEngine:DumpDebugInfo >> () >> >> in <0x00072> >> IronPythonConsole.PythonCommandLine:RunInteractive >> (IronPython.Hosting.PythonEngine engine) >> >> in <0x000a5> IronPythonConsole.PythonCommandLine:Main >> (System.String[] rawArgs) >> >> >> >> C:\> >> >> >> >> ? and ? >> >> >> >> >>>>> from System.Collections.Generic import * >>>>> >> >> >> >> ** (C:\Program >> Files\IronPython-0.7.5\bin\IronPythonConsole.exe:3124): >> WARNING **: Missing method TryGetValue in assembly C:\Program >> Files\IronPython-0.7.5\bin\IronPython.dll, type IDictionary`2 >> >> System.NullReferenceException: Object reference not set to an >> instance of an >> object >> >> in <0x00000> >> >> in <0x0001c> IronPython.Objects.Importer:Import >> (IronPython.Objects.PythonModule mod, System.String fullName, >> IronPython.Objects.List from) >> >> in <0x00082> IronPython.Objects.Ops:ImportStar >> (IronPython.Objects.PythonModule mod, System.String fullName) >> >> in <0x00031> input_0:Run (IronPython.Objects.Frame frame) >> >> in <0x0025a> >> IronPython.Hosting.PythonEngine:DoOneInteractive >> (IronPython.Objects.Frame topFrame) >> >> in <0x0004c> IronPython.Hosting.PythonEngine:RunInteractive >> () >> >> >>>>> >>>>> >> >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From firemoth at gmail.com Thu May 26 08:58:34 2005 From: firemoth at gmail.com (Timothy Fitz) Date: Thu, 26 May 2005 02:58:34 -0400 Subject: [IronPython] Array Access Problem In-Reply-To: <6C91A34F0BB48B40A86F1E146B7A049201C802CF@df-fido-msg.exchange.corp.microsoft.com> References: <6C91A34F0BB48B40A86F1E146B7A049201C802CF@df-fido-msg.exchange.corp.microsoft.com> Message-ID: <972ec5bd05052523581586ba99@mail.gmail.com> On 5/10/05, Jim Hugunin wrote: > >>> apt[0] = pt > What do we do here? We need to copy the data in pt into apt[0]. This > is what it means to have an array of structs. No matter what we do with > proxies or wrappers there's no way out of this copy. We could add some > kind of pointer to the ValueProxy keeping track of the fact that > there's a copy of this variable now held in apt[0]. This would need to > be an arbitrarily large list of pointers. This list would also be easy > to break with CLI code that directly modified apt or other containers > holding on to the value types. I thought I understood this, but now I'm second guessing myself. Why can't >>> apt[0] = pt indicate a copy by value if apt is a CLI array? Python lists would still get a reference to ValueProxy. >>> pt = apt[0] Here ValueProxy would be a reference to apt[0], so pt.x += 10 is still fine. What am I missing? > > >>> pt.X = 0 > The only way this can modify apt[0] is if we keep the full list of > references in ValueProxy. See above for why keeping that full list > still wouldn't always work. > > >>> apt[0].X = 0 > This example would work using the ValueProxy that pointed to apt[0]; > however, when apt[0] is assigned to a variable the situation becomes as > bad as it is for pt. > > >>> for pt in apt: > >>> pt.X = 0 > The for loop uses an Enumerator to loop through the points in apt. > Without constructing a custom enumerator for arrays there's no way to > get anything but copy semantics here. While we could build a custom > enumerator for arrays this wouldn't solve the general case of value > types being returned from methods. > > When I played with this example in C#, I discovered something > interesting: > > Point[] pa = new Point[3]; > foreach (Point p in pa) { > pt.X = 10; > } > > The code above generates an error from the C# compiler: > "Cannot modify members of 'p' because it is a 'foreach iteration > variable'" > > The C# compiler is treating these iteration variables as semi-immutable > in order to minimize the confusion that can come from the copy semantics > of value types. This seems like a promising idea... > > > > (2) Make value types immutable (or at least the ones you grab from > > > collections) > > All of the problems with value types stem from their mutability. Nobody > ever complains that int, double, char, etc. are value types because > those are all immutable. For immutable objects there's no difference > between pass by reference and pass by value. > > The CLR team's API Design Guidelines say this: > - Do not create mutable value types. > http://blogs.msdn.com/kcwalina/archive/2004/09/28/235232.aspx > (or see here - http://peter.golde.org/2003/10/13.html#a16) > > In some ways, this would be just reflecting in IronPython this good > design sense. > > One advantage of immutability is that it would make failures like the > following much more obvious: > > >>> apt[0].X = 0 > If value types were immutable this would throw. The exception message > might give people enough information to get started tracking down the > issue and modifying their code to work correctly. > > What are the problems with this approach? > > 1. C#/VB examples won't port very naturally to IronPython and the docs > will need a section explaining the various workarounds to the fact that > IronPython doesn't support this idiom. This isn't ideal, but I could > easily live with this doc burden. > > 2. There's no way that I know of to make a value type 100% immutable > without controlling its implementation. IronPython could block setting > of fields and properties on value types, but there's no way to reliably > detect and block all sets that came through methods. Just getting the > properties and fields would probably cover 95% of the cases where people > try to mutate a value type, but it seems pretty awkward to me to say > that value types in IronPython are sort-of immutable unless there are > mutating methods. The fact that this is what the C# compiler does for > iteration variables is encouraging at least in that it's a precedent. > > 3. There might be things that are impossible to express with this > restriction. I don't think that's true, particularly with the use of > named parameters to initialize fields and properties in the value type's > constructor. However, one of the principles of IronPython is that it > should be able to use any CLS library and it's possible there's some > weird library design with value types that wouldn't work if they were > considered virtually immutable by IronPython. > > If we went down the immutable value type route, it would be interesting > to look at different kinds of sugar that could be provided to make the > impact on most programs less than it currently is. > > -Jim > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From bob at redivi.com Thu May 26 10:56:05 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 26 May 2005 01:56:05 -0700 Subject: [IronPython] Array Access Problem In-Reply-To: <6C91A34F0BB48B40A86F1E146B7A049201C802CF@df-fido-msg.exchange.corp.microsoft.com> References: <6C91A34F0BB48B40A86F1E146B7A049201C802CF@df-fido-msg.exchange.corp.microsoft.com> Message-ID: <6AD8A2ED-9B4D-47B3-B263-B6C0AFB86F1A@redivi.com> On May 10, 2005, at 10:57 AM, Jim Hugunin wrote: >> Bob Ippolito wrote: >> >>> (1) Don't have mutable value types, use a reference type that points >>> to a value type (some kind of proxy) >>> > > I don't think that this is possible to do in a consistent way and my > suspicion is that doing this half-way would be more confusing than not > doing it at all. Let's walk through the original example: > > >>>> apt = Array.CreateInstance(Point, 1) >>>> > This creates a true CLI array of Point structs > > >>>> pt = Point(1,2) >>>> > Today this makes a new Point struct and returns the boxed version of > that struct. We could instead return a new instance of an > imaginary new > type, ValueProxy. This new instance is a standard reference > type > that holds a point as its data. This proxy will need to forward all > field, property and method accesses to the contained Point struct. > > >>>> apt[0] = pt >>>> > What do we do here? We need to copy the data in pt into apt[0]. This > is what it means to have an array of structs. No matter what we do > with > proxies or wrappers there's no way out of this copy. We could add > some > kind of pointer to the ValueProxy keeping track of the fact > that > there's a copy of this variable now held in apt[0]. This would > need to > be an arbitrarily large list of pointers. This list would also be > easy > to break with CLI code that directly modified apt or other containers > holding on to the value types. > > >>>> pt.X = 0 >>>> > The only way this can modify apt[0] is if we keep the full list of > references in ValueProxy. See above for why keeping that full list > still wouldn't always work. > > >>>> apt[0].X = 0 >>>> > This example would work using the ValueProxy that pointed to apt[0]; > however, when apt[0] is assigned to a variable the situation > becomes as > bad as it is for pt. > > >>>> for pt in apt: >>>> pt.X = 0 >>>> > The for loop uses an Enumerator to loop through the points in apt. > Without constructing a custom enumerator for arrays there's no way to > get anything but copy semantics here. While we could build a custom > enumerator for arrays this wouldn't solve the general case of value > types being returned from methods. > > When I played with this example in C#, I discovered something > interesting: > > Point[] pa = new Point[3]; > foreach (Point p in pa) { > pt.X = 10; > } > > The code above generates an error from the C# compiler: > "Cannot modify members of 'p' because it is a 'foreach iteration > variable'" > > The C# compiler is treating these iteration variables as semi- > immutable > in order to minimize the confusion that can come from the copy > semantics > of value types. This seems like a promising idea... Actually the idea I had was different -- leaving boxed type handling as-is, but the __getitem__ of the Point[] instance would return "ValueProxy" instances.. which would give you similar semantics to C# -- as long as you don't keep it around for a long time. Of course, you could deviate from standard Python a little bit and have an optional extension to the __getitem__ protocol that would recognize that the __getitem__ is really just to find a "pointer" so that it can set an attribute somewhere. __getitemforsetattr__ or something... I only really had that idea because it would fix the reported bug, you're probably right about how it's currently half-implemented being more confusing.. however, I think it might be less confusing than the current state. >>> (2) Make value types immutable (or at least the ones you grab from >>> collections) >>> > > All of the problems with value types stem from their mutability. > Nobody > ever complains that int, double, char, etc. are value types because > those are all immutable. For immutable objects there's no difference > between pass by reference and pass by value. > > The CLR team's API Design Guidelines say this: > - Do not create mutable value types. > http://blogs.msdn.com/kcwalina/archive/2004/09/28/235232.aspx > (or see here - http://peter.golde.org/2003/10/13.html#a16) > > In some ways, this would be just reflecting in IronPython this good > design sense. > > One advantage of immutability is that it would make failures like the > following much more obvious: > > >>>> apt[0].X = 0 >>>> > If value types were immutable this would throw. The exception message > might give people enough information to get started tracking down the > issue and modifying their code to work correctly. > > What are the problems with this approach? > > 1. C#/VB examples won't port very naturally to IronPython and the docs > will need a section explaining the various workarounds to the fact > that > IronPython doesn't support this idiom. This isn't ideal, but I could > easily live with this doc burden. > > 2. There's no way that I know of to make a value type 100% immutable > without controlling its implementation. IronPython could block > setting > of fields and properties on value types, but there's no way to > reliably > detect and block all sets that came through methods. Just getting the > properties and fields would probably cover 95% of the cases where > people > try to mutate a value type, but it seems pretty awkward to me to say > that value types in IronPython are sort-of immutable unless there are > mutating methods. The fact that this is what the C# compiler does for > iteration variables is encouraging at least in that it's a precedent. > > 3. There might be things that are impossible to express with this > restriction. I don't think that's true, particularly with the use of > named parameters to initialize fields and properties in the value > type's > constructor. However, one of the principles of IronPython is that it > should be able to use any CLS library and it's possible there's some > weird library design with value types that wouldn't work if they were > considered virtually immutable by IronPython. > > If we went down the immutable value type route, it would be > interesting > to look at different kinds of sugar that could be provided to make the > impact on most programs less than it currently is. In PyObjC we have similar problems to this.. the mutable value type problem exists, but isn't a problem in practice because people Just Don't Do That. What *is* a problem is that Foundation has a mutable string type. Now this sounds like a small problem at first, but since Foundation NSDictionary is key-copying, mutable strings are hashable and are allowed to pass for a regular string anywhere. Also, since unicode objects are immutable in Python and their hash can not change, weird things can happen. In practice, this is also not a problem (anymore). From Python, the NSMutableString is bridged to a subclass of unicode. So, it has a copy of the contents at the time of its creation, and all of the Python methods will behave as documented since they are using Python's implementation. However, it also has all of the methods of NSMutableString and they also act correctly. In order to get an updated Python representation, you simply call some Objective-C- implemented-method that will return the object again and you'll get a new proxy (normally proxies are guaranteed unique so "is" works, but this is not true for most classes that we conveniently bridge to immutable Python built-in types). Fortunately, the NSObject protocol has a "self" instance method that will return that instance .. >>> from Foundation import * >>> s = NSMutableString.string() >>> s u'' >>> hash(s) 0 >>> s.description() u'' >>> s.appendString_('foo') >>> hash(s) 0 >>> s u'' >>> s.description() u'foo' >>> s.self() u'foo' It looks confusing in a contrived example like this, but in practice you're generally either using one set of methods or the other.. so I've never been confused by it and we haven't had any complaints. You could provide some similar workaround, with a function or method that mutates a field (because unlike in the PyObjC case, you're not guaranteed mutating methods). -bob From redmoon17 at gmail.com Fri May 27 08:27:22 2005 From: redmoon17 at gmail.com (Chu Kevin) Date: Fri, 27 May 2005 14:27:22 +0800 Subject: [IronPython] not support Mixin Message-ID: <41d7f4a905052623271aca1ba3@mail.gmail.com> I run this code: [John at mars /tmp]# vi Lover.py class lover: def __init__(self,man='man',woman='woman'): self.lover='When a '+man+' love a '+woman print self.lover def smile(self): print self.lover+':-)' def kiss(self): print self.lover+':-)(-:' [John at mars /tmp]# python Python 2.1 (#1, Apr 18 2001, 17:55:45) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>>from Lover import lover >>>John_and_Rose=lover() When a man love a woman >>>John_and_Rose.smile() when a man love a woman:-) >>>John_and_Rose.kiss() when a man love a woman:-)(-: >>>John_and_Rose.sayGoodBye() Traceback (most recent call last): File "", line 1, in ? AttributeError: lover instance has no attribute 'sayGoodBye' >>>John_and_rose.JohnAskWhy() Traceback (most recent call last): File "", line 1, in ? AttributeError: lover instance has no attribute 'JohnAskWhy' >>>class RoseLoveSomebodyElse: def sayGoodBye(self): print "Let's say goodbye tonight." >>>lover.__bases__+=(RoseLoveSomebodyElse,) >>>John_and_Rose.sayGoodBye() Let's say goodbye tonight. >>> a error occur IronPython.Objects.PythonAttributeError: 'lover' object has no attribute 'sayGoodBye' at IronPython.Objects.Ops.GetAttr(Object o, String name) at input_8.Run(Frame frame) at IronPython.Hosting.PythonEngine.DoOneInteractive(Frame topFrame) at IronPython.Hosting.PythonEngine.RunInteractive() From ben.siemon at gmail.com Fri May 27 18:21:25 2005 From: ben.siemon at gmail.com (Ben Siemon) Date: Fri, 27 May 2005 09:21:25 -0700 Subject: [IronPython] compiling python libraries into assemblies Message-ID: I need to convert a python file to an assembly. It needs to import os and use the Crypto module. Is it possible to obtain the source for these libraries and use them in the Iron Python Console? -- cheers Ben Siemon 254 723 6937 cs.baylor.edu/~siemon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimhug at exchange.microsoft.com Fri May 27 19:04:15 2005 From: jimhug at exchange.microsoft.com (Jim Hugunin) Date: Fri, 27 May 2005 10:04:15 -0700 Subject: [IronPython] not support Mixin Message-ID: <1DFB396200705E46B5338CA4B2E25BDE101A1A@DF-BANDIT-MSG.exchange.corp.microsoft.com> Chu Kevin wrote: > >>>class RoseLoveSomebodyElse: > def sayGoodBye(self): > print "Let's say goodbye tonight." > > >>>lover.__bases__+=(RoseLoveSomebodyElse,) > > >>>John_and_Rose.sayGoodBye() > a error occur > > IronPython.Objects.PythonAttributeError: 'lover' object has no > attribute 'sayGoodBye' Thanks for the entertaining and yet still self-contained repro. It's a lot more fun than a lot of foo's and bar's. Unsurprisingly, you've found a bug. The bug is that __bases__ on old-style Python classes isn't settable. This is a simple bug to fix and we'll fix it for 0.7.6. The same bug is present for __dict__ on old-style classes - but not anymore on old-style instances (as of 0.7.5). There are a few similar attributes and we'll try to get most if not all of them in this space this time around. In IronPython's implementation, there has been more focus on new-style classes as they are presumably the future direction of Python's classes and they also are the route to the best integration with CLS types. If you change your example to make both lover and RoseLoveSomebodyElse extend object - and thus make them Python new-style classes - your example will run under IronPython. (Note: You will then discover that this changed example won't run in CPython with a complaint about no consistent MRO between object and RoseLoveSomebodyElse. So, we still have more work to do.) Thanks for the interesting bug - Jim From jon at jcosby.com Sun May 29 19:17:50 2005 From: jon at jcosby.com (Jon Cosby) Date: Sun, 29 May 2005 10:17:50 -0700 (PDT) Subject: [IronPython] Readlines Message-ID: <1317.4.243.43.130.1117387070.squirrel@secure.alienhosting.com> I see IronPython does not have the CPython readlines method. Is this an oversight? Jon Cosby From jon at jcosby.com Sun May 29 20:21:51 2005 From: jon at jcosby.com (Jon Cosby) Date: Sun, 29 May 2005 11:21:51 -0700 (PDT) Subject: [IronPython] Cmath Message-ID: <1446.4.243.44.236.1117390911.squirrel@secure.alienhosting.com> If anyone is interested, I have a cmath module to extend Complex64. It's equivalent to the cpython cmath. http://www.jcosby.com/csharp/cmath.zip Jon Cosby From kfarmer at thuban.org Sun May 29 20:50:33 2005 From: kfarmer at thuban.org (Keith J. Farmer) Date: Sun, 29 May 2005 11:50:33 -0700 Subject: [IronPython] Cmath Message-ID: Getting archive corruption errors from WinZip -----Original Message----- From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Jon Cosby Sent: Sunday, May 29, 2005 11:22 AM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Cmath If anyone is interested, I have a cmath module to extend Complex64. It's equivalent to the cpython cmath. http://www.jcosby.com/csharp/cmath.zip From jon at jcosby.com Sun May 29 21:12:27 2005 From: jon at jcosby.com (Jon Cosby) Date: Sun, 29 May 2005 12:12:27 -0700 (PDT) Subject: [IronPython] Cmath In-Reply-To: References: Message-ID: <1636.4.243.45.202.1117393947.squirrel@secure.alienhosting.com> No problem in UltimateZip. Try this: http://www.jcosby.com/csharp/cmath.cs > Getting archive corruption errors from WinZip > > -----Original Message----- > From: users-ironpython.com-bounces at lists.ironpython.com > [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of > Jon Cosby > Sent: Sunday, May 29, 2005 11:22 AM > To: users-ironpython.com at lists.ironpython.com > Subject: [IronPython] Cmath > > If anyone is interested, I have a cmath module to extend Complex64. It's > equivalent to the cpython cmath. > > http://www.jcosby.com/csharp/cmath.zip > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From jon at jcosby.com Sun May 29 21:12:27 2005 From: jon at jcosby.com (Jon Cosby) Date: Sun, 29 May 2005 12:12:27 -0700 (PDT) Subject: [IronPython] Cmath In-Reply-To: References: Message-ID: <1636.4.243.45.202.1117393947.squirrel@secure.alienhosting.com> No problem in UltimateZip. Try this: http://www.jcosby.com/csharp/cmath.cs > Getting archive corruption errors from WinZip > > -----Original Message----- > From: users-ironpython.com-bounces at lists.ironpython.com > [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of > Jon Cosby > Sent: Sunday, May 29, 2005 11:22 AM > To: users-ironpython.com at lists.ironpython.com > Subject: [IronPython] Cmath > > If anyone is interested, I have a cmath module to extend Complex64. It's > equivalent to the cpython cmath. > > http://www.jcosby.com/csharp/cmath.zip > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From hessammehr at gmail.com Tue May 31 19:04:02 2005 From: hessammehr at gmail.com (S. Hessam Moosavi Mehr) Date: Tue, 31 May 2005 21:34:02 +0430 Subject: [IronPython] Cannot run executable Message-ID: <429c9911.1e0c38d4.4a9b.2c73@mx.gmail.com> When I try to run any .exe generated by IronPython, I get the following error: [application name here] is not a valid Win32 application. I have IronPython 0.7.5 and .net Framework 2.0.50215 How can I fix this problem? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From carrillog.luis at gmail.com Tue May 31 21:26:56 2005 From: carrillog.luis at gmail.com (Luis Carrillo) Date: Tue, 31 May 2005 14:26:56 -0500 Subject: [IronPython] Any have one good reason to use .NET Framework v2.0 with IronPython Message-ID: Why I need to update the .NET Framework v2.0 with revisions 50215, knowing that this version is BETA!!, I work with v1.2, and I don't need one upgrade yet. Why not work it?? with early versions of .NET or give more options to downloads, like IronPython 0.7.5 to .NET Fram.. v.1.0 or v.1.2, Thanks 4 your time when u reply me... From almondb at gmail.com Tue May 31 22:21:31 2005 From: almondb at gmail.com (Brian Almond) Date: Tue, 31 May 2005 13:21:31 -0700 Subject: [IronPython] Any have one good reason to use .NET Framework v2.0 with IronPython In-Reply-To: References: Message-ID: <21f1e27005053113215423e65d@mail.gmail.com> On 5/31/05, Luis Carrillo wrote: > > Why I need to update the .NET Framework v2.0 with revisions 50215, > knowing that this version is BETA!! Of course, IronPython isn't exactly production stable. Jim H. recently said: > This change was accidental and not a deliberate attempt to force people to > upgrade; nevertheless, at this stage of the project I suspect that more of > this sort of thing will happen from time to time. That's part of the price > of 0.7.x software. We'll try to at least give you better warning in the > future. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dw at botanicus.net Tue May 31 21:29:49 2005 From: dw at botanicus.net (David Wilson) Date: Tue, 31 May 2005 20:29:49 +0100 Subject: [IronPython] Any have one good reason to use .NET Framework v2.0 with IronPython In-Reply-To: References: Message-ID: <429CBB2D.4060609@botanicus.net> Luis Carrillo wrote: > Why I need to update the .NET Framework v2.0 with revisions 50215, > knowing that this version is BETA!!, I work with v1.2, and I don't > need one upgrade yet. > Why not work it?? with early versions of .NET or give more options to > downloads, like IronPython 0.7.5 to .NET Fram.. v.1.0 or v.1.2, > Thanks 4 your time when u reply me... Hi there, From my understanding of the situation, a number of enhancements to .NET 2.0 are specifically geared for implementing languages such as IronPython. It does not seem unreasonable to me that a beta implementation of IronPython has a beta implementation of .NET as a prerequisite. :) By the time IronPython makes it to 1.0, .NET 2.0 will probably be released also. David.