When assigning a subtype of list to a list slice the implementation 
of slice-assignment directly accesses the list representation and 
ignores any modified accessor functions:

class MyList  (list):
    def __getitem__(self, idx):
        if idx % 2 == 0:
            return 'E'
        return 'O'

mylst = MyList()
mylst.append(1)
mylst.append(1)

lst = [ 1, 2, 3, 4]
lst [2:3] = mylst
print lst
# prints [1, 2, 1, 1, 4] I'd expect it to print [1, 2, 'E', 'O', 4 ]

Logged In: YES 
user_id=580910

The attached patch (list_ass_slice.patch) updates the implementation of 
slice assigment for lists: If the RHS is a list (exact match) use the 
current implementation and if the RHS is a sequence use 
PySequence_GetItem.

Logged In: YES 
user_id=6656

I think this is now fixed, via a somewhat different approach.

You might want to check, though.

While we're at it, there are a bunch of problems with your
patch (for future reference):

1) it contains a bunch of NUL bytes!
2) it's a straight diff.  we like context (-c) or unified
(-u) diffs.  most people prefer context diffs, I think. 
Bass players (e.g. Barry) prefer unified.
3) it has no error checking at all!

Logged In: YES 
user_id=580910

Sorry, but it is not fixed completely. The problem is in PyList_AsTuple 
(called by PySequence_Tuple if the arguments is a PyList). 
PyList_AsTuple directly accesses the list representation, and therefore 
the code above still fails. I'll try to post a patch for this later this week.

I'm not sure why the patch got corrupted, it (and still is) fine on my 
system (but not when I download it again...). 

Logged In: YES 
user_id=6656

Sigh.  More s/PyList_Check/PyList_CheckExact/ I guess.

Logged In: YES 
user_id=6656

I've thought about this a bit.

You're writing a NSArray proxy, right?

Here's some advice: do NOT inherit from list.

What does inheriting from list get you?  The ability to pass
`PyList_Check'.  But almost inevitably code that calls that
promptly pokes into the internal structure of the list.  For
example, you'll find iterating over your proxy list doesn't
respect the subtype (unless you supply an __iter__ method, I
guess/hope).

If you find things that fail because of this, let's fix
those to take more general sequences.

Logged In: YES 
user_id=580910

I already have an NSArray proxy (actually a module that proxies the 
entire Cocoa classtree on MacOS X). The NSArray proxy is not a 
subclass of list but part of a class hierarchy that mirrors that of the 
proxied classes (the code is available from pyobjc.sourceforge.net).

The reason I ran into this bug is that someone suggested that 
subclassing list might be a good solution for using an NSArray as the 
source for slice assigment on lists. Thanks to your previous patch that 
is no longer an issue.

It might be usefull to add functions that check if it is save to directly 
access the list representation. Even though it might not be sensible to 
do so, it is possible to change __getitem__ et. al. from Python code and 
it would be very strange if the version of those methods from 
subclasses is sometimes ignored. 

Logged In: YES 
user_id=33168

Michael is there still a bug here or should this be closed?

Logged In: YES 
user_id=6656

Not sure :-/

Actually, the extended slices stuff should grow to accept non-lists on the RHS, so the report should stay open.

What's less clear is whether tuple(list_subtype) should respect the subtype.  There are so many places where the subtype is not respected, I'm inclined to leave it be.

Logged In: YES 
user_id=6656

Checked in

Objects/listobject.c revision 2.142
Lib/test/test_types.py revision 1.43

to allow arbitrary sequences on the RHS of assignment to
extended slices.

Closing.