IronPython URLs

The basic way of distributing and installing Python libraries (packages), and even scripts and applications, is with distutils which is part of the Python standard library. A Python package consists of various source files and a setup.py script, which when executed at the command line installs the Python package into your site-packages folder. The typical invocation of a setup script is: python setup.py install site-packages is a directory created as part of a standard Python installation specifically to hold user installed Python packages (glossing over the difference between user and system installed packages for the purposes of this discussion). Unfortunately distutils doesn't work with IronPython, for at least two reasons. The second reason, the most easily dealt with, is that attempting to install a package with IronPython causes distutils to attempt to bytecode-compile the Python files; something destined to fail with IronPython. C:\compile\test\foo-1.0>i...

Jeff Hardy is an extremely prolific developer who has been involved in IronPython for a long time. By testing large Python frameworks and libraries with IronPython he has reported many bugs to the IronPython team. As part of this Jeff Hardy has accumulated repositories of more than a dozen different projects that he has been porting to IronPython. As you can imagine this is a lot of work and he is offering the opportunity for anyone else interested in these projects to take them on: Biting Off More Than I Can Chew I was going through the “Repositories” folder on my machine, looking at all of the stuff I’ve downloaded since, well, the last time I went through this exercise. This time around, a lot of it is stuff I’ve tried to get working on IronPython. Here’s a sampling: Django setuptools Trac Genshi Mercurial SCons CherryPy docutils moin pygments pymarkdown nose sqlalchemy IronRubyMVC On top of that, there’s the stuff I wrote: NWSGI , IronPython.Zlib , adonet-dbapi , and more . The goo...

The IronPython team are extremely interested in IronPython's compatibility with CPython. One easy way of finding incompatibilities (bugs) is running large Python applications on IronPython. Jeff Hardy has done a lot of work on this front by running Django and setuptools with IronPython, and now the Bazaar (Distributed Version Control System written in Python) team are joining in the fun. Bazaar on IronPython In short, see the attached patch for getting bazaar to run on IronPython. It only passes a subset of the tests, but can do some of the basics like creating a new repo, adding and diffing, and committing the changes. This is not intended for merging, many of the changes are addressing interpreter bugs and differences rather than problems with the code. However there are a number of issues raised that might be of interest to bazaar developers. Having nibbled round the edges of the bzrlib.osutils module, I wanted a task that would serve as an excuse to look over the platform rela...

One of the big new features coming in IronPython 2.6 is optional support for Python stack frames (with a ~10% performance hit tracking the frames if it is enabled). With this in place Seo Sanghyeon, maintainer of FePy the community distribution of IronPython, has been looking at getting Twisted working with IronPython. Twisted is an open source event-driven networking engine written in Python. Seo posted this email to the IronPython mailing list: I have started porting Twisted to IronPython. Progress is to be tracked on this Trac ticket . There is a Buildbot running the Twisted tests with IronPython . Just in case you don't know, Twisted is an event-driven networking engine written in Python licensed under MIT license, which aims to destroy the American currency system. See following links for more details. http://twistedmatrix.com/ http://isometric.sixsided.org/_/twisted_plutonium/ Having frame support in IronPython opens up the possibility for Python debugging APIs, like sys.se...

