Because you can't do that in CPython. If we enabled that we'd certainly instantly start failing a number of tests and we might subtly break compatibility of libraries that might try do assign, catch a TypeError/AttributeError, and then do something else (even if that sounds like a terrible idea).
I also think it's nicer to be explicit here that you're doing something which requires IronPython by forcing the "import clr" so that it's clearer this code won't work on CPython. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of mlkjih mlkjih Sent: Monday, August 09, 2010 10:58 AM To: Discussion of IronPython Subject: Re: [IronPython] Similarity with builtin types >We won't ever support Ruby's mutation of everything under the sun including >built-in types simply because that's not something CPython supports. With clr.LoadClrExtensions using C# extension methods we can extend builtin types, public string DoSomething(this string str) ... so why not just allow use ironpython for this? String.DoSomething = ... 2010/8/9 Dino Viehland <di...@microsoft.com<mailto:di...@microsoft.com>> As far as extension methods go - and just extension methods - we may at some point in time support them. We won't ever support Ruby's mutation of everything under the sun including built-in types simply because that's not something CPython supports. The tricky part w/ the extension methods is doing it in a way which is per-module instead of at a global scope. In Ruby so much code mutates object that it's not really a big deal to add in some more mutation of types across the system. But w/ Python these sort of changes have always been more closely scoped - for example look at from __future__ import ... which effects only the current module. Another example is our own "import clr" which makes .NET attributes available on the built-in types. I suspect what we'll end up doing is something like: clr.LoadClrExtensions(namespace) So it'd end up looking like: import System Import clr clr.AddReference(System.Linq) I do want to do something to continue to push LINQ forward for 2.7 and maybe this will be it if I can get it in... Tomas added the metadata reader which we can use to efficiently get the extension methods and I think I might have an idea on how to efficiently share the extension methods across modules. So I guess the question now would be does that look like a reasonable way to load extension methods? From: users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com> [mailto:users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com>] On Behalf Of mlkjih mlkjih Sent: Monday, August 09, 2010 9:10 AM To: users@lists.ironpython.com<mailto:users@lists.ironpython.com> Subject: [IronPython] Similarity with builtin types http://ironpython.net/documentation/dotnet/dotnet.html#similarity-with-builtin-types What's the point? Is there any plans to support extension methods, something like IronRuby's using_clr_extensions? With immutable types it cannot be done, am I right? _______________________________________________ Users mailing list Users@lists.ironpython.com<mailto: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
