[Tutor] 'slice', etc

[Mark Lawrence]

On 07/12/2013 01:26, spir wrote:
> 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
>

The good news is there is a memoryview in Python, see 
http://docs.python.org/3/library/functions.html#func-memoryview.  The 
bad news is it doesn't work on strings. See here for the slice object 
http://docs.python.org/3/library/functions.html#slice.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence