[IronPython] Similarity with builtin types

Dino Viehland dinov at microsoft.com
Mon Aug 9 20:20:20 CEST 2010


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-bounces at lists.ironpython.com [mailto:users-bounces at 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 <dinov at microsoft.com<mailto:dinov at 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-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of mlkjih mlkjih
Sent: Monday, August 09, 2010 9:10 AM
To: users at lists.ironpython.com<mailto:users at 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 at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20100809/43110312/attachment.html>


More information about the Ironpython-users mailing list