[ python-Bugs-887042 ] 2.3.3 str & list still use __getslice__ / __setslice__

SourceForge.net noreply at sourceforge.net
Tue Feb 3 16:04:56 EST 2004


Bugs item #887042, was opened at 2004-01-29 15:47
Message generated for change (Comment added) made by oodoo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887042&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Florian Bösch (oodoo)
Assigned to: Nobody/Anonymous (nobody)
>Summary: 2.3.3 str & list still use __getslice__ / __setslice__

Initial Comment:
Python 2.3.3 (#1, Jan 13 2004, 17:45:56)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2

str and list still use __getslice__ / __setslice__ for
the binary form

foo = mystr[1:2]
mystr[1:2] = foo

instead of __getitem__ / __setitem__ with slice objects.



----------------------------------------------------------------------

>Comment By: Florian Bösch (oodoo)
Date: 2004-02-03 21:04

Message:
Logged In: YES 
user_id=723141

Jep, I noticed it while subclassing and overriding the
operators for slicing.
It's odd to deprecate a feature, and force the programmer to
use it anyway if he wants to sublcass existing types.

Is there an explicit typename for tuples? 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-02-03 02:03

Message:
Logged In: YES 
user_id=593130

This only strikes me as a bug if use of *item is specified 
somewhere so that people subclassing builtin seqs know 
which methods to override.  Is it?  Are tuples different or just 
not checked?  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887042&group_id=5470



More information about the Python-bugs-list mailing list