| msg13046 - (view) |
Author: Ronald Oussoren (ronaldoussoren) *  |
Date: 2002-11-04 08:19 |
| 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 ] |
|
|
| msg13047 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2002-11-04 11:04 |
| 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. |
|
|
| msg13048 - (view) |
Author: Michael Hudson (mwh) |
Date: 2002-11-05 18:15 |
| 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! |
|
|
| msg13049 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2002-11-06 08:45 |
| 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...). |
|
|
| msg13050 - (view) |
Author: Michael Hudson (mwh) |
Date: 2002-11-06 11:21 |
| Logged In: YES user_id=6656 Sigh. More s/PyList_Check/PyList_CheckExact/ I guess. |
|
|
| msg13051 - (view) |
Author: Michael Hudson (mwh) |
Date: 2002-11-11 11:50 |
| 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. |
|
|
| msg13052 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2002-11-11 12:26 |
| 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. |
|
|
| msg13053 - (view) |
Author: Neal Norwitz (nnorwitz) * |
Date: 2002-11-14 03:43 |
| Logged In: YES user_id=33168 Michael is there still a bug here or should this be closed? |
|
|
| msg13054 - (view) |
Author: Michael Hudson (mwh) |
Date: 2002-11-14 13:23 |
| 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. |
|
|
| msg13055 - (view) |
Author: Michael Hudson (mwh) |
Date: 2002-12-05 21:33 |
| 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. |
|
|