IronPython URLs

The talk schedule has gone up for for PyCon 2009 in Chicago. There are three talks on IronPython, plus a tutorial on the Wednesday before the conference. PyCon is the international Python conference, and the highlight of the Python year. The conference dates are: March 25-26th Tutorial Days March 27-29th Conference March 30th - April 2nd Development Sprints Jim Hugunin is one of the invited speakers, so his talk doesn't yet appear on the schedule - but his usual talk is " IronPython the Road Ahead ". The other two IronPython talks are: IronPython Implementation, by Dino Veihland (core IronPython developer) IronPython is an implementation of Python running on .NET. This talk will provide an overview of the IronPython internals. The talk will start with a high-level walk through of the IronPython architecture and source layout. From there we’ll drill into details such as method dispatch, how the .NET and Python type systems interrelate, multi-runtime support, and how I

IronPython isn't the only new language going mainstream on the .NET framework. In fact the dynamic languages team (responsible for IronRuby, IronPython and the Dynamic Language Runtime) are part of a larger team called the GO team - Growth Opportunities. One of these languages is F# , a functional language created by Don Syme and team and based on Ocaml. Because it runs on the .NET framework (or Mono) F# has the great advantage over many interesting functional languages in being of immediate practical use! It also lends itself to polyglot programming - algorithms and problems particularly suited to being solved in a functional language can easily be mixed with code written in C# or IronPython. F# is already beloved by statisticians who where previously working in C#. Like Python it has a powerful interactive shell. Luis Diego Fallas has a blog entry on using F# code from IronPython: Some Notes on Using F# Code from IronPython F# has its own built-in types like lists and tuples. A

The .NET answer to the wonderful world of web frameworks like Django and Rails is ASP.NET MVC (which reached RC1 in the last couple of days). There are various ways that dynamic languages can be used with ASP.NET MVC, and the integration is improving. This entry on Code Voyeur demonstrates how to configure controllers with IronPython, using a PyControllerFactory : A Simple IronPython ControllerFactory for ASP.NET MVC The default behavior for ASP.NET MVC is to wire up a controller instance to the controller value found in a request's RouteData. This mapping is desirable for its simplicity, but limited in its ability to provide an extensible configuration model. Managing properties on controllers would likely require either a custom configuration section or extensive use of AppSettings. An alternative approach would be to use an IoC container, such as Spring.NET. This approach simply manages controller instances as standard Spring container objects. An MVC contrib project already pr

Ironclad is a project by Resolver Systems to allow the use of Python C extensions from IronPython. Ironclad provides a compatibility layer for the Python C API, allowing extensions to be imported from IronPython. The goal is to allow the use of Numpy within Resolver One spreadsheets , but Ironclad is open source and available under the MIT license. The core developer of Ironclad, William Reade, has just announced the release of Ironclad 0.8. This is an important release as many extension libraries are now usable with Ironclad. In fact now you can run through the whole Numpy tutorial using the IronPython interactive interpreter! As usual, sources and windows binaries are available from the project page: Ironclad Project Page I'm delighted to announce the release of Ironclad v0.8 -- the all-singing, all-dancing CPython API compatibility layer for IronPython -- available now from the Ironclad Project Page . Notable improvements over the last release include: Ironclad is now a neat

One use for IronPython in .NET applications is as an embedded engine for expression evaluation: Expression evaluator in 15 minutes with Irony & Dlr Evaluation of a string expression to a value is a common programming task. Almost any college course in informatics includes this excercise. It involves implementing some fundamental algorithms and structures such as: recursive-descent parser, regexp matching, traversal algorithms, syntax tree, hash-tables, etc. And for sure it should be done on some pure programming language such as ANSI C or Pascal. .NET Framework brought a lot of in-box algorithms and structures which simplifies the usual live of software developer. However it is still a good excercise to evaluate a string expression, say 2+(4*5)^12. But fortunately there are some new tools that facilitate producing language parsers and their interpreters/compilers. Piter has used the DLR, along with a C# parser library called Irony (which he has also used to create Script.NET ), t

