<html>
At 05:55 AM 3/2/01 +0000, Donn Cave wrote:<br>
<br>
<blockquote type=cite cite>The problem for me is that when we write
ob[i:j], we clearly<br>
must have expected that ob is a sliceable sequence. If it is<br>
instead a mapping, then the expression has no sensible meaning,<br>
so it's an error and ought to raise an exception.</blockquote><br>
Making slice objects comparable/hashable is at cross purposes with
forbidding their use as dictionary keys. Guido endorsed the strict
forbiddance of slice objects as dict keys; that patch is more
straightforward than extending the slice objects' behavior.<br>
<br>
Proposed 2.1 patch:<br>
<br>
- no changes to slice object<br>
- Slice objects are rejected as dict keys, just as lists and dicts<br>
are rejected; this rejection is only on setitem; getitem<br>
will just throw suitable KeyError as it does now<br>
- fix exception values for built-in types like DictType for <br>
the operation dict[i:j,]; the exception value<br>
strips the tupleness and I dislike that inconsistency<br>
- change things so that obj[:] passes slice(None,None,None) <br>
instead of slice(0, sys.maxint, None)<br>
to mapping getitem (sequence getslice behavior still uses<br>
(0, sys.maxint) as defaults)<br>
<br>
The last item deserves a little explanation. From the language reference
5.3.3:<br>
<br>
"The semantics for a simple slicing are as follows. The primary must
evaluate to a sequence object. The lower and upper bound expressions, if
present, must evaluate to plain integers; defaults are zero and the
sys.maxint, respectively. If either bound is negative, the sequence's
length is added to it. The slicing now selects all items with index
<i>k</i> such that <i>i</i> <= <i>k</i> < <i>j</i> where <i>i</i>
and <i>j</i> are the specified lower and upper bounds. This may be an empty sequence. It is not an error if <i>i</i> or <i>j</i> lie outside the range of valid indexes (such items don't exist so they aren't selected)."<br>
<br>
[Thus for simple slicing, the default lower bound is 0 and the default higher bound is sys.maxint.]<br>
<br>
"The semantics for an extended slicing are as follows. The primary must evaluate to a mapping object, and it is indexed with a key that is constructed from the slice list, as follows. If the slice list contains at least one comma, the key is a tuple containing the conversion of the slice items; otherwise, the conversion of the lone slice item is the key. The conversion of a slice item that is an expression is that expression. The conversion of an ellipsis slice item is the built-in Ellipsis object. The conversion of a proper slice is a slice object (see section <font color="#0000FF"><u>3.2</u></font>) whose start, stop and step attributes are the values of the expressions given as lower bound, upper bound and stride, respectively, substituting None for missing expressions."<br>
<br>
Thus for extended slicing, default values for start, stop, and step are always None. If obj[i:j] finds that obj is not a sliceable sequence, the fallback to mapping getitem is by nature an extended slicing operation, and thus should obey extended slicing rules. Thus:<br>
<br>
>>> d = {}<br>
>>> d[:]<br>
Traceback (innermost last):<br>
File "<pyshell#1>", line 1, in ?<br>
d[:]<br>
KeyError: slice(0, 2147483647, None)<br>
<br>
is wrong. Instead it should be:<br>
<br>
>>> d = {}<br>
>>> d[:]<br>
Traceback (innermost last):<br>
File "<pyshell#1>", line 1, in ?<br>
d[:]<br>
KeyError: slice(None, None, None)<br>
<br>
Think this is a trivial issue? It's not. The whole reason for extended slicing was to let the Numeric Python guys have richly expressive slice objects: a None value always has a different and important meaning than some imposed default like sys.maxint. Treating [:] as some magic integer range is the wrong behavior, and requires implementations to write special-case code to handle slice(0, sys.maxint, None) as slice(None, None, None).<br>
<br>
So this suggested small change just enforces the rules in section 5.3.3.<br>
<br>
I will need a vote of confidence from the Numeric Python gang. My searches of NumPy source turn up no breakage as a result of the change. David A? Anyone?<br>
<br>
I'll be unavailable for all of next week. If I can find the time today, I'll put together the first draft of the patch, but then I'll need to hand it off to someone else. Volunteers? Donn?<br>
<br>
One last note:<br>
<br>
With the above patches to 2.1, extended slice handling is now consistent with the Language Reference. Any type wishing to implement extended slicing has complete freedom in how to interpret the extended slice object or tuple. Thus we're free to add extended slice support incrementally to built-in types and only in ways that make sense for the type.<br>
<br>
For 2.2 or later, I would like to add extended slice handling to several built-in types. I'll make a PEP. Here's a quick example to start the wheels turning:<br>
<br>
>>> s = "abcdef"<br>
>>> s[1:2,3:,::-1,3,765,...]<br>
"bdeffedbcadabcdef"<br>
<br>
I've wanted this kind of behavior for a while. :)<br>
<br>
<br>
<div>--</div>
<div>Robin Thomas</div>
<div>Engineering</div>
<div>StarMedia Network, Inc.</div>
<div>robin.thomas@starmedia.net</div>
</html>