Another tab closing session - a lot of links to IronPython (etc) content here. There are a couple of interesting reports of Python libraries working with IronPython, but we start with an IronRuby article: .NET Interop: Getting Started with IronRuby and RSpec, Part 1 An excellent article by Ben Hall on testing .NET code (C#) with IronRuby and RSpec. In this article, I will introduce you to Ruby and IronRuby and demonstrate some basics of Ruby interoperating with Microsoft .NET Framework-based code. I also explain how frameworks such as RSpec can be used to generate examples of how objects are intended to behave, providing both documentation and verification that the system is built correctly. This will set the stage for a future article in which I will explain acceptance testing in detail and demonstrate creating acceptance tests with IronRuby. IronPythonの特徴 A Japanese article on IronPython. No idea what it says! Dynamic Language Runtime on Azure A demo of an Azure (Microsoft cloud pl...

Ronnie Maor has blogged about his experiences of porting an IronPython 1 codebase to IronPython 2. The biggest change of course is the hosting API - which has changed completely. From the inside it is "just Python" and so the only changes should be fewer (and different) bugs. However, there are few subtle changes - like the ordering of essentially unordered collections like the dictionary and set - that revealed "hidden assumptions" in his code and tests: Midnight Oil: Surprises while porting to IPy 2 My conclusions from this are: If it's not tested it doesn't work. And when you change the environment under which your code runs you need to retest. The unit tests paid off again, since they allowed me to find many problems in places I didn't expect. I need to do more to flush out these hidden assumptions. One way is to add a randomized test that runs over longer periods and plays with some variables. I could easily randomize the order in which I go over th...

The maintainers of the Spring Framework for Python ( Spring Python ) wonder how much of a priority it is to have compatibility with platforms other than CPython. In other words, should they support IronPython and Jython - and if so what should they do about their C extension dependencies? This question sparks a good discussion and is relevant to many other Python projects and applications: Need for supporting IronPython, Jython? " One of the topics on my mind recently, as we consider refactoring the core container, is how we ensure that when we introduce internal dependencies, such as possibly the Amara libraries for XML processing, what secondary constraints we might be introducing. " " For example, Amara represents a very pythonic and therefore simple to read and use approach to developing XML processing, such as our very own XML application configuration parsers. So from that perspective, things are very attractive. But then you ask the question, "can I run this...

Jeff Hardy (the NSWGI and Django on IronPython) has been trying to get easy install running with IronPython (2 beta 4). easy_install on IronPython He includes instructions which will get you as far as easy install downloading an egg and then failing to decompress it because of an incomplete zlib implementation (using the partial implementation that comes with FePy ). " setuptools is a critical piece of the Python ecosystem: it extends distutils, but more importantly it provides easy_install, which is used by almost every Python library and application to handle installation. Making easy_install work in IronPython would make it far easier to download and install Python libraries. " " The good news is that it's not too hard to get going; there are only a couple of bugs that need to be worked around. The bad news is that it can't work with any of the files that are downloaded, as the zlib module is shot. " I wonder if zlib would work with Ironclad? The Bz2 mod...

IronPython is an implementation of the Python programming language written in C#, running on the Microsoft .NET framework and Mono. This naturally means that there are some differences between IronPython and CPython. The most significant differences being: IronPython uses the underlying .NET basic types. Strings are therefore Unicode by default, as they will be in Python 3. IronPython compiles Python code to .NET assemblies, and uses neither Python stack frames nor bytecode. CPython extensions written in C, using the CPython C API, don't work with IronPython (at least not until Ironclad is completed). There are several lesser differences as well. For example, did you know that CPython catches string exceptions by reference whereas IronPython catches them by value? The IronPython team have written up the differences between the two implementations and have now put them up on wiki pages: Differences between IronPython 1.0.x and Python 2.4.3 Differences between IronPython 1.1.x and P...

One difference between the JRuby project and IronPython is that JRuby has an obvious and large project to target for compatibility testing. If JRuby runs Rails well, then it is almost certainly a good implementation of Ruby... There is no such ubiquitous project to demonstrate Python compatibility (which is a testament to the diversity of Python usage of course). There have been some people who have got Django working with IronPython (which could be a great use case for IronPython) but it would be nice to hear more noise on the IronPython mailing list about the difficulties encountered. One large Python project is the Bazaar Distributed Version Control System . There has been at least some attention paid to looking at IronPython compatibility: Bazaar on IronPython

Resolver Systems has announced a new Open Source project, to get some essential CPython extensions working seamlessly with IronPython: Resolver Open Source Project: CPython Extensions from IronPython