One option might be a non-technical solution: Instead of you redistributing the library (or modified library) we distribute it w/ IronPython - and then you're just including the combined package. There's other reasons why it'd be good for us to do this (help, encodings, warnings, etc...).Michael's understanding of this is in reference to the complete Python standard library rather than just the Decimal module. If so this is excellent news for all Python users, since it will broaden the common code base between CPython and IronPython and make portability between the two environments easier to achieve. It would be interesting to know whether the developers and maintainers of FePy, the open source IronPython distribution, would view such a move with apprehension or relief. Internationalization support can be a significant effort, and Microsoft have a lot of experience in that area.
My own hope is that this move might eventually broaden the support base for the standard library, which hasn't developed as much as I had hoped in 2.5. There will be some sort of reorganization of the library in (I think) 3.1, but I haven't heard much about that yet.
Michael Foord's blog post is amusingly prioritized from an industry perspective, which is one of the charms of the blog: he was reporting big things for Resolver, which I am sure will become a significant Python application in short order. But it's a little like "Three Hundred Japanese Killed in Earthquake: Ohio Man Breaks Ankle" with a different twist. Good luck in Barcelona, Michael (and in New York and Paris too, guys).
I suspect that we have just seen the magic of the Python license at work: there isn't much doubt in my mind that Python's explicit permission to redistribute for broad purposes without opening up your own code makes it easier for organizations with a large proprietary code base to incorporate the language into their own technologies. I know from reports at PyCon that Jim Hugunin has been surprising audiences inside and outside Microsoft at how easy it is to do things in the .NET environment with Python. Surely full IronPython support in Visual Studio must inevitably follow.
2 comments:
"Ohio Man Breaks Ankle" - I've never even been to Ohio! ;-)
I guess I tried to squeeze too much into that blog entry. Glad you managed to pull out the 'important announcement' bit. I do think this is important for IronPython.
With the standard library as well, .NET users who come to IronPython (and are much less likely to come via FePy which already includes the stdlib) will come to something that is much more recognisably Python.
I think Seo (who is basically the 'FePy guys') will be very pleased with this. FePy does come with several *extra* packages and patches the IronPython makefiles so that it builds cleanly with Mono. It also has patches for extra functionality - so FePy will still be a useful project even if IP comes with the standard library.
Actually the library reorg will hopefully happen in 3.0. It basically requires me to find the time to do it. =)
Post a Comment