[Python-bugs-list] [Bug #115928] UserList.__getslice__ and co break previous behaviour

[noreply@sourceforge.net]

Bug #115928, was updated on 2000-Oct-03 09:41
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: UserList.__getslice__ and co break previous behaviour

Details: When I make a class MyL derived from UserList, and a MyL instance named l, then l[:] returns a true list (in the sense that it responds to list operators).

Well, this is the behaviour in version 1.5.1. I recently upgraded to 1.5.2 (by switching my Linux distro to Debian Potato), and it breaks lots of my code, because the slice operator tries to create a new instance of MyL !

Unfortunately, MyL's constructor does not respond to UserList prototype expectance (no arguments), because MyL is a complex object that needs extra arguments at construction.

Additionally, it is not advisable, in that context, to create new MyL instances (or copies) like this, because of database connection / open files.

I triple checked the documentation of UserList/Sequences for 1.5.1, 1.5.2 and 1.6.0, and there is no such requirement that the slice operator should return a result of the same class as the operand, nor any specification on the constructor's arguments.

I understand anyway, that it has to return an object of the same sequence nature, be it tuple, list or string. But since I derive from a UserList, I expect it to look, smell and act like a python list... Hence the slice operator should return a plain list, that will in turn look, smell and act like a list, which it actually is !

The same reasonning holds for +/*/copy operators.

One could object, that if I do l=l[1:], or l=l+[x], then l would not be an MyL instance any more, and that is probably annoying.

That's perfectly true, but on one hand that's perhaps what I want, and on the other hand, it's my job to specify that + on a MyL instance should return a MyL instance, to specify how it should be done, and to implement it by overloading the adequate method. I don't want UserList implementation to decide for me !

If UserList is implemented the minimal way, then I'm free to overload it's methods to change its behaviour. That's what a class is for !
On the contrary, if it's implemented the current way, I have no choice. One solution is to bring back the old UserList implementation and put it in front of the python provided one in PYTHONPATH. Another is to overload methods to restore its generic behaviour.

Both solutions virtually make a library module useless, which I don't like. Why not making the default implementation the generic way, and provide another UserList2 implementation with different specification and requirements on its derived classes ?

Anyway, one of the implementation or the documentation/specification should be changed, so that they are in accordance to each other...


Follow-Ups:

Date: 2000-Oct-06 10:27
By: gvanrossum

Comment:
Let's update the documentation to say that for derived classes __getslice__ and others return an instance of the derived class. Since this was changed in 1.5.2 already, it's really too late to revert to the 1.5.1 specs -- it would break code relying on the 1.5.1 behavior! Plus, I really like the 1.5.2 (and 2.0) behavior better.

The best solution for you would be to override __getslice__ in your class to return a real list (or a UserList, if you prefer).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115928&group_id=5470