[ 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