MC Press Online has a new article on IronPython by Joydip Kanjilal : IronPython: Old Wine in a New Bottle The article is an introduction to using IronPython and interacting with the .NET framework: Learn how to write simple programs in IronPython and access .NET libraries with IronPython code. The advent of the IronPython programming language in the managed environment of the CLR provides a lot of benefits, namely these: Support for dynamic typing Support for procedural, functional, object-oriented programming Support for rapid development Support for embedded scripting Support for seamless extendibility Support for accessing .NET managed libraries Support for accessing .NET objects from IronPython script using reflection The article covers installing IronPython, the interactive interpreter, using .NET assemblies, plus examples with WPF and XML. There are a couple of minor issues with the article: indentation in the code examples is missing and after showing installing IronPython 2.0 i

Craig Murphy is a .NET developer who helps organise a lot of community events in the UK and Scotland . He has read an early access version of IronPython in Action , and has posted a detailed review: Book Review: IronPython In Action, Michael Foord and Christian Muirhead During 2008, dynamic languages picked up a lot of momentum. Indeed, in IronPython In Action, Foord and Muirhead describe this momentum somewhat amusingly: “dynamic languages are trendy; all the alpha-geeks are using them!” With what is the largest known IronPython codebase forming a large part of their careers, the authors are well-placed to provide us with accurate and authorative information coupled with practical code examples. Fortunately Craig liked the book (and so he should!) and says some nice things: You should buy this book if you wish to understand where the Dynamic Language Runtime fits into your .NET toolkit. If you are looking for better ways to test your code, dynamic languages and duck typing lend them

Jimmy Schementi maintains the Silverlight and DLR (agDLR) integration, which is now hosted on github and open to community contributions. Unfortunately being a browser plugin, Silverlight is hard to test - or at least was: Dynamic Language Testing in Silverlight getting the infrastructure to run tests has taken some time, but I just committed a Silverlight spec runner for bacon (a little Ruby spec framework) and a bunch of specs for Microsoft.Scripting.Silverlight ! So, the tests are written in Ruby, but they test the C# code in Microsoft.Scripting.Silverlight ... pretty cool. This is a deviation from my common belief of "test in the language you write the code in", but so what ... I never cared for that way of thinking =) This test system is reusable by Silverlight apps. Jimmy has a video of it in action on his blog entry and explains the problems with the old system. To get tests out to the world, the only sane thing would be to head back to the drawing board, which is

A while ago Cal Schrotenboer contacted me about an article on dynamic languages and Silverlight. He used chapter 13 of IronPython in Action for research, and its nice to finally see the article published: RIA Applications for Python and Ruby Developers - with Silverlight 2 If you're a Python or Ruby fan, you may feel you're missing out on all the latest developments in Rich Internet Applications. With support for Python and Ruby in Microsoft® Silverlight™ 2, dynamic language developers now have easy access to the latest RIA technologies. Moreover, in my conversations with dynamic language developers, the rapid development cycle and the ability to see changes immediately without the need to recompile are the most commonly stated reasons for their preference for dynamic languages. This article will focus specifically on dynamic language support in the recently released Silverlight 2. This topic should be of potential interest to three categories of developers: Python or Ruby dev

