> (2) For 2.x, I'm a bit uncomfortable with introducing the extra Python layer 
> on top of the C layer.  Partly I'm worried about accidentally breaking 
> something (it's not 100% clear to me whether there might be hidden 
> side-effects to such a change),

I understand.  I am worried about that as well. The main area that 
concerns me is the interface for the 'Struct' class.  I did my best to 
match the methods and functions from the C implementation.  I need to 
look into this in more detail, though.  One quirk I currently know 
about is that the following methods:

   '__delattr__', '__getattribute__', '__setattr__', '__new__'

show up in 'help' for the C implementation, but not the Python one.  
Although, the implementations do exist in both places. 

> but I also notice that this seems to have a significant impact on performance.
> In fact, I seem to recall that the previously existing Python component of 
> the struct module was absorbed into Modules/_struct.c precisely for 
> performance reasons.
>
> A quick, unscientific benchmark:  the time taken to run test_struct with this
> patch (excluding the changes to test_struct itself) on my machine (OS X 10.6,
> 64-bit non-framework non-debug build of Python) is around 1.52--1.53 seconds; > without the patch it's around 1.02--1.03 seconds.

Agreed that this is not a really scientific benchmark.  I did 
experiment with this idea a little further though on my machine (OS X 
10.5 32-bit):

==============================================
| Configuration                    | Seconds |
==============================================
| Original                         | 1.26    |
----------------------------------------------
| __index__ patch v1               | 1.88    |
----------------------------------------------
| Hoisted imports out of functions | 1.53    |
----------------------------------------------
| Hoisted imports and no __index__ | 1.34    |
----------------------------------------------

So with this simple experiment pulling the 'imports' out of the function
wrappers made quite a difference.  And, of course, removing the 
'__index__' transform brought the times down even more.  So, the 
wrapper overhead does not look to be terrible for this simple test.

However, as you alluded to, we should find a better benchmark.  Any 
ideas on a good one?
 
> (4) For 2.x, perhaps we don't need the extra __index__ functionality anyway, 
> now that the previous use of __int__ has been restored.  That would give us 
> a bit more time to think about this for 3.x.

Agreed.  Thanks for taking the time to look at the patch anyway!