[IronPython] IDLE like functionality
Hi, A beginner's question: Is there a tutorial/demo/sample project to show how embed IDLE like functionality in C# WinForms application? So basically I'd like to add interactive command line to my application, but of course all other features of IDLE (eg debugging, code editors etc) must be left out. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] pywin32 on Iron Python?
Dave Fugate wrote: That said, there is something extremely useful the community can do for IronPython that our team simply cannot: get 3rd party Python applications such as Django, pywin32, NumPy, etc running under IronPython. This could mean adapting something like adodbapi.py to utilize IronPython APIs similar to what Vernon Cole did, or re-implementing NumPy's C-based modules in C#. NumPy works pretty well already (under ironclad*). I suspect that in circumstances where managedness is so important that the CPython numpy can't be used, one would be better off using a preexisting .NET library than trying to rewrite parts of NumPy. Also, I just performed a quick test on pywin32 under ironclad and, once I added the 'pythonwin', 'win32', and 'win32\lib' folders from site-packages to sys.path, was able to call win32api.GetComputerName without problems. Not all of it will work, but see the numpy-related footnote below. Cheers william * and if it doesn't do what you need, or if what you need is too slow, please let me know and I'll do my best to fix it :-) ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IDLE like functionality
Hi Harriv, You could start by looking at http://www.ironpython.info/index.php/Contents#Tools_and_Utilities There's a couple of web and desktop IronPython shells there. Davy On Wed, Apr 29, 2009 at 9:21 AM, Harriv har...@gmail.com wrote: Hi, A beginner's question: Is there a tutorial/demo/sample project to show how embed IDLE like functionality in C# WinForms application? So basically I'd like to add interactive command line to my application, but of course all other features of IDLE (eg debugging, code editors etc) must be left out. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IDLE like functionality
Davy Mitchell wrote: Hi Harriv, You could start by looking at http://www.ironpython.info/index.php/Contents#Tools_and_Utilities There's a couple of web and desktop IronPython shells there. There is also IronTextBox which is an IronPython console in a Windows Forms TextBox You will probably need to update it for 2.0.1 but it is probably what you want. http://www.codeproject.com/KB/edit/irontextbox2.aspx Michael Davy On Wed, Apr 29, 2009 at 9:21 AM, Harriv har...@gmail.com wrote: Hi, A beginner's question: Is there a tutorial/demo/sample project to show how embed IDLE like functionality in C# WinForms application? So basically I'd like to add interactive command line to my application, but of course all other features of IDLE (eg debugging, code editors etc) must be left out. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] sys._getframe(n)?
Is it true that the dev team is considering implementing sys._getframe(n) where n 0? I'd love to see this since my understanding is that this is a stumbling block for running IronPython under IPython. Is there an issue number on CodePlex on this that I can vote for? Thanks, Mike ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IDLE like functionality
Actually, the code editor for IDLE (and pythonwin) is written in Python, so no, it does not have to be left out. Since pythonwin is a native WinForms application, it would be a great example project for how to do it. If pywin32 were ported to IronPython it would be done. On Wed, Apr 29, 2009 at 2:21 AM, Harriv har...@gmail.com wrote: Hi, A beginner's question: Is there a tutorial/demo/sample project to show how embed IDLE like functionality in C# WinForms application? So basically I'd like to add interactive command line to my application, but of course all other features of IDLE (eg debugging, code editors etc) must be left out. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IDLE like functionality
Vernon Cole wrote: Actually, the code editor for IDLE (and pythonwin) is written in Python, so no, it does not have to be left out. IDLE uses Tkinter - which theoretically *might* work under Ironclad but unless there is a managed version of Tk/Tcl no-one is likely to port it. Since pythonwin is a native WinForms application, PythonWin does not use Windows Forms it uses win32. Michael it would be a great example project for how to do it. If pywin32 were ported to IronPython it would be done. On Wed, Apr 29, 2009 at 2:21 AM, Harriv har...@gmail.com wrote: Hi, A beginner's question: Is there a tutorial/demo/sample project to show how embed IDLE like functionality in C# WinForms application? So basically I'd like to add interactive command line to my application, but of course all other features of IDLE (eg debugging, code editors etc) must be left out. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IDLE like functionality
Eagle is a managed version of TCL (that's also hosted on Codeplex) but I doubt that the more-important Tk part is there :). On Wed, Apr 29, 2009 at 6:24 AM, Michael Foord fuzzy...@voidspace.org.ukwrote: Vernon Cole wrote: Actually, the code editor for IDLE (and pythonwin) is written in Python, so no, it does not have to be left out. IDLE uses Tkinter - which theoretically *might* work under Ironclad but unless there is a managed version of Tk/Tcl no-one is likely to port it. Since pythonwin is a native WinForms application, PythonWin does not use Windows Forms it uses win32. Michael it would be a great example project for how to do it. If pywin32 were ported to IronPython it would be done. On Wed, Apr 29, 2009 at 2:21 AM, Harriv har...@gmail.com wrote: Hi, A beginner's question: Is there a tutorial/demo/sample project to show how embed IDLE like functionality in C# WinForms application? So basically I'd like to add interactive command line to my application, but of course all other features of IDLE (eg debugging, code editors etc) must be left out. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] pywin32 on Iron Python?
On Tue, Apr 28, 2009 at 5:32 PM, Jeff Hardy jdha...@gmail.com wrote: Hi Dave, On Tue, Apr 28, 2009 at 10:37 AM, Dave Fugate dfug...@microsoft.com wrote: That said, there is something extremely useful the community can do for IronPython that our team simply cannot: get 3rd party Python applications such as Django, pywin32, NumPy, etc running under IronPython. This could mean adapting something like adodbapi.py to utilize IronPython APIs similar to what Vernon Cole did, or re-implementing NumPy's C-based modules in C#. While it's quite difficult (impossible?) for anyone on our team to submit changes supporting IronPython back to other OSS projects, the rest of the IronPython Community happily doesn't have this limitation. Dave: My condolences on having to put up with the lawyers. I have to sleep with one, but at least she doesn't tell me who I can contribute code to. ;-) -- VC The problem with this approach is that I don't really want to clutter up e.g. Django with workarounds for IP bugs that are actually incompatibilities with CPython - they should and will get fixed in IP at some point. If it's a legitimate platform difference, or an invalid assumption by Django, then it can be fixed there - but I've found very few of those relative to bugs in IP itself. That's true. There is still one outstanding bug in adodbapi on iron which I hope will eventually be fixed in IPy. (see Work Item # 18222 -- August 2008) The workaround was just too large to use and would still have left the IPy COM implementation with a bug. When the COM bug gets fixed that last test failure will go away. There are other places where if IronPython: made sense and was used. (I also included simple workarounds for bugs like #18223.) -- VC Also, would it possible for you guys to revisit your commit messages? I would at least like to see a note in the CP commit messages when a particular CP issue has been fixed. + 1. Maybe my bug has already been fixed and I don't know. -- VC If anyone wants to contribute in this manner, please just give us a heads up so we can obtain permission to add tests for the 3rd party app(s) to our checkin system. Also, if there's enough interest in this I can setup a wiki page on CodePlex to keep track of whose working on what... +1 on the wiki page. Now this is interesting! Last time I checked, Django's test suite was nowhere near passing - would the full test suite have to pass before you'd include it? In other words, how good do we have to get? I really appreciate the work you guys are doing here. It can't be easy swimming against the tide all the time! - Jeff Amen! -- VC ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [wingide-users] Using Wing IDE with IronPython - autocomplete for .NET objects (PI file generator)
Hello all, Attached is an updated script for generating PI files to provide autocomplete on standard .NET objects. It now handles all the standard .NET member types (including static properties, enumeration fields, indexers, events and so on). It also recurses into sub-namespaces generating new pi-files for all of them. This script is hardcoded to add references to, and then generate PI files for: System System.Data System.Drawing System.Windows.Forms It generates 90 pi files (90 namespaces) taking up 24mb! The autocomplete it provides is awesome though. :-) I had to do a fair bit of violence to the standard generate_pi.py script so I *doubt* it is desirable to merge it back in. Obviously very happy for this to be included with Wing if you want, or merged if you think it is worth it. Is it ok for me to offer this for download from my site? If I make further changes I will email this list. The big thing to add is the return type for methods. Is it possible to specify return types for properties? (Currently any attribute without an obvious parallel in Python I have turned into a property in the PI files). The only real caveat with the current script (that I am aware of - bug reports and contributions welcomed) is that None is a common enumeration field member. This is invalid syntax in Python, so I rename these to None_. There are quite a few minor changes sprinkled through the code - plus the __main__ part of the script is very different. I have tried to mark changes with a # CHANGE: comment, but it should be relatively amenable to diffing anyway... For reference I was using IronPython 2.0.1, with .NET 3.5 installed and Wing 3.2beta 1. All the best, Michael Foord Michael Foord wrote: Hello all, I've created a modified version of the 'generate_pi.py' which generates the interface files for .NET libraries. It is attached. At the moment it generates PI files for the following assemblies / namespaces (hardwired at the bottom of the code): System System.Data System.Drawing System.Windows.Forms To run it, create a new directory and add this to the 'Interface File Path' (File menu - Preferences - Source Analysis - Advanced - Insert). Then from the command line switch to this directory (if you are on Vista you will need to run cmd with admin privileges due to a defect explained below). Execute the command: ipy generate_pi_for_net.py This generates the pi files. It doesn't work *as well* on 64 bit windows because the .NET XML help files (or whatever they are called) are in a different location so the docstrings are not always available - which is why I am not just distributing the pi files yet. The script doesn't yet understand static properties on classes - so it actually *fetches* static properties rather than looking at the descriptor (which is available in the class __dict__ so should be easy to fix). This is what causes inadvertent registry lookups etc and therefore requires admin privileges. It doesn't yet understand multiple overloads. This may require a change to Wing or may not matter. It isn't yet able to do anything with the information about return types - which would allow Wing to know the type of objects returned by methods. This may be easy to add? It is late so I am going to bed. At some point I will explain the simple changes I had to make to the standard generate_pi.py script (although they are mostly straightforward). I will also do further work on it as it will be very useful to me... All the best, Michael _ Wing IDE users list http://wingware.com/lists/wingide -- http://www.ironpythoninaction.com/ generate_pi.py -- Generate Python interface by inspecting a module at runtime Copyright (c) 2001-2008, Archaeopteryx Software, Inc. All rights reserved. Written by John P. Ehresman and Stephan R.A. Deibel Simple utility to generate a python interface file from inspecting a module at run time. First argument is the name of the module. Subsequent arguments are name:expression pairs -- a class with given name will be created in the interface file with methods attributes matching the methods attributes of the object that results from the expression. The expression will be evaluated within the context of the module. The interface will be written to stdout. This contains some code specific to Python standard library code because it parses the docstring standards used there to determine information about return values. However, it works also with code that does not contain those type hints in docstrings (but return value type cannot be determined). # IMPORTANT: This code has to run under all Python versions! import sys import os import string import stat try: import inspect except: inspect = None try: ascii_letters =
Re: [IronPython] IDLE like functionality
On Wed, Apr 29, 2009 at 7:24 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: Vernon Cole wrote: Actually, the code editor for IDLE (and pythonwin) is written in Python, so no, it does not have to be left out. Since pythonwin is a native WinForms application, PythonWin does not use Windows Forms it uses win32. Michael Errr, Ummm, I didn't know there was a difference. Please educate me. (supply links if helpful) The longer I spend in this industry, the more I discover I don't know. -- VC ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [wingide-users] Using Wing IDE with IronPython - autocomplete for .NET objects (PI file generator)
Would be nice to have something similar for vim :-) -- -- Lukas -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Wednesday, April 29, 2009 4:45 PM To: Wing Users Cc: Discussion of IronPython Subject: Re: [IronPython] [wingide-users] Using Wing IDE with IronPython - autocomplete for .NET objects (PI file generator) Hello all, Attached is an updated script for generating PI files to provide autocomplete on standard .NET objects. It now handles all the standard .NET member types (including static properties, enumeration fields, indexers, events and so on). It also recurses into sub-namespaces generating new pi-files for all of them. This script is hardcoded to add references to, and then generate PI files for: System System.Data System.Drawing System.Windows.Forms It generates 90 pi files (90 namespaces) taking up 24mb! The autocomplete it provides is awesome though. :-) I had to do a fair bit of violence to the standard generate_pi.py script so I *doubt* it is desirable to merge it back in. Obviously very happy for this to be included with Wing if you want, or merged if you think it is worth it. Is it ok for me to offer this for download from my site? If I make further changes I will email this list. The big thing to add is the return type for methods. Is it possible to specify return types for properties? (Currently any attribute without an obvious parallel in Python I have turned into a property in the PI files). The only real caveat with the current script (that I am aware of - bug reports and contributions welcomed) is that None is a common enumeration field member. This is invalid syntax in Python, so I rename these to None_. There are quite a few minor changes sprinkled through the code - plus the __main__ part of the script is very different. I have tried to mark changes with a # CHANGE: comment, but it should be relatively amenable to diffing anyway... For reference I was using IronPython 2.0.1, with .NET 3.5 installed and Wing 3.2beta 1. All the best, Michael Foord Michael Foord wrote: Hello all, I've created a modified version of the 'generate_pi.py' which generates the interface files for .NET libraries. It is attached. At the moment it generates PI files for the following assemblies / namespaces (hardwired at the bottom of the code): System System.Data System.Drawing System.Windows.Forms To run it, create a new directory and add this to the 'Interface File Path' (File menu - Preferences - Source Analysis - Advanced - Insert). Then from the command line switch to this directory (if you are on Vista you will need to run cmd with admin privileges due to a defect explained below). Execute the command: ipy generate_pi_for_net.py This generates the pi files. It doesn't work *as well* on 64 bit windows because the .NET XML help files (or whatever they are called) are in a different location so the docstrings are not always available - which is why I am not just distributing the pi files yet. The script doesn't yet understand static properties on classes - so it actually *fetches* static properties rather than looking at the descriptor (which is available in the class __dict__ so should be easy to fix). This is what causes inadvertent registry lookups etc and therefore requires admin privileges. It doesn't yet understand multiple overloads. This may require a change to Wing or may not matter. It isn't yet able to do anything with the information about return types - which would allow Wing to know the type of objects returned by methods. This may be easy to add? It is late so I am going to bed. At some point I will explain the simple changes I had to make to the standard generate_pi.py script (although they are mostly straightforward). I will also do further work on it as it will be very useful to me... All the best, Michael -- -- _ Wing IDE users list http://wingware.com/lists/wingide -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IDLE like functionality
Vernon Cole wrote: On Wed, Apr 29, 2009 at 7:24 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: Vernon Cole wrote: Actually, the code editor for IDLE (and pythonwin) is written in Python, so no, it does not have to be left out. Since pythonwin is a native WinForms application, PythonWin does not use Windows Forms it uses win32. Michael Errr, Ummm, I didn't know there was a difference. Please educate me. (supply links if helpful) The longer I spend in this industry, the more I discover I don't know. Windows Forms is .NET functionality layered on top of the Win32 APIs (using User32.dll, GDI+ etc). It introduces new controls and a whole programming model on top of those primitives. Pywin32 provides direct access to win32 and has nothing to do with Windows Forms. There are other complications with MFC (I've always assumed that was just a strict subset of what is loosely termed win32 - but I am playing fast and loose with terminology here). All the best, Michael Foord -- VC ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [wingide-users] Using Wing IDE with IronPython - autocomplete for .NET objects (PI file generator)
Cenovsky, Lukas wrote: Would be nice to have something similar for vim :-) Go for it. :-) Michael -- -- Lukas -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Wednesday, April 29, 2009 4:45 PM To: Wing Users Cc: Discussion of IronPython Subject: Re: [IronPython] [wingide-users] Using Wing IDE with IronPython - autocomplete for .NET objects (PI file generator) Hello all, Attached is an updated script for generating PI files to provide autocomplete on standard .NET objects. It now handles all the standard .NET member types (including static properties, enumeration fields, indexers, events and so on). It also recurses into sub-namespaces generating new pi-files for all of them. This script is hardcoded to add references to, and then generate PI files for: System System.Data System.Drawing System.Windows.Forms It generates 90 pi files (90 namespaces) taking up 24mb! The autocomplete it provides is awesome though. :-) I had to do a fair bit of violence to the standard generate_pi.py script so I *doubt* it is desirable to merge it back in. Obviously very happy for this to be included with Wing if you want, or merged if you think it is worth it. Is it ok for me to offer this for download from my site? If I make further changes I will email this list. The big thing to add is the return type for methods. Is it possible to specify return types for properties? (Currently any attribute without an obvious parallel in Python I have turned into a property in the PI files). The only real caveat with the current script (that I am aware of - bug reports and contributions welcomed) is that None is a common enumeration field member. This is invalid syntax in Python, so I rename these to None_. There are quite a few minor changes sprinkled through the code - plus the __main__ part of the script is very different. I have tried to mark changes with a # CHANGE: comment, but it should be relatively amenable to diffing anyway... For reference I was using IronPython 2.0.1, with .NET 3.5 installed and Wing 3.2beta 1. All the best, Michael Foord Michael Foord wrote: Hello all, I've created a modified version of the 'generate_pi.py' which generates the interface files for .NET libraries. It is attached. At the moment it generates PI files for the following assemblies / namespaces (hardwired at the bottom of the code): System System.Data System.Drawing System.Windows.Forms To run it, create a new directory and add this to the 'Interface File Path' (File menu - Preferences - Source Analysis - Advanced - Insert). Then from the command line switch to this directory (if you are on Vista you will need to run cmd with admin privileges due to a defect explained below). Execute the command: ipy generate_pi_for_net.py This generates the pi files. It doesn't work *as well* on 64 bit windows because the .NET XML help files (or whatever they are called) are in a different location so the docstrings are not always available - which is why I am not just distributing the pi files yet. The script doesn't yet understand static properties on classes - so it actually *fetches* static properties rather than looking at the descriptor (which is available in the class __dict__ so should be easy to fix). This is what causes inadvertent registry lookups etc and therefore requires admin privileges. It doesn't yet understand multiple overloads. This may require a change to Wing or may not matter. It isn't yet able to do anything with the information about return types - which would allow Wing to know the type of objects returned by methods. This may be easy to add? It is late so I am going to bed. At some point I will explain the simple changes I had to make to the standard generate_pi.py script (although they are mostly straightforward). I will also do further work on it as it will be very useful to me... All the best, Michael -- -- _ Wing IDE users list http://wingware.com/lists/wingide -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IDLE like functionality
MFC is a C++ wrapper for Win32. Made it more OO. Ah takes me back :-) !! Cheers, Davy ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] pywin32 on Iron Python?
On 18222 - I think ctypes will drive some changes to our buffer support making it more real. Right now it's close to useless :) There is some way for us to make types marshalable via COM ourselves so I think we'll be able to fix it eventually. I'm surprised that it's more of a problem than 18223 though. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Vernon Cole Sent: Wednesday, April 29, 2009 7:34 AM To: Discussion of IronPython Subject: Re: [IronPython] pywin32 on Iron Python? On Tue, Apr 28, 2009 at 5:32 PM, Jeff Hardy jdha...@gmail.com wrote: Hi Dave, On Tue, Apr 28, 2009 at 10:37 AM, Dave Fugate dfug...@microsoft.com wrote: That said, there is something extremely useful the community can do for IronPython that our team simply cannot: get 3rd party Python applications such as Django, pywin32, NumPy, etc running under IronPython. This could mean adapting something like adodbapi.py to utilize IronPython APIs similar to what Vernon Cole did, or re- implementing NumPy's C-based modules in C#. While it's quite difficult (impossible?) for anyone on our team to submit changes supporting IronPython back to other OSS projects, the rest of the IronPython Community happily doesn't have this limitation. Dave: My condolences on having to put up with the lawyers. I have to sleep with one, but at least she doesn't tell me who I can contribute code to. ;-) -- VC The problem with this approach is that I don't really want to clutter up e.g. Django with workarounds for IP bugs that are actually incompatibilities with CPython - they should and will get fixed in IP at some point. If it's a legitimate platform difference, or an invalid assumption by Django, then it can be fixed there - but I've found very few of those relative to bugs in IP itself. That's true. There is still one outstanding bug in adodbapi on iron which I hope will eventually be fixed in IPy. (see Work Item # 18222 -- August 2008) The workaround was just too large to use and would still have left the IPy COM implementation with a bug. When the COM bug gets fixed that last test failure will go away. There are other places where if IronPython: made sense and was used. (I also included simple workarounds for bugs like #18223.) -- VC Also, would it possible for you guys to revisit your commit messages? I would at least like to see a note in the CP commit messages when a particular CP issue has been fixed. + 1. Maybe my bug has already been fixed and I don't know. -- VC If anyone wants to contribute in this manner, please just give us a heads up so we can obtain permission to add tests for the 3rd party app(s) to our checkin system. Also, if there's enough interest in this I can setup a wiki page on CodePlex to keep track of whose working on what... +1 on the wiki page. Now this is interesting! Last time I checked, Django's test suite was nowhere near passing - would the full test suite have to pass before you'd include it? In other words, how good do we have to get? I really appreciate the work you guys are doing here. It can't be easy swimming against the tide all the time! - Jeff Amen! -- VC ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] sys._getframe(n)?
Yep, we're going to make it available via a command line option. The Interesting question is what does IPython need from frames? Does it need locals (which frequently won't be available), globals, the function or code, or something else? I think bug 1042 is the one to vote on: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=1042 -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Mike Krell Sent: Wednesday, April 29, 2009 6:19 AM To: Users@lists.ironpython.com Subject: [IronPython] sys._getframe(n)? Is it true that the dev team is considering implementing sys._getframe(n) where n 0? I'd love to see this since my understanding is that this is a stumbling block for running IronPython under IPython. Is there an issue number on CodePlex on this that I can vote for? Thanks, Mike ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Running Scripts/generate.py on CPython
Scripts/generate.py has a comment: TODO: does it make sense to run this under CPython?. I think so. The following is how I did that: 1. Delete import nt at the top. It is imported later anyway. 2. Change root_dir and source_directories. (Because source layout is different, but change is easy.) 3. Uncomment lines under TODO: does it make sense... 4. Define basename as os.path.basename and System.IO.Path.GetFileName just like isdir. Use it later. Maybe change 1 and 4 can be made on IronPython? Also change code_text += \n to \r\n if you want to avoid line ending difference. -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] pywin32 on Iron Python?
The technical bar for inclusion of 3rd party tests into our checkin system is pretty simple - the test process needs to emit a non-zero exit code when it fails. When some portion of a test fails under IronPython for whatever reason, we simply disable that portion. For example, we run around 200 CPython 2.6 test_*.py files for every IronPython checkin with roughly a thousand individual test cases in these modules disabled. With this in mind, it likely doesn't matter that most of Django's test suite does not pass = we can disable the broken stuff. As for inclusion of commit messages in the CodePlex source synchs, we'll look into this. It's a bit challenging as sometimes we work on getting IronPython running against/with the latest unannounced Microsoft technology (e.g., we had IronPython running under Silverlight months before Silverlight was publically announced) and this is often reflected in our checkin comments. Thanks, Dave -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Vernon Cole Sent: Wednesday, April 29, 2009 7:34 AM To: Discussion of IronPython Subject: Re: [IronPython] pywin32 on Iron Python? On Tue, Apr 28, 2009 at 5:32 PM, Jeff Hardy jdha...@gmail.com wrote: Hi Dave, On Tue, Apr 28, 2009 at 10:37 AM, Dave Fugate dfug...@microsoft.com wrote: That said, there is something extremely useful the community can do for IronPython that our team simply cannot: get 3rd party Python applications such as Django, pywin32, NumPy, etc running under IronPython. This could mean adapting something like adodbapi.py to utilize IronPython APIs similar to what Vernon Cole did, or re-implementing NumPy's C-based modules in C#. While it's quite difficult (impossible?) for anyone on our team to submit changes supporting IronPython back to other OSS projects, the rest of the IronPython Community happily doesn't have this limitation. Dave: My condolences on having to put up with the lawyers. I have to sleep with one, but at least she doesn't tell me who I can contribute code to. ;-) -- VC The problem with this approach is that I don't really want to clutter up e.g. Django with workarounds for IP bugs that are actually incompatibilities with CPython - they should and will get fixed in IP at some point. If it's a legitimate platform difference, or an invalid assumption by Django, then it can be fixed there - but I've found very few of those relative to bugs in IP itself. That's true. There is still one outstanding bug in adodbapi on iron which I hope will eventually be fixed in IPy. (see Work Item # 18222 -- August 2008) The workaround was just too large to use and would still have left the IPy COM implementation with a bug. When the COM bug gets fixed that last test failure will go away. There are other places where if IronPython: made sense and was used. (I also included simple workarounds for bugs like #18223.) -- VC Also, would it possible for you guys to revisit your commit messages? I would at least like to see a note in the CP commit messages when a particular CP issue has been fixed. + 1. Maybe my bug has already been fixed and I don't know. -- VC If anyone wants to contribute in this manner, please just give us a heads up so we can obtain permission to add tests for the 3rd party app(s) to our checkin system. Also, if there's enough interest in this I can setup a wiki page on CodePlex to keep track of whose working on what... +1 on the wiki page. Now this is interesting! Last time I checked, Django's test suite was nowhere near passing - would the full test suite have to pass before you'd include it? In other words, how good do we have to get? I really appreciate the work you guys are doing here. It can't be easy swimming against the tide all the time! - Jeff Amen! -- VC ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Expression printing in interactive mode
In changeset 42603, a change was made to IronPython.Hosting.PythonCommandLine.RunOneInteraction, - SourceUnit su = Language.CreateSnippet(s, stdin, SourceCodeKind.InteractiveCode); + SourceUnit su = Language.CreateSnippet(s, stdin, (s.Contains(Environment.NewLine))? SourceCodeKind.Statements : SourceCodeKind.InteractiveCode); Why is this? It seems to me that s always contains newline, so its net effect is making all interactive code non-interactive. In Python, this means no expression is printed in interactive mode. -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Expression printing in interactive mode
There was some internal work going on w/ running a remote console and it looks like this change was related to that. In Microsoft.Scripting.Hosting.Shell there's a comment added to its RunOneInteraction w/ the same change: /// We check if the code read is an interactive command or statements is by checking for NewLine /// If the code contains NewLine, it's a set of statements (most probably from SendToConsole) /// If the code does not contain a NewLine, it's an interactive command typed by the user at the prompt Looking at the code thought I'm guessing this is totally broken on Unix because in ReadStatement we append a newline, with a wonderful comment there: // Note that this does not use Environment.NewLine because some languages (eg. Python) only // recognize \n as a line terminator. b.Append(\n); So this just happens to do the right thing on Windows due to the mismatches between the new lines being used. I guess we should actually be checking for more than one \n. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Seo Sanghyeon Sent: Wednesday, April 29, 2009 10:48 AM To: Discussion of IronPython Subject: [IronPython] Expression printing in interactive mode In changeset 42603, a change was made to IronPython.Hosting.PythonCommandLine.RunOneInteraction, - SourceUnit su = Language.CreateSnippet(s, stdin, SourceCodeKind.InteractiveCode); + SourceUnit su = Language.CreateSnippet(s, stdin, (s.Contains(Environment.NewLine))? SourceCodeKind.Statements : SourceCodeKind.InteractiveCode); Why is this? It seems to me that s always contains newline, so its net effect is making all interactive code non-interactive. In Python, this means no expression is printed in interactive mode. -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Expression printing in interactive mode
2009/4/30 Dino Viehland di...@microsoft.com: Looking at the code thought I'm guessing this is totally broken on Unix because in ReadStatement we append a newline, with a wonderful comment there: // Note that this does not use Environment.NewLine because some languages (eg. Python) only // recognize \n as a line terminator. b.Append(\n); So this just happens to do the right thing on Windows due to the mismatches between the new lines being used. Ah, mystery solved. So it worked by accident on systems where NewLine != \n... -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Expression printing in interactive mode
Actually now that I think about it more than one \n isn't right either because that will change how we parse multi-line statements at the REPL. Maybe this should just be undone. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Dino Viehland Sent: Wednesday, April 29, 2009 11:13 AM To: Discussion of IronPython Subject: Re: [IronPython] Expression printing in interactive mode There was some internal work going on w/ running a remote console and it looks like this change was related to that. In Microsoft.Scripting.Hosting.Shell there's a comment added to its RunOneInteraction w/ the same change: /// We check if the code read is an interactive command or statements is by checking for NewLine /// If the code contains NewLine, it's a set of statements (most probably from SendToConsole) /// If the code does not contain a NewLine, it's an interactive command typed by the user at the prompt Looking at the code thought I'm guessing this is totally broken on Unix because in ReadStatement we append a newline, with a wonderful comment there: // Note that this does not use Environment.NewLine because some languages (eg. Python) only // recognize \n as a line terminator. b.Append(\n); So this just happens to do the right thing on Windows due to the mismatches between the new lines being used. I guess we should actually be checking for more than one \n. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Seo Sanghyeon Sent: Wednesday, April 29, 2009 10:48 AM To: Discussion of IronPython Subject: [IronPython] Expression printing in interactive mode In changeset 42603, a change was made to IronPython.Hosting.PythonCommandLine.RunOneInteraction, - SourceUnit su = Language.CreateSnippet(s, stdin, SourceCodeKind.InteractiveCode); + SourceUnit su = Language.CreateSnippet(s, stdin, (s.Contains(Environment.NewLine))? SourceCodeKind.Statements : SourceCodeKind.InteractiveCode); Why is this? It seems to me that s always contains newline, so its net effect is making all interactive code non-interactive. In Python, this means no expression is printed in interactive mode. -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] pywin32 on Iron Python?
When we make a major effort to make IPy work with a third party package, how shall we clue you to re-enable the tests? An announcement on this forum, or what? -- Vernon On Wed, Apr 29, 2009 at 10:55 AM, Dave Fugate dfug...@microsoft.com wrote: The technical bar for inclusion of 3rd party tests into our checkin system is pretty simple - the test process needs to emit a non-zero exit code when it fails. When some portion of a test fails under IronPython for whatever reason, we simply disable that portion. For example, we run around 200 CPython 2.6 test_*.py files for every IronPython checkin with roughly a thousand individual test cases in these modules disabled. With this in mind, it likely doesn't matter that most of Django's test suite does not pass = we can disable the broken stuff. As for inclusion of commit messages in the CodePlex source synchs, we'll look into this. It's a bit challenging as sometimes we work on getting IronPython running against/with the latest unannounced Microsoft technology (e.g., we had IronPython running under Silverlight months before Silverlight was publically announced) and this is often reflected in our checkin comments. Thanks, Dave ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] pywin32 on Iron Python?
-- http://www.ironpythoninaction.com On 29 Apr 2009, at 17:55, Dave Fugate dfug...@microsoft.com wrote: The technical bar for inclusion of 3rd party tests into our checkin system is pretty simple - the test process needs to emit a non-zero exit code when it fails. When some portion of a test fails under IronPython for whatever reason, we simply disable that portion. For example, we run around 200 CPython 2.6 test_*.py files for every IronPython checkin with roughly a thousand individual test cases in these modules disabled. With this in mind, it likely doesn't matter that most of Django's test suite does not pass = we can disable the broken stuff. As for inclusion of commit messages in the CodePlex source synchs, we'll look into this. It's a bit challenging as sometimes we work on getting IronPython running against/with the latest unannounced Microsoft technology (e.g., we had IronPython running under Silverlight months before Silverlight was publically announced) and this is often reflected in our checkin comments. I can't believe that editing / redacting commit messages is an impossible challenge. :-) It really would be very useful. Michael Thanks, Dave -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com ] On Behalf Of Vernon Cole Sent: Wednesday, April 29, 2009 7:34 AM To: Discussion of IronPython Subject: Re: [IronPython] pywin32 on Iron Python? On Tue, Apr 28, 2009 at 5:32 PM, Jeff Hardy jdha...@gmail.com wrote: Hi Dave, On Tue, Apr 28, 2009 at 10:37 AM, Dave Fugate dfug...@microsoft.com wrote: That said, there is something extremely useful the community can do for IronPython that our team simply cannot: get 3rd party Python applications such as Django, pywin32, NumPy, etc running under IronPython. This could mean adapting something like adodbapi.py to utilize IronPython APIs similar to what Vernon Cole did, or re-implementing NumPy's C-based modules in C#. While it's quite difficult (impossible?) for anyone on our team to submit changes supporting IronPython back to other OSS projects, the rest of the IronPython Community happily doesn't have this limitation. Dave: My condolences on having to put up with the lawyers. I have to sleep with one, but at least she doesn't tell me who I can contribute code to. ;-) -- VC The problem with this approach is that I don't really want to clutter up e.g. Django with workarounds for IP bugs that are actually incompatibilities with CPython - they should and will get fixed in IP at some point. If it's a legitimate platform difference, or an invalid assumption by Django, then it can be fixed there - but I've found very few of those relative to bugs in IP itself. That's true. There is still one outstanding bug in adodbapi on iron which I hope will eventually be fixed in IPy. (see Work Item # 18222 -- August 2008) The workaround was just too large to use and would still have left the IPy COM implementation with a bug. When the COM bug gets fixed that last test failure will go away. There are other places where if IronPython: made sense and was used. (I also included simple workarounds for bugs like #18223.) -- VC Also, would it possible for you guys to revisit your commit messages? I would at least like to see a note in the CP commit messages when a particular CP issue has been fixed. + 1. Maybe my bug has already been fixed and I don't know. -- VC If anyone wants to contribute in this manner, please just give us a heads up so we can obtain permission to add tests for the 3rd party app(s) to our checkin system. Also, if there's enough interest in this I can setup a wiki page on CodePlex to keep track of whose working on what... +1 on the wiki page. Now this is interesting! Last time I checked, Django's test suite was nowhere near passing - would the full test suite have to pass before you'd include it? In other words, how good do we have to get? I really appreciate the work you guys are doing here. It can't be easy swimming against the tide all the time! - Jeff Amen! -- VC ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] pywin32 on Iron Python?
On Wed, Apr 29, 2009 at 10:55 AM, Dave Fugate dfug...@microsoft.com wrote: The technical bar for inclusion of 3rd party tests into our checkin system is pretty simple - the test process needs to emit a non-zero exit code when it fails. When some portion of a test fails under IronPython for whatever reason, we simply disable that portion. For example, we run around 200 CPython 2.6 test_*.py files for every IronPython checkin with roughly a thousand individual test cases in these modules disabled. With this in mind, it likely doesn't matter that most of Django's test suite does not pass = we can disable the broken stuff. In the case of Django, many of the tests depnd on a database. Is there anyway for you guys to handle that, or would you only be able to run the tests that don't need a db? You could use SQLite, but that requires an sqlite module, and you're back into 3rd party code again. As for inclusion of commit messages in the CodePlex source synchs, we'll look into this. It's a bit challenging as sometimes we work on getting IronPython running against/with the latest unannounced Microsoft technology (e.g., we had IronPython running under Silverlight months before Silverlight was publically announced) and this is often reflected in our checkin comments. My thought was that anything safe for public consumption could be prefixed with cp:(or whatever), but that might depend on how much munging there is between your internal repo and Codeplex. Or you could work off the Codeplex repo for real, and use a seperate one for the sekrit stuff :). - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] pywin32 on Iron Python?
2009/4/30 Michael Foord fuzzy...@voidspace.org.uk: I can't believe that editing / redacting commit messages is an impossible challenge. :-) No, but *automating* editing/redacting commit message will be well nigh impossible challenge. :( -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] pywin32 on Iron Python?
On Wed, Apr 29, 2009 at 9:33 AM, Dino Viehland di...@microsoft.com wrote: On 18222 - I think ctypes will drive some changes to our buffer support making it more real. Right now it's close to useless :) There is some way for us to make types marshalable via COM ourselves so I think we'll be able to fix it eventually. I'm surprised that it's more of a problem than 18223 though. As Jeff said, it's a question of cluttering up the code. pywin32 C code does a lot of work converting Python objects into/from COM compatible types. IronPython COM calls do not have the extra layer of help. For example, in adodbapi the workaround for 18223 is: elif isinstance(elem, longType) and onIronPython: # Iron Python Long s = SystemDecimal(elem) # feature workaround for IPy 2.0 p.Value = s else: p.Value=elem Note that when converted to Python 3, this effectively becomes: elif isinstance(elem, int) and onIronPython: # Iron Python integer s = SystemDecimal(elem) # feature workaround for IPy 2.0 p.Value = s else: p.Value=elem so that ALL integers will be run thru SystemDecimal before use as a COM parameter. Clearly this will need to be fixed before IronPython 3.0... -- Vernon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] pywin32 on Iron Python?
-- http://www.ironpythoninaction.com On 29 Apr 2009, at 19:40, Seo Sanghyeon sanx...@gmail.com wrote: 2009/4/30 Michael Foord fuzzy...@voidspace.org.uk: I can't believe that editing / redacting commit messages is an impossible challenge. :-) No, but *automating* editing/redacting commit message will be well nigh impossible challenge. :( Coming up with a scheme so that non-public information can be automatically trimmed shouldn't be an impossible challenge. Even if it is these syncs happen once a day or so and they won't all need editing. Having 'secret' commit messages in an open source project is not good. Michael -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Using Wing IDE with IronPython - autocomplete for .NET objects (PI file generator)
This sounds great. I am new to both IronPython, WingIDE and Windows development in general. One of the disappointing things with WingIDE for me is the total absence of autocompletion of .NET imports and also the DLL Assembly References I've added to access the libraries my app requires. Unfortunately, for most of what I would like, I believe it would require WingIDE to support the use of IronPython. Is this accurate? And if WingIDE did support the use of IronPython would it make what you are doing easier or possibly unnecessary? I am exploring my IDE options. So I am somewhat disappointed with WingIDE not providing autocompletion or any of the features for which I am explicitly needing to use IronPython for. Unfortunately I really haven't found anything that does provide autocompletion for the libraries I've imported via clr. Oh well. It is possible I've missed something. I would love to see WingIDE support IronPython and enabling autocompletion, debugging, etc. on .NET and clr imported libraries and modules. Thanks for doing this Michael. It will be a nice help. And also thanks for your book which I am working my way through. Jimmie Houchin Michael Foord wrote: Hello all, Attached is an updated script for generating PI files to provide autocomplete on standard .NET objects. It now handles all the standard .NET member types (including static properties, enumeration fields, indexers, events and so on). It also recurses into sub-namespaces generating new pi-files for all of them. This script is hardcoded to add references to, and then generate PI files for: System System.Data System.Drawing System.Windows.Forms It generates 90 pi files (90 namespaces) taking up 24mb! The autocomplete it provides is awesome though. :-) I had to do a fair bit of violence to the standard generate_pi.py script so I *doubt* it is desirable to merge it back in. Obviously very happy for this to be included with Wing if you want, or merged if you think it is worth it. Is it ok for me to offer this for download from my site? If I make further changes I will email this list. The big thing to add is the return type for methods. Is it possible to specify return types for properties? (Currently any attribute without an obvious parallel in Python I have turned into a property in the PI files). The only real caveat with the current script (that I am aware of - bug reports and contributions welcomed) is that None is a common enumeration field member. This is invalid syntax in Python, so I rename these to None_. There are quite a few minor changes sprinkled through the code - plus the __main__ part of the script is very different. I have tried to mark changes with a # CHANGE: comment, but it should be relatively amenable to diffing anyway... For reference I was using IronPython 2.0.1, with .NET 3.5 installed and Wing 3.2beta 1. All the best, Michael Foord Michael Foord wrote: Hello all, I've created a modified version of the 'generate_pi.py' which generates the interface files for .NET libraries. It is attached. At the moment it generates PI files for the following assemblies / namespaces (hardwired at the bottom of the code): System System.Data System.Drawing System.Windows.Forms To run it, create a new directory and add this to the 'Interface File Path' (File menu - Preferences - Source Analysis - Advanced - Insert). Then from the command line switch to this directory (if you are on Vista you will need to run cmd with admin privileges due to a defect explained below). Execute the command: ipy generate_pi_for_net.py This generates the pi files. It doesn't work *as well* on 64 bit windows because the .NET XML help files (or whatever they are called) are in a different location so the docstrings are not always available - which is why I am not just distributing the pi files yet. The script doesn't yet understand static properties on classes - so it actually *fetches* static properties rather than looking at the descriptor (which is available in the class __dict__ so should be easy to fix). This is what causes inadvertent registry lookups etc and therefore requires admin privileges. It doesn't yet understand multiple overloads. This may require a change to Wing or may not matter. It isn't yet able to do anything with the information about return types - which would allow Wing to know the type of objects returned by methods. This may be easy to add? It is late so I am going to bed. At some point I will explain the simple changes I had to make to the standard generate_pi.py script (although they are mostly straightforward). I will also do further work on it as it will be very useful to me... All the best, Michael _ Wing IDE users list http://wingware.com/lists/wingide
Re: [IronPython] sys._getframe(n)?
On Wed, Apr 29, 2009 at 8:34 AM, Dino Viehland di...@microsoft.com wrote: Yep, we're going to make it available via a command line option. The Interesting question is what does IPython need from frames? Does it need locals (which frequently won't be available), globals, the function or code, or something else? I hadn't looked at the source until now, but a cursory glance suggests that it typically wants to evaluate expressions with the locals (and globals) from various stack frames. Could you discuss in a bit more detail why certain locals wouldn't be available that would otherwise be available in CPython? Mike ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] sys._getframe(n)?
On Wed, Apr 29, 2009 at 6:19 PM, Mike Krell mbk.li...@gmail.com wrote: On Wed, Apr 29, 2009 at 8:34 AM, Dino Viehland di...@microsoft.com wrote: Yep, we're going to make it available via a command line option. The Interesting question is what does IPython need from frames? Does it need locals (which frequently won't be available), globals, the function or code, or something else? I hadn't looked at the source until now, but a cursory glance suggests that it typically wants to evaluate expressions with the locals (and globals) from various stack frames. Could you discuss in a bit more detail why certain locals wouldn't be available that would otherwise be available in CPython? I don't know the exact answer but I won't let that stop me from replying. :) I'll just rely on Dino correcting anything I say that is wrong... IronPython is a compiler that ultimately produces MSIL. If it determines that a particular local variable doesn't need to be accessed from outside the local scope -- that is, if it's not closed over and there is no exec or locals() which could target it -- then that variable simply becomes a local value on the IL stack. The CLR StackFrame object doesn't give us access to the associated locals, so we have no way of accessing them from outside (except through CLR debug APIs, which aren't really applicable for this type of use). In principle, IronPython could optionally use a less-efficient representation for locals that would allow us to expose them all of them through the Python stack frame. I don't know how serious a performance penalty this would exact, but I imagine it's not small. The Unladen Swallow project is likely to face similar tradeoffs. -- Curt Hagenlocher c...@hagenlocher.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