Another selection of blog entries and articles about IronPython and the Dynamic Language Runtime that have appeared over the last month or so. I still have a problem with the DLR A blogger called mithrandir explains the problems he has with the source code for the DLR. It basically boils down to two things: There seems to be a lot of hard coded references to the main DLR languages IronPython & IronRuby, potentially making it hard to implement other languages. There are a lot of compiler directives (#ifdefs) for the Silverlight version Bill Chiles (DLR PM) responds to this (particularly the first point) in the comments, so it really boils down to mithrandrir not liking compiler directives... Hosting IronPython 2.0 What looks like a great article on hosting IronPython 2.0 from C#, explaining the core classes and replete with diagrams and code examples. Unfortunately (for me) the article is in Chinese - although as usual the code examples are easy to follow. For those who only speak

Reflector is an extremely well known .NET tool (free but not open source and owned by Redgate ) for exploring .NET assemblies. It can show you all the types in assemblies, their members and the relationships between them. In addition to this, it can disassemble the IL bytecode back into .NET languages like C# and VB.NET - allowing you to examine the implementation. Reflector has a plugin mechanism and lots of interesting plugins. A new one has appeared on Codeplex called IP reflector, which promises to be able to decompile the bytecode generated by IronPython back into Python code (IronPython code that has been compiled by the Pyc.py compiler): IronPython addin for Redgate's .Net Reflector There is a release available on codeplex - version 1.0.0 Beta. No word on whether it is based on IronPython 1 or 2.

There is a new release of Silvershell, version 0.6.1. As well as fixing several bugs this release includes the sourcecode! Silvershell is a Python interactive interpreter with intellisense and lots of other features. It can run on the Windows desktop with WPF or in the browser with Silverlight: Silvershell Project Page Dan Eloff announced the release on the IronPython mailing list: There's an important new bugfix release. I put a lot of irritating flaws in the "intellisense" to rest, including a major issue with member completion that crept into 0.6.0 at the last minute. Had I known there was going to be such a response I think I would have tested it more thoroughly. As promised all source code is in this release. Please notify me of remaining bugs, either via email, or via the issue tracker on Google Code. Patches are most welcome.

Ryan Brady has posted a great blog entry with step-by-step instructions on how to debug IronPython code with the Visual Studio debugger (unfortunately it requires Visual Studio Professional and so doesn't work with Visual Studio Express - although it is possible that you could get round it by building IronPython from source as part of your solution): Debugging IronPython in Visual Studio The steps he lists are (although if you go directly to his entry it has more detailed instructions along with pretty pictures): Create a Python file to debug. From Visual Studio, open the IronPython executable (ipy.exe). If it doesn’t do so for you, add the ipy.exe as an existing project. From the Solution Explorer, right-click on Properties and set the Command Arguments property. Use “-D” to tell ipy.exe to create debugging output and add the full path to the script you made before. Click Ok. Open the script you created earlier in Visual Studio and place breakpoints as desired. Run the script in

Jeff Hardy is the creator of NWSGI , a .NET implementation of WSGI implemented as an ASP.NET HttpHandler for use with IIS 6 & 7. His goal is to be able to use Python web applications and frameworks like Django and Trac from IronPython. He has been working on getting Django and easy_install working with IronPython. For easy_install one of the big hurdles is that the zlib module isn't available (even the version in FePy is missing a key part of the API that setuptools uses to unpack archives it downloads from PyPI). Getting setuptools working with IronPython will be a big win for using Python libraries and frameworks as more and more of them depend on being installed in this way. He has written three blog entries on how far he has got with these issues. Django + IronPython I've had a couple of people ask about a Django + IronPython "Getting Started". This has been on my TODO list for a while; I just haven't gotten around to it. I'll try to do somethin

One thing that isn't clear when working with IronPython (as if it was clear for Python) is which IDE to use. The Visual Studio 2008 integration is done through IronPython Studio . This has impressive elements - but also plenty of rough edges and in my opinion isn't stable enough for regular use. IronPython Studio is built on IronPython 1 and seems to be little more than abandonware from the company that produced it. It is not necessary to use IronPython Studio to debug IronPython code in Visual Studio, however if you want features you're used to in a Python IDE (autocomplete, go to definition, call tips, integrated interactive interpreter and so on) then you probably want to look elsewhere. I use the capable Wing IDE , but a custom solution for IronPython would be an interesting project. This is where Davy Mitchell steps in with a new project called Davy's IronPython editor. The screenshot below shows the editor pane (implemented with the Windows Forms SyntaxBox compo

XAML is a markup language used to describe user interfaces for the Windows Presentation Foundation (WPF) UI library. PyBinding is a library created by Pixel-in-Gene allowing you to use IronPython for custom expressions in data binding situations: " essentially a DSL for creating Bindings ". A second blog entry discusses a detail of the WPF framework that makes this less useful than it could be in some situations. The PyBinding MarkupExtension: use Python statements for Data Binding Huge limitation of a MarkupExtension Many of us have felt the need to have custom expressions inside of Bindings. The need has ranged from applying mathematical operators to calling methods on bound objects. For simple needs you can probably create a custom IValueConverter or a IMultiValueConverter that can do the job, but when you want to use arbitrary expressions, something more elaborate is needed. The ScriptConverter class that I blogged about earlier provides the underpinning for the PyBindi

Now that Python 2.6 is out of the door the IronPython team are working on IronPython support for 2.6 features. Useful new features in Python 2.6 (or at least the ones I particularly like) include: with statement available without future import New syntax for exception handling Class decorators hasattr not discarding all exceptions Being able to provide keyword arguments after *args Getter, setter and deleter on properties (damn useful) __dir__ support In fact the last one is already available - it is analogous to the method GetMemberNames that you can implement on .NET objects to provide dynamic Python behavior for classes implemented in C#. Because it was basically already there, the IronPython team built it into IronPython 2 anyway. Now that IronPython 2 is also out of the door, the team have been working on the 2.1 branch and implementing Python 2.6 features. Of course having IronPython 2.1 tracking Python 2.6 is a recipe for confusion, so Dave Fugate asked whether t

As well as the 'signed-and-supported' releases of IronPython , source code drops of the latest sources are available from the public facing repository . The same is also true of the Dynamic Language Runtime project. The scripts that pushed from the Microsoft internal repositories to the public ones were broken over Christmas, but on Wednesday new drops arrived with some nice performance improvements. The source code drops include the 2.0 branch (the stable branch that will shortly be released as 2.0.1) and head (IronPython_Main) that includes deeper changes to the DLR, with even more dramatic performance gains in some areas. Until recently this was referred to as the 2.1 branch; more on that shortly. To get working binaries from the source code releases it needs to be compiled with the .NET 3.5 compiler. This doesn't require Visual Studio (the compiler is part of the framework) and the resulting binaries will run on .NET 2.0 (SP1). It does require some command line magic,

realXtend is an "Open source platform for interconnected virtual worlds". The server can be scripted with Python using IronPython: Content Scripting Python Introduction realXtend adds Python script support for the server using Ironpython. The script uses a different kind of system compared to LSL scripts which use the inventory system. This is because the scripts are more powerful and can also access the server machine's other resources. The scripts are stored in the server's ScriptEngines\PythonScript subfolders, not to database. By default this folder contains the RXCore folder which contains the core implementation of the script engine so this folder shouldn't be modified. Samples folder contains some example scripts. Apparently realXtend can also be used to do some pretty funky things with Second Life scripting: Tutorial: realXtend’s powerful configuration management for models without notecards One of the most annoying aspects of supplying parameters to sc

IronPython in Action inches ever closer to publication. Several people have been reading and reviewing the early access version of the ebook. To cover news about the book and its accompanying sourcecode, plus online reviews, I've started an IronPython in Action news blog: IronPython in Action News Blog (The blog is run with the excellent new Python blog engine: Zine .) We've just had the latest deadlines from Manning, and the latest blog entry sets out the schedule - if all goes well the book should go into publication in the middle of next month. Another of the blog entries notes what Lawrence Oluyede has been up to with the book. Whilst reading he has been posting summaries of each chapter in Italian. So far he is up to chapter 12 (and by what I can make out from Google translate he is enjoying the book). The first entry: preambolo The latest entry: accesso ai dati e webservice All Lawrence's IronPython Entries Lawrence assures me that when he has finished the book he

Resolver Systems has just announced the release of version 1.3.1 of Resolver One , the IronPython spreadsheet. This is purely a bugfix release, with a few usability fixes and documentation improvements. Resolver One 1.3 was a major release that I didn't cover on this blog. It had several major new features : Row and column level formulae Improved startup time An option to trigger a recalculation, reloading all imports Various API and usability improvements, plus bugfixes We're currently working on the next major release of Resolver One, version 1.4 . The major features in this include moving to IronPython 2 and preliminary support for using Numpy in your spreadsheets through Ironclad . The spreadsheet challenge is a competition run by Resolver Systems. We're offering $25000 in prize money for the best spreadsheets created with Resolver One. The Resolver One Spreadsheet Challenge We're so confident about the revolutionary potential of Resolver One that we've set up

Philipp Sumi has been looking at performance optimizations when using IronPython hosted from C#. Reusing Import Symbols to Avoid Performance Hits Lets do an artificial sample: The snippet below just increments a variable by one. As expected, it executes blazingly fast - after compilation, it executes a few thousand times without getting over a single millisecond: value = value + 1 Now look at the following example: import clr clr.AddReference('System.Xml') from System.Xml import * value = value + 1 Basically, this snippet performs the same logic (incrementing the ‘value’ variable), but it contains an import for the System.Xml namespace. It’s not necessary, but it still needs to be compiled. Executing this (compiled!) script 4000 times takes over 5 seconds! From a hosting point of view, the extra time is spent populating the namespace (the ScriptScope ) in which the code is executed. Philipp shows how to reuse imports by creating new scopes from a pre-populated SymbolDictionary

Laurion Burchall has just posted the following message to the IronPython mailing list: I've added the esedb module (esedb.zip) to the release page of the ManagedEsent CodePlex projec t. This is still under development and I'm interested in comments, feedback and suggestions on how to do things better in Python. What is Esent? Esent is the Windows database engine. It is used by the Active Directory and several smaller applications on Windows clients (e.g. Windows Update). The same code is also used by Microsoft Exchange as their database engine. The unmanaged API is documented on MSDN and there is a managed interop layer on code plex. What is esedb? The esedb module uses the Esent interop layer to provide a persisted key/data store in a dbm-like way. The zip file contains the managed interop DLL and the Python module. The code uses the esent DLL which is part of Windows. This code will work on Windows XP up (it won't work on Windows 2000). That does mean that this module wil

Shay Friedman works at a startup called ActionBase , and has a blog " chatting about IronRuby, IronPython, the DLR, Office and more ". He already has several entries about IronRuby, the new dynamic keyword in C# and presentations that he has done. One particularly useful entry is a collection of resources on dynamic languages on the .NET framework: Getting Started with Dynamic Languages For IronPython he lists: Resources IronPython homepage Python tutorial Debugging IronPython Code in Visual Studio Planet IronPython IronPython Cookbook Recommended Blogs Harry Pierson - IronPython product manager IronPython URLs (of course!) Jim Hugunin IronPython team blog Martin Maly Srivatsn Narayanan Shri Borde He also lists resources for IronRuby, IronScheme and the DLR.

Harry Pierson has been playing with Windows Azure and the Live Framework . IronPython and LiveFX: Accessing Profiles In this first post he uses the Live Framework SDK, showing IronPython code to do the following: I retrieve the user’s ID and password using raw_input (Python’s equivalent to Console.ReadLine ). Finally, I connect to the user’s LiveOperatingEnvironment and pull their name, email address, personal status message and the number of contacts they have. IronPython and LiveFX: Raw HTTP Access In the second post he accesses LiveFX via the raw HTTP interface rather than the .NET assemblies. He again shows IronPython code using WebRequest - with XmlReader to handle XML and uhm... simpler techniques for handling JSON. IronPython and LiveFx: Ori's LiveEO.py In the third post on LiveFX rewrites his scripts to use the LiveFX Python module by Ori Amiga the Live Framework group Program Manager.

The UK MSDN Flash developer newsletter features an article on the Dynamic Language Runtime by Mark Bloodworth : Combining Dynamic Languages and Static Languages Traditionally, there has been tension between dynamic languages and static languages. Each language has its distinct strengths and weaknesses, which means a choice: constrain yourself to one language or face the pain of language interoperability. The Dynamic Language Runtime (DLR) solves this problem. The Common Language Runtime (CLR) provides a unified platform for statically typed languages. The DLR extends the CLR to provide a unified platform for dynamic languages on the .NET platform. This means that there is a common, unified platform for static and dynamic languages. By having one platform, which means one object world, the pain of language interoperability is history. In addition to dynamic languages such as IronPython and IronRuby , C# and VB will also, in the 4.0 release of the .NET platform, be able to ta

Jon Udell is at it again; this time looking at different ways to wrangle data with IronPython. I should get a life, I know, but I can’t help myself, one of my favorite pastimes is figuring out new ways to wrangle information. One of the reasons that IronPython had me at hello is that, my fondness for the Python programming language notwithstanding, IronPython sits in an interesting place: on Windows, side by side with Office, where a lot of information gets wrangled — particularly in spreadsheets. Two IronPythonic Spreadsheets He has been looking at two very different ways of working with spreadsheets, and both of them have IronPython integration. The first of these is a tool called Inference.NET , which is part of the Inference suite that integrates statistical and analytical tools into Microsoft Excel. Inference.NET allows you to use the " general-purpose scripting capabilities of the dynamic .NET languages, including IronPython and IronRuby ". The second is Resolver One

Bernie Almosni looks at extending C# applications with IronPython. He shows how to use the DLR hosting API to create a 'rules engine' for the application - and example IronPython code for adding new rules. Extending your C# application with IronPython I think that in almost every enterprise application project at some point you’ll come to the conclusion that you need extension points in the system. It can be a Rule Engine, a Workflow of some sort or a pluggable User Interface. So now you want to give someone else the ability to extend or modify the application’s behavior with a minimal effort and time. Of course it’s possible to achieve this with custom tools and code generators that compile and load at runtime, but these solutions are complex and time consuming. Utilizing the DLR as an embedded scripting engine is easy and for my opinion quite elegant.

As promised, a small collection of links showing people doing useful, interesting or just plain odd things with IronPython. Python Swings; Ruby still doesn't This first post definitely falls into the odd category. Steve Gilham continues his experiments using the Swing Java UI toolkit from IronPython. This time he creates Python code that runs unmodified on the JVM (with Jython) or the CLR (with IronPython). He also attempts the same thing with Ruby, using JRuby and IronRuby. It's hard to tell whether there are fundamental problems with his approach on IronRuby or whether it just needs to mature. IronPython 2 & Microsoft Research Infer.NET 2.2 Apparently Infer.NET is: " a .NET framework for machine learning. It provides state-of-the-art message-passing algorithms and statistical routines for performing Bayesian inference. It has applications in a wide variety of domains, including information retrieval, bioinformatics, epidemiology, vision, and many others. " Larr

Another selection of interesting links related to IronPython and the Dynamic Language Runtime. Encoding Name Normalization in Python Notable in that this is the first blog entry in a long while from Seo Sanghyeon, maintainer of FePy the community distribution of IronPython. The blog entry focuses on the differences between how CPython (the reference implementation) and IronPython do encoding name normalisation in the codecs module. So Python normalizes encoding names received from codecs.lookup. How exactly this is done isn't really specified. But did you know that the following code work with CPython? (I don't recommend this!!!) import codecs codecs.lookup('utf!!!8') Yes, those are three exclamation marks. I'm not kidding... Jimmy Hacking (at) Microsoft Jimmy Schementi is part of the dynamic languages team at Microsoft and maintains the integration with Silverlight. This blog entry is really a presentation that he gave in December, but it has lots of interesting

John Udell is a well known blogger with an interest in Python, who now works for Microsoft. Recently he has been exploring various aspects of working with Microsoft technologies with Python, including several posts on using the new cloud computing platform Azure. His first post doesn't show much code: Hello World But what happens behind the scenes is quite interesting to me. The URL hits a deployment in the Azure cloud where I’m hosting an IronPython runtime. Then it invokes that runtime on a file that contains this little Python program: hello = "Hello world" Finally, it gets back an object representing the result of that program, extracts the value of the hello variable, and pops it into the textbox. This is the proof of concept I’ve been looking for. He updates this post with a status report: IronPython/Azure Status Report I’m exploring the viability of Python as a way of programming the newly-announced Microsoft cloud platform, Azure. Partly that’s because I love Pyt

Extension methods are a feature of .NET 3 that allows you to add methods to existing types. These are effectively static methods, but are called as if they were instance methods on the extended type. Saveen Reddy has a blog entry on using these methods from IronPython. Consuming Extension Methods in IronPython One of my projects implemented in C# makes frequent use of extension methods. Recently I started using IronPython to script that project and what I learned is that consuming those extension methods in C# is straightforward but with IronPython some extra work is involved. It turns out to be harder than it should be...

Another practical example of using IronPython for system administration, this one using WSUS (Windows Server Update Status). Cleanup WSUS - Remove Computers No Longer in the Domain One thing I love about WSUS is the ability to monitor the presence of clients. It gives me a good approximation of the last time a computer was on the network. I often use this information to help me clean missing computers out of Active Directory. But what about when a computer is removed from the domain before it is removed from WSUS? Rather than manually checking, I wrote an IronPython script that compares the list of computers in Active Directory with the computers on WSUS. When I run this script, it lists computers that should be removed from WSUS, and deletes them for me (after prompting). Requires WSUS 3.0 API, specifically Microsoft.UpdateServices.Administration.dll . As long as that library is available, the script doesn't need to be run on the server itself.

Continuing his IronPython and Microsoft Technologies series, Harry Pierson has posted four articles on working with XML and Linq from IronPython. Part 1: Introduction Part 2: Screen Scraping Part 3: Consuming Atom Feeds Part 4: Generating XML Linq stands for Language Integrated Query and is part of .NET 3. It adds first class support for querying data sources to C# and VB.NET. Underlying this are libraries that can be used from any .NET language (whether it has syntactic support for Linq or not.) In its basic form, "Linq over objects" is remarkably similar to Python list comprehensions and generator expressions. IronPython doesn't have syntactic support for Linq, but you can use the libraries. Part 2 of this series does exactly this: LINQ to objects works just fine from IronPython, with a few caveats. First, IronPython doesn’t have extension methods, so you can’t chain calls together sequentially like you can in C#. So instead of collection.Where(…).Select(…), you have t

Rob Oakes has set about learning Python through IronPython, and has written a series of articles that both document his progress and serve as a tutorial for others following in his footsteps. He starts with a confession and a manifesto: Learning IronPython - Part 1 - A Halfhearted Manifesto There are certain times for confessions, and now seems like such a time so … here goes: My name is Rob, and I’m an addict. I am addicted to Matlab. If I didn’t have Matlab, my productivity would go to near-zero. For this reason, like any good junkie, I tolerate its expensive fees, obnoxious quirks and serious limitations. That is, until recently. Some recent events, however, have forced me to start looking for alternatives. [...] I have made a serious decision: I am going to learn Python! And why Python? Like Matlab, it is a dynamic (or scripting) language. Like Matlab, it has an enormous number of existing libraries and functions available. Indeed, after a bit of surface scratching, I’ve come to t