[Python-3000] Future of slices

[Nick Coghlan]

Short version: +1 for the first point (but for different reasons), -1 for the 
rest. Use cases for advanced slicing operations are not provided by the 
standard library, but by Numpy's sophisticated data manipulation capabilities.

Alexander Belopolsky wrote:
<get rid of ...>> 1. l[:] syntax for shallow copy.


I kind of agree with this one, mainly because I'd like standard library data 
types to return views for slicing operations. Making a copy based on a view is 
as easy as wrapping the view in a call to the appropriate constructor. 
Avoiding the memory impact of multiple slicing operations that copy data 
around is much harder.

Returning views rather than copies would also eliminate some of the use cases 
for islice().

> 2. Overloading of [] syntax. The primary meaning of c[i] is: get the  
> i-th item from the collection. This meaning is consistent between  
> lists/tuples and dicts.  The only difference is that  i may not be an  
> integer in the case of dict.

The c[x] syntax isn't really overloaded - it always means "ask the container c 
for the item corresponding to subscript x"

For a dict, x must be hashable, but otherwise both x and the item returned are 
unconstrained. Other mappings may remove the requirement for hashability.

Sequences use the rule that x must be either an integer (object with an 
__index__ method), or a slice object. The key characteristic that 
distinguishes a sequence from a general mapping is that c[0:0] == type(c)().

Multi-dimensional arrays then loosen the restrictions on x imposed by 
sequences slightly to also permit tuples. The key characteristic to 
distinguish Numpy-style arrays from other sequences is that c[0:0] == c[0:0,].

These behaviours aren't fundamental rules of programming that need to be 
embedded in the underlying language implementation. The kinds of subscript 
that makes sense may vary from container to container. Python's current 
approach avoids embedding particular interpretations in the language allowing 
each data structure designer to make their own decisions (hopefully guided by 
the conventions used for existing data structures).

>   Slicing is specific  to lists, tuples  
> and strings (I am ignoring non-built-in types for now).

Ignoring external types when discussing slicing is a mistake. Much of Python's 
slicing design was driven by the Numpy folks, rather than the needs of the 
standard library.

> 3.  Overloading of []= syntax. Similarly to #2, this is the case when  
> the same notation is used to do conceptually different operations.   
> In addition it provides alternative ways to do the same thing (e.g. l  
> += a vs. l[len(l):] = a).

The OOW in TOOWTDI stands for "One Obvious Way" not "Only One Way" :)

As Josiah said, for manipulating data structures, that obvious way is 
typically the appropriate methods of the collection being used.

> 4. Extended slicing.  I believe the most common use case l[::-1] was  
> eliminated with the introduction of "reversed".  The remaining  
> functionality in case of a tuple c can be expressed as tuple(c[i] for  
> i in range(start,stop, stride)).  The later is more verbose than c 
> [start:stop:stride], but also more flexible.

Extended slicing was added to provide syntactic support for various operations 
on Numpy's multi-dimensional arrays. As I understand it, the later addition of 
support to the types in the standard library was more due to consistency 
reasons than really compelling uses cases.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org