The answer is kind of both. When it comes to the core language grammar we are (and I believe will always be) an equivalent set. That's rather important in that any code which is .NET specific can still be parsed by other Python implementations and therefore you can do various if I'm running on IronPython do this else if I'm on Jython do that or if I'm on CPython do something else - which is a fairly common pattern and even shows up in the standard library. When it comes to the various builtin types we intend to be a superset but that superset is only available after the user has specifically opted in to IronPython.
So let's look at some examples how this has played out. To add generic support we used Python's existing indexing support rather than adding parsing support for something like Dictionary<int, int> which would have matched C#. But at the same time we don't want to modify the core objects too much - for example a future version of CPython could choose to add indexing support to built-in functions to add some new feature of their own. Therefore our built-in functions which are generic are actually a subtype of the normal built-in function type and add indexing. Our normal built-in functions don't support indexing (types/generic types actually still need this treatment of not having indexing by default but I haven't gotten around to fixing that one yet). And of course we try and make sure that all of the extensions that we do offer are only available on an opt-in basis and that opt-in basis is per-module rather than tainting all code in the interpreter. That enables some code to be Python specific and other code to be Ipy specific. That's done via "import clr" (or importing any other .NET namespace actually) which makes any additional attributes that we've added to types available (for example __clrtype__ is not visible until you do an import clr). That enables us to expose things which are .NET specific but still allows pure Python code to run without seeing anything change - so for example if some code as doing dir() it's not going to freak out because there's some unexpected attributes. From: [email protected] [mailto:[email protected]] On Behalf Of Hank Fay Sent: Tuesday, May 18, 2010 11:11 AM To: Discussion of IronPython Subject: [IronPython] .Net attributes/decorators In reviewing the discussion of .Net decorators in the list (thank you Google Groups), I did not come across a discussion of what I saw as the central issue: is IronPython to be a Superset of Python (every Python program will run in IronPython, not every IronPython program will run in Python), or is IronPython to be an equivalent set (every Python program will run in IPy, and every IPy will run in Python). Has there been a discernment on this issue? For me, coming from a non-Python world, it makes sense to view IPy as a superset of Python. This perspective would, e.g., allow the use of .Net decorators on classes (which in turn would facilitate returning .Net objects). I've read about the ways of using __clrtype__ to do this in a Pythonic manner. My interest is in simplicity and clarity in my programs, rather than maintaining two-way compatibility (which I could not port to Python, in any case, for a .Net program using .Net features). thanks, Hank Fay
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
