Thanks for the explanation. I like the "opt in" idea -- taken to its fullest, that could allow .Net-style decorators on an opt-in module basis, could it not? And I see the point about the "many platforms in one codebase" approach you describe as a way of enabling the larger Python community. By pursuing both approaches, the many-in-one and the opt-in to the fullest, I think IPy can continue to fulfill what I understand now to have been the original goal, of serving the Python community, while also providing an enticing alternative to static .Net languages for non-Pythonistas looking for a more comfortable home.
In the meantime, I know where to go when I get stuck on how to use ClrType.py to use .Net attributes. You probably know where I can go, too, but we're probably thinking of different places. <s> thanks again, Hank On Tue, May 18, 2010 at 4:50 PM, Dino Viehland <di...@microsoft.com> wrote: > 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:* users-boun...@lists.ironpython.com [mailto: > users-boun...@lists.ironpython.com] *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 > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com