[Tutor] 'slice', etc

[spir]

On 12/07/2013 02:07 AM, Alan Gauld wrote:
> On 06/12/13 15:39, spir wrote:
>
>> How does slicing in Python really work? Apparently, there are slice
>> objects (start, past-end, step), generated using either the 'slice'
>> builtin func or the extended slicing syntax [i:k:s]. Is this correct? [1]
>
> I believe the slice notation simply calls the underlying method as is the case
> for most operations in Python. But I'm no expert in the internals, others are
> far better qualified.
>
>> Does (only) the extended syntax (always) trigger slicing instead of
>> contructing a new subsequence? (new substring or sublist or whatever,
>> actually holding a section of the original sequence)
>
> I'm not sure what you think slicing does? But in general a slice produces a new
> sequence. Thus
>
>
> L = [1,2,3,4]
> L2 = L[1:2]
>
> L2 is a new list object.
>
> Indeed taking a full slice is one of the commonest ways of making a copy of a list:
>
> L3 = L[:]   # a new copy of L
>
>> Are slices and subsequences transparently usable one for the other?
>
> subsequences don't exist as objects in Python so you can't use them in the same
> way as a slice (which does explicitly exist). So I don't understand what you
> have in mind here.
>
>> rationale, design, etc... Maybe this means slices have always existed
>> and I just missed them totally?
>
> Slices have been in python since I started using it in V1.3. And I think from
> before then too. Certainly a very long time.
>
>> [2] The fact that slices exist at all shows how worth it is to avoid
>> needlessly creating subsequences,
>
> No it doesn't. Slices create new sequences.
> Creating a "sub sequence" is often the fastest most efficient way to do
> something. They are not something to get hung up about unless you have
> absolutely proved they are a source of a problem. Especially given the
> difficulty of writing reliable in-place code for many sequence operations.

Hum, we are not talking of the same topic, apparently. I mean this, from the 
library ref, builtin funcs:
http://docs.python.org/3.3/library/functions.html#slice:

  slice(start, stop[, step])

     Return a slice object representing the set of indices specified by 
range(start, stop, step).
     The start and step arguments default to None. Slice objects have read-only 
data attributes
     start, stop and step which merely return the argument values (or their 
default).
     They have no other explicit functionality; however they are used by Numerical
     Python and other third party extensions. Slice objects are also generated when
     extended indexing syntax is used. For example: a[start:stop:step] or 
a[start:stop, i].
     See itertools.islice() for an alternate version that returns an iterator.

Note the third and forelast sentences (extedned syntax apparently means 
indicating a step).

spir at ospir:~$ python3
Python 3.3.1 (default, Sep 25 2013, 19:29:01)
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> s = slice(1,-1,3)
>>> s.start, s.stop, s.step
(1, -1, 3)
>>> s
slice(1, -1, 3)

But i don't see what changes below, when using extended indexing syntax:

>>> str = "abcdefghi"
>>> sl = str[1:-1:2]
>>> sl
'bdfh'
>>> type(sl)
<class 'str'>

How to get a actual slice (a view, something like (str, 1, -1, 2) or better 
(start-pointer, -1, 2))? Why does slice() exist at all? How to use it? Is it 
used internally? Or does python cheat, pretending on the interface, at the 
language-side, that this is a str, just to maintain the language's semantics, 
while in some cases at least it is not?

Denis