|This article is of interest to the following WikiProjects:|
- 1 IronPython 3 Implementation
- 2 ironpython
- 3 see also setence is bad
- 4 Simple Windows Forms application
- 5 Link to "Python IDE Project" is bogus.
- 6 Difficult to read?
- 7 Why "Iron"?
- 8 Sample code
- 9 Unrelated reference removed
- 10 Removed Introductory Sentence
- 11 The Issue of Compatibility
- 12 ironpython IDE
IronPython 3 Implementation
My understanding is that IronPython is not attempting to be a complete Python implementation. Can someone please further describe what IronPython really is other than just the whole python on dotnet rigamaroll?
- IronPython is definitely trying to be a complete Python implementation. Do you have any evidence to the contrary? Sanxiyn 07:18, 18 June 2007 (UTC)
I expanded this article by describing (in my view) why IronPython make sense. Essentially, when developing a complex application framework, the server-side developer rarely understands how the downstream client-side developers will want to use the framework. Therefore, it often makes sense to push responsibility for developing analytics from the server-side to the client-side.
IronPython greatly simplifies this objective, particularly since .NET is fairly rigid in the way it supports dynamic code structures. By integrating IronPython into an existing framework, the server-side developer, with minimal work, can greatly expand the range of analytics that client-side developer has access to. Instead of tweaking the interface everytime a new request comes in, the server-side developer can concentrate on maintaining clean data structures.
I highlighted this with a short example.
Hope this makes sense.
- Is it possible to restrict the capabilites of a script sent from the client to the server? If not, one could try to insert som dangerous code into the server...
see also setence is bad
See also Boo, a language for .NET and Mono based on Python, but has features borrowed from C# and Ruby such as static typing and anonymous closures.
it may give the impression nthat Ruby has static typing which AFAICT it doesn't --Nkour 13:27, 23 November 2005 (UTC)
Simple Windows Forms application
The Simple Windows Forms application section is a how-to, and doesn't belong in an encyclopia article. 18.104.22.168 21:36, 28 August 2006 (UTC)
I have removed the how-to section : Hessian
Link to "Python IDE Project" is bogus.
The link to the "Python IDE Project" seems to be spam.
Difficult to read?
Honestly, I don't understand most of the article. I think it should be improved. Only thing I take away is that everything is somewhat dynamic. —Preceding unsigned comment added by 22.214.171.124 (talk) 03:09, 10 March 2008 (UTC)
Is there any reason why the language has got the prefix "Iron"? With Jython or JPython it's clear, but what is so "Iron" about .NET? Is there any official explanation of the name? If so, it should be mentioned. —Preceding unsigned comment added by 126.96.36.199 (talk) 12:20, 19 March 2008 (UTC)
- This would be interesting to know. It's probably just the name that they decided (Nython doesn't really click) and then IronRuby and IronScheme just followed along. MahangaTalk 23:06, 19 March 2008 (UTC)
I rewrote the loop in the code sample to use the more Pythonic list comprehension syntax. However, I am confused about that last line there; why is the list being stated on its own line? Not sure what to do with it. Rainault (talk) 17:49, 5 June 2008 (UTC)
(Full disclosure - I work for Resolver Systems)
The referenced page "Differences Between Resolver One's Formula Language and Python Expressions" does not make the point that it was being cited to support. Although Resolver One is written in IronPython, and is not compatible with CPython, the referenced page is not related to this. Instead, it is description of a DSL used within the application, and in particular how that particular DSL differs from Python. I was bold and removed the reference.
I don't think there is a page on the Resolver Systems website that explains how and why Resolver One is not CPython-compatible. There probably should be! I will put something here when there is - directly into the article if no-one objects.
Removed Introductory Sentence
The following sentence in the introduction did not make sense as written, had no citation and seemed to be biased against the open source nature of the project "As the open source license of IronPython does not apply to parts of its documentation, including the comparison fact sheet, it is not clear of how these differences affect compatibility with the reference implementation of CPython.". I don't think such discussion was helpful in the introductory status - I left the statement that products developed on top of IronPython are not compatible with CPython, although that is hardly the point of IronPython (to leverage the .NET framework through Python). MichaelFoord (talk) 19:27, 4 October 2008 (UTC)
The Issue of Compatibility
The water is being muddied here without need. There are two main issues with compatibility language and libs
IronPython seeks to be 100% language compatible...
It's well integrated with the rest of the .NET Framework and makes all .NET libraries easily available to Python programmers, while maintaining compatibility with the Python language.
It intends to be language compatible, and integrate with the .NET libraries. There's not a lot of ambiguity here as it doesn't speak to Python libs. Python libs written in Python should run in IronPython and if they don't might be considered a bug as they should be able to rely upon Python compatability.
Python libs written in C (or whatever) as pyd extensions can not be expected to run out of the box as that would be a different compatibility issue extirely.
IronPython is a Python language implementation.
Applications written in Python may or may not be compatible with either IronPython or CPython (or JPython) depending on whether they use .NET specific features or C specific features (or Java specifc features).
Appplications written in Python may or may not be compatible with either *nix or Windows systems depending on whether they use Windows specific features or *nix specific features.
This is not a controversial area for a language to be in. There is no drama here. There are no tricky aspects that haven't been visited many times with other languages before. There is no divorcement from common sense.
Historically the Python community has already dealt with such issues over windows which are why there are windows specific parts of the Python libs. It is why there are python and pythonw versions of CPython.
The list of Iron pyhton IDE could be place in the page http://en.wikipedia.org/wiki/Comparison_of_integrated_development_environments#IronPython instead speak of some ide in this article . ~~ —Preceding unsigned comment added by 188.8.131.52 (talk) 18:42, 8 August 2009 (UTC)
Though it claims to be significantly faster than CPython, the references show it is only faster in a few cases, and slower in most others.Maybe "IronPython is generally slower than CPython, ..., but can be faster for some tasks" instead? 184.108.40.206 (talk) 16:05, 12 August 2009 (UTC)
- It is faster than CPython. Check yourself. Shootout reference runs IronPython on Mono, which is quite different from running IronPython on .NET. On the other hand, performance difference between Mono and .NET would be good to include. Sanxiyn (talk) 06:00, 14 August 2009 (UTC)
- The referenced PyBench benchmark indicates mixed results. Seems there are two areas where IronPython has performance deficiencies. First dictionaries - IronPython seems to be about 100 % slower on some of the dictionary stuff. Secondly, exception handling, IronPython seems to be faster when exceptions aren't raised. But raise an exception, and IronPython hits a brick wall - 50 x slower. IronPyton looks to be faster for a lot of things, though. In the end, your results will vary with your application mix. --Aflafla1 (talk) 21:52, 18 November 2010 (UTC)