[IronPython] IronPython 2: Bug in Indexing (Blocker)

Dino Viehland dinov at microsoft.com
Wed Nov 5 22:23:18 CET 2008


Thanks for the report.  I've opened CodePlex bug #19350 to track this (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19350).

I believe the fix is actually pretty simple and we'll discuss whether we'll take it for 2.0 final at our Friday team meeting.  If you want to try out the fix either to unblock yourself or just see if there's other issues lurking behind it you can do this change:

                          return new MetaObject[] {
                        arguments[0],
                        new MetaObject(
                            Ast.Call(
                                typeof(PythonOps).GetMethod("MakeTuple"),
                                Ast.NewArrayInit(typeof(object), tupleArgs)
                            ),
-                           Restrictions.Empty
+                           Restrictions.Combine(arguments)
                        ),
                        arguments[arguments.Length-1]
                    };

If you just search for "return new MetaObject[]" in PythonProtocol.Operations.cs you'll get to the right spot.  There's a 2nd spot about 20 lines later for the getter case which has the same issue & fix.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Wednesday, November 05, 2008 8:03 AM
To: Discussion of IronPython
Subject: [IronPython] IronPython 2: Bug in Indexing (Blocker)

Hello Guys,

Discovered a bug in indexing Python objects in IronPython 2.

The following code:

class X(object):
    def __setitem__(self, key, value):
        print repr(key)

def f(a, b):
    X()[a, b] = object()

f(1, 2)
f('one', 'two')

Produces the following exception:

Traceback (most recent call last):
  File "bugtest.py", line 9, in bugtest.py
  File "bugtest.py", line 6, in f
TypeError: Specified cast is not valid.

It looks like IronPython has a call site that is now expecting integers
the second time round.

Switching to using explicit tuples for indexing works around the problem:

    X()[(a, b)] = object()

However this kind of indexing is an *extremely* common way to use our
spreadsheet API from user code, so we couldn't release with this bug in
place.

(Doing the indexing outside of the function also avoids the problem
interestingly enough.)

All the best,

Michael Foord

--

Michael Foord
Senior Software Engineer, Resolver Systems Ltd.
michael.foord at resolversystems.com
+44 (0) 20 7253 6372

Try out Resolver One! <http://www.resolversystems.com/get-it/>

17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK

_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



More information about the Ironpython-users mailing list