#1 is definitely correct behavior, consider: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type "help", "copyright", "credits" or "license" for more information. >>> class c(object): ... def __getitem__(self, index): ... return index ... >>> c()[0:1.2] slice(0, 1.2, None)
It's Python's list implementation which is converting indexes to integers so you'll need to do that as well. You can do that via IronPython.Runtime.Converter.ConvertToIndex though. On #2 in theory we don't let you override existing members w/ extension members. But __getitem__ is taking precedence here because we pick up the List<T> version later in resolution via a .NET mapping than looking up members by name. But you can define the integer overload for __getitem__ and forward it to the real implementation. We could also consider just adding slicing support for List<T> to IronPython natively :) We probably can't do that for all IList<T>'s though in case there's one that accepts negative or out of range indexes. From: [email protected] [mailto:[email protected]] On Behalf Of Jeffrey Sax Sent: Wednesday, December 02, 2009 5:39 PM To: 'Discussion of IronPython' Subject: Re: [IronPython] Magic methods on CLR types I found 2 issues: 1. It looks like __index__ is not called for slice arguments of non-Python objects (like List<T>'s). Reading PEP 357 (which introduced __index__), I would expect __index__ to always be called, so that I can be sure that the slice components are either int, long, or NULL. (I haven't verified this in CPython.) 2. If I supply a __getitem__ method in my extension type (in my case with a strongly typed ISlice parameter), the underlying CLR indexers are no longer picked up. Extender assembly: [assembly: ExtensionType(typeof(List<>), typeof(ListExtensions<>))] namespace Compatibility.Python { public static class ListExtensions<T> { public static T __getitem__(List<T> a, ISlice slice) { return a[(int)slice.Start]; // Dummy } } } IP session 1: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type "help", "copyright", "credits" or "license" for more information. >>> from System.Collections.Generic import List >>> a=List[int]() >>> a.Add(55) >>> a[0] 55 >>> a[0:1.2] 55 >>> b=[1,2,3,4] >>> b[0:1.2] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: expected index value, got float >>> IP session 2: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type "help", "copyright", "credits" or "license" for more information. >>> import clr >>> clr.AddReferenceToFile("Compatibility.Python") >>> from System.Collections.Generic import List >>> a=List[int]() >>> a.Add(55) >>> a[0] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: expected ISlice, got int >>> From: [email protected] [mailto:[email protected]] On Behalf Of Dino Viehland Sent: Tuesday, December 01, 2009 8:57 PM To: Discussion of IronPython Subject: Re: [IronPython] Magic methods on CLR types If you want IronPython to recognize them you just need to create an assembly w/ ExtensionTypeAttribute and have it point at the extended and extending types. Then the assembly needs to be loaded into the ScriptRuntime using ScriptRuntime.LoadAssembly. We still need to figure out our story for recognizing and importing normal .NET extension methods that C# supports. From: [email protected] [mailto:[email protected]] On Behalf Of Jeffrey Sax Sent: Tuesday, December 01, 2009 5:27 PM To: 'Discussion of IronPython' Subject: [IronPython] Magic methods on CLR types Is there a way to add magic methods like __repr__, __call__, etc. to CLR types? 1. Can it be done in the external CLR assembly without polluting the API for other languages? If so, how? 2. Can it be done using F# style type augmentations by redefining such methods on the Python type corresponding to the CLR type? If so, how? 3. If neither of these alternatives is possible, is there a third way? Thanks! Jeffrey Sax
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
