UserList.__getslice__(): copy.copy(self.data) vs. self.__class__(self.data).
Tom Funk
_spam_sux_tdfunk at _spam_sux_nettally.com
Tue Mar 14 23:25:16 EST 2000
Alex:
Thanks so much for responding.
In an article posted 14 Mar 2000 17:37:00 -0500,
Alex (alex at somewhere.round.here) said:
> Sometimes, that's what you want, and, in my experience, sometimes not.
It seems to me that *not* carrying forward the currently active
attributes is counter-intuitive (of course, that's probably just me....).
*I* can't think of a case where I'd want to lose the attributes I'd built
up over the course of the current program execution when I slice off a
sub-set of the list of things I'm tracking. Can you give me an example
of where losing the additional attributes after taking a subset of an
existing collection is desirable?
Consider an inventory system and a class that implements an order, with
the list holding each of the order items. Each of the items "belongs" to
the order and shares the order's attributes: order number, ship date,
customer id, shipping address, etc. Assume further that the user changes
her order and she now wants only the middle three of the five items
ordered:
neworder = order[1:4]
The neworder instance shouldn't have to go back to the order instance to
collect the order-specific attributes (order id, customer id, etc.)
Or perhaps the last two items in the order are back ordered:
backordered = order[len(order)-1:len(order)]
backordered.status = Order.BACKORDERED
backordered.shipdate = None
backordered.bodate = DateTime.today()
In this instance, losing all the original order information would be a
huge pain, and would be counter-intuitive -- I'd expect the order ID,
customer ID, shipping address, etc, to end up in the new back ordered
instance.
With the other approach, all of the order attributes are lost and would
have to be copied from the original order. Ouch. What if I forget one?
Enter one sneaky little bug, hard to catch.
It just seems to me that if one goes to the trouble to create a class
(FancyList) that has attributes beyond the data attribute, then each of
the items in the list are "children" of FancyList and share the
attributes of FancyList. It's a one-to-many relationship. It seems to
me that slicing off a subset of the list would only rarely disconnect the
items in the subset from super-set. It also seems to me that such
behavior would be the exception rather than the rule.
> UserList is intended as a base class, so you can override any methods
> that aren't doing what you want.
True, but to my thinking the current implementation is neither intuitive
nor does it mimic a "real" list object. Shouldn't the counter-intuitive
and the non-list-like implementation be the overridden implementation
rather than the "normal" one? We learn how lists work when we learn
Python, but UserList doesn't act like a "real" list, and we have to be
aware of those differences when we use it - or suffer for it.
I'm not terribly experienced with Python and I stumbled over this quirk
myself. I expected UserList to act like a true list. When I decided to
inherit from it I gave the code a cursory glance and, seeing no
indication that UserList's behavior departs from that of a native list, I
started coding. The test cases I wrote bumped up against the deviations
-- I was treating the derived class like a real list, and it failed to
act like a native list object under certain conditions. This led to my
research and this series of messages and what-not.
My assertion is that UserList should mimic a true list object as
precisely as possible and any deviation from "acting like a native list"
should be left as an exercise for the implementor.
My biggest worry over UserList is that it doesn't properly handle out-of-
bounds negative numbers. Instead of raising an IndexError for what is
likely a programming error, it quietly returns an unexpected result. Not
good. Silently returning incorrect results goes against everything I
know about "defensive" programming. Steve McConnell would have a cow.
The purpose of my article was to elicit feedback on whether UserList.py
should be changed to mimic a real list. If I understand you correctly,
you believe that UserList, seemingly flawed as it is, should be left as
it is?
I've made my case as strongly as I can. Now I'll just sit back and tally
the "votes." <wink>
--
-=< tom >=-
Thomas D. Funk (tdfunk at asd-web.com) | "Software is the lever
Software Engineering Consultant | Archimedes was searching for"
Advanced Systems Design, Tallahassee FL. |
More information about the Python-list
mailing list