Tutorial creates confusion about slices

[Antoon Pardon]

The following is part of the explanation on slices in the
tutorial:

The best way to remember how slices work is to think of the indices as
pointing between characters, with the left edge of the first character
numbered 0. Then the right edge of the last character of a string of n
characters has index n, for example:

+---+---+---+---+---+
| H | e | l | p | A |
+---+---+---+---+---+
0 1 2 3 4 5
-5 -4 -3 -2 -1

This is all very well with a simple slice like:

"HelpA"[2:4] => "lp"


But it give the wrong idea when using the following extended slice:

"HelpA"[4:2:-1] => "Ap"

So this doesn't result in the reverse of the previous expression while
the explanation above suggest it does.


So I suggest to drop this.

 

[Rob Wolfe]

The following is part of the explanation on slices in the
tutorial:

The best way to remember how slices work is to think of the indices as
pointing between characters, with the left edge of the first character
numbered 0. Then the right edge of the last character of a string of n
characters has index n, for example:

+---+---+---+---+---+
| H | e | l | p | A |
+---+---+---+---+---+
0 1 2 3 4 5
-5 -4 -3 -2 -1

This is all very well with a simple slice like:

"HelpA"[2:4] => "lp"


But it give the wrong idea when using the following extended slice:

"HelpA"[4:2:-1] => "Ap"

So this doesn't result in the reverse of the previous expression while
the explanation above suggest it does.

Clearly I understand that differently:

"HelpA"[-2:-4:-1]

'pl'

 

[Antoon Pardon]

The following is part of the explanation on slices in the
tutorial:

The best way to remember how slices work is to think of the indices as
pointing between characters, with the left edge of the first character
numbered 0. Then the right edge of the last character of a string of n
characters has index n, for example:

+---+---+---+---+---+
| H | e | l | p | A |
+---+---+---+---+---+
0 1 2 3 4 5
-5 -4 -3 -2 -1

This is all very well with a simple slice like:

"HelpA"[2:4] => "lp"


But it give the wrong idea when using the following extended slice:

"HelpA"[4:2:-1] => "Ap"

So this doesn't result in the reverse of the previous expression while
the explanation above suggest it does.

Clearly I understand that differently:

"HelpA"[-2:-4:-1]

'pl'

This is not about what you understand. This is about what the tutorial
seems to suggest here and whether or not that corresponds with how
python actually works.

Read the explanation and look at the picture. The -2 is to the right
of "l" the -4 is to the left of "e". So the picture IMO suggests
that "HelpA"[-2:-4:-1] would result in "le"

 

[Michael Bentley]

The following is part of the explanation on slices in the
tutorial:

The best way to remember how slices work is to think of the indices as
pointing between characters, with the left edge of the first character
numbered 0. Then the right edge of the last character of a string of n
characters has index n, for example:

+---+---+---+---+---+
| H | e | l | p | A |
+---+---+---+---+---+
0 1 2 3 4 5
-5 -4 -3 -2 -1

This is all very well with a simple slice like:

"HelpA"[2:4] => "lp"


But it give the wrong idea when using the following extended slice:

"HelpA"[4:2:-1] => "Ap"

So this doesn't result in the reverse of the previous expression while
the explanation above suggest it does.


So I suggest to drop this.

But 'drop' means to let or make (something) fall vertically...

At that point in the tutorial, step values had not been discussed.
Just a bit lower down on the page you'll find a link to 'Sequence
Types' where you'll find an explanation of stepping you'll perhaps
find more satisfactory.

hth,
Michael

 

[Antoon Pardon]

The following is part of the explanation on slices in the
tutorial:

The best way to remember how slices work is to think of the indices as
pointing between characters, with the left edge of the first character
numbered 0. Then the right edge of the last character of a string of n
characters has index n, for example:

+---+---+---+---+---+
| H | e | l | p | A |
+---+---+---+---+---+
0 1 2 3 4 5
-5 -4 -3 -2 -1

This is all very well with a simple slice like:

"HelpA"[2:4] => "lp"


But it give the wrong idea when using the following extended slice:

"HelpA"[4:2:-1] => "Ap"

So this doesn't result in the reverse of the previous expression while
the explanation above suggest it does.


So I suggest to drop this.

But 'drop' means to let or make (something) fall vertically...

At that point in the tutorial, step values had not been discussed.
Just a bit lower down on the page you'll find a link to 'Sequence
Types' where you'll find an explanation of stepping you'll perhaps
find more satisfactory.

That is very well posible. The question: Even if we get a good
explanation later, do we want an explanation here that can cause
confusion. These things are not just read and then discarded.
Someone can already have read the whole tutorial and then come
back to this place. So at that point he knows about stepping
when he is reading this.


I suspect that if you give this explanation to someone and explain
that there is also a step parameter, chances are he will answer
correctly if you ask him, what he thinks the following will result
in:


"This is an example line"[12:19:2]



If you ask him what the following will result in:

"This is an example line"[19:12:-1]

Chances are he will give the wrong answer.

 

[Michael Bentley]

The following is part of the explanation on slices in the
tutorial:

The best way to remember how slices work is to think of the
indices as
pointing between characters, with the left edge of the first
character
numbered 0. Then the right edge of the last character of a string
of n
characters has index n, for example:

+---+---+---+---+---+
| H | e | l | p | A |
+---+---+---+---+---+
0 1 2 3 4 5
-5 -4 -3 -2 -1

This is all very well with a simple slice like:

"HelpA"[2:4] => "lp"


But it give the wrong idea when using the following extended slice:

"HelpA"[4:2:-1] => "Ap"

So this doesn't result in the reverse of the previous expression
while
the explanation above suggest it does.


So I suggest to drop this.

But 'drop' means to let or make (something) fall vertically...

At that point in the tutorial, step values had not been discussed.
Just a bit lower down on the page you'll find a link to 'Sequence
Types' where you'll find an explanation of stepping you'll perhaps
find more satisfactory.

That is very well posible. The question: Even if we get a good
explanation later, do we want an explanation here that can cause
confusion. These things are not just read and then discarded.
Someone can already have read the whole tutorial and then come
back to this place. So at that point he knows about stepping
when he is reading this.


I suspect that if you give this explanation to someone and explain
that there is also a step parameter, chances are he will answer
correctly if you ask him, what he thinks the following will result
in:


"This is an example line"[12:19:2]



If you ask him what the following will result in:

"This is an example line"[19:12:-1]

Chances are he will give the wrong answer.

To be honest, bro -- I'd expect him to have enough intelligence to
experiment for a second and figure it out. This isn't rocket science
-- you can plainly see what's happening -- so learn it and move on.
Or better yet, quietly submit a patch...

 

[Antoon Pardon]

I suspect that if you give this explanation to someone and explain
that there is also a step parameter, chances are he will answer
correctly if you ask him, what he thinks the following will result
in:


"This is an example line"[12:19:2]



If you ask him what the following will result in:

"This is an example line"[19:12:-1]

Chances are he will give the wrong answer.

To be honest, bro -- I'd expect him to have enough intelligence to
experiment for a second and figure it out. This isn't rocket science
-- you can plainly see what's happening -- so learn it and move on.

I don't think that the possibility to experiment and see for oneself
is a good reason to keep a possible confusing explanation in a tutorial.

Or better yet, quietly submit a patch...

Why should I? If the reactions would have been one of agreement that
this is confusing and that the explanation should be changed, I would
have considered submitting a patch.

But most people that reacted seem to defend the current text in some
way or another. So if most people seem to feel there is no need for
a change why should I then submit a patch?

 

[Michael Bentley]

I suspect that if you give this explanation to someone and explain
that there is also a step parameter, chances are he will answer
correctly if you ask him, what he thinks the following will result
in:


"This is an example line"[12:19:2]



If you ask him what the following will result in:

"This is an example line"[19:12:-1]

Chances are he will give the wrong answer.

To be honest, bro -- I'd expect him to have enough intelligence to
experiment for a second and figure it out. This isn't rocket science
-- you can plainly see what's happening -- so learn it and move
on.

I don't think that the possibility to experiment and see for oneself
is a good reason to keep a possible confusing explanation in a
tutorial.

It's only potentially confusing if you already know more than has
been presented and are in fact, *experimenting* with techniques that
have yet to be presented.

Why should I? If the reactions would have been one of agreement that
this is confusing and that the explanation should be changed, I would
have considered submitting a patch.

But most people that reacted seem to defend the current text in some
way or another. So if most people seem to feel there is no need for
a change why should I then submit a patch?

.... or even continue the thread?

 

[Antoon Pardon]

On Apr 24, 2007, at 1:39 AM, Antoon Pardon wrote:

I suspect that if you give this explanation to someone and explain
that there is also a step parameter, chances are he will answer
correctly if you ask him, what he thinks the following will result
in:


"This is an example line"[12:19:2]



If you ask him what the following will result in:

"This is an example line"[19:12:-1]

Chances are he will give the wrong answer.

To be honest, bro -- I'd expect him to have enough intelligence to
experiment for a second and figure it out. This isn't rocket science
-- you can plainly see what's happening -- so learn it and move
on.

I don't think that the possibility to experiment and see for oneself
is a good reason to keep a possible confusing explanation in a
tutorial.

It's only potentially confusing if you already know more than has
been presented and are in fact, *experimenting* with techniques that
have yet to be presented.

People don't read tutorials in a strictly linear fashion. They can
continue to later subjects and then come back here to see how things
tie together. So the fact that it is only confusing to those who
know more than is already presented doesn't seem a very good reason
to leave it in.

... or even continue the thread?

It is always interresting to see how far people are willing to go to
defend the status quo.

I bet that if the tutorial was written now, given the possible
confusion, nobody would defend including this section. But now
that it already is in the tutorial it suddenly is worth defending.

 

[Michael Bentley]

On Apr 24, 2007, at 1:39 AM, Antoon Pardon wrote:

I suspect that if you give this explanation to someone and explain
that there is also a step parameter, chances are he will answer
correctly if you ask him, what he thinks the following will result
in:


"This is an example line"[12:19:2]



If you ask him what the following will result in:

"This is an example line"[19:12:-1]

Chances are he will give the wrong answer.

To be honest, bro -- I'd expect him to have enough intelligence to
experiment for a second and figure it out. This isn't rocket
science
-- you can plainly see what's happening -- so learn it and move
on.

I don't think that the possibility to experiment and see for oneself
is a good reason to keep a possible confusing explanation in a
tutorial.

It's only potentially confusing if you already know more than has
been presented and are in fact, *experimenting* with techniques that
have yet to be presented.

People don't read tutorials in a strictly linear fashion. They can
continue to later subjects and then come back here to see how things
tie together. So the fact that it is only confusing to those who
know more than is already presented doesn't seem a very good reason
to leave it in.

Yet they understand that earlier in the document, there is likely to
be a less complete coverage of a given topic. There is in fact, a
link on that page that includes a more complete coverage of that
topic (which I mentioned to you in an earlier message IIRC).

It is always interresting to see how far people are willing to go to
defend the status quo.

I bet that if the tutorial was written now, given the possible
confusion, nobody would defend including this section. But now
that it already is in the tutorial it suddenly is worth defending.

Submit a patch if you want it changed. I'm sure your valuable
insights will greatly improve the quality of the python documentation.

 

[Antoon Pardon]

Yet they understand that earlier in the document, there is likely to
be a less complete coverage of a given topic. There is in fact, a
link on that page that includes a more complete coverage of that
topic (which I mentioned to you in an earlier message IIRC).

That there is more complete coverage elsewhere is no good reason
to come with an explanation that suggests things working in
a way that will be contradicted by that more complete coverage.

Even after people have read the more complete coverage it is
still very possible that they will come back to this part of
the text and get the wrong idea of how things work.

A more complete coverage elsewhere is not an adequate remedy
for a tekst suggesting things working differently than they
actually do. Sure in the long run people will figger out how
things actually work and that the explanation given in that
section is totally inadequate for negative steps. But I
prefer that people don't loose too much time figgering out
that a particular explanation only works for particular cases
and not in general.

Submit a patch if you want it changed. I'm sure your valuable
insights will greatly improve the quality of the python documentation.

Fat chance, if they reason like you.

 

[Michael Hoffman]

Fat chance, if they reason like you.

I don't think that Michael Bentley is the documents maintainer. Are you
trying to pick a fight with him or improve the docs?

Personally, I do not think of slices in the way this tutorial suggests,
but I think taking it out without replacement would not help. If you
want to add a more accurate replacement, I think that would be better
received than just saying that the section should be removed. Even more
so if you provide it in the form of a patch.

 

[Antoon Pardon]

I don't think that Michael Bentley is the documents maintainer. Are you
trying to pick a fight with him or improve the docs?

I try not to pick fights. But I don't try very hard to avoid them
either.

Personally, I do not think of slices in the way this tutorial suggests,
but I think taking it out without replacement would not help. If you
want to add a more accurate replacement, I think that would be better
received than just saying that the section should be removed. Even more
so if you provide it in the form of a patch.

Well people could suggest that instead of just removing the section
there should be a replacement and then we could discuss how such
a replacement should look like. I just started with what I see as
a problem and one possible fix. Now I guess that if people would
agree that there is problem but don't agree with my fix they would
comment on my fix. Instead most reactions seem to suggest there is
not really a problem. Now I am not going to waste my time writing
a patch for something that doesn't seem to be considered a problem.

 

[Michael Hoffman]

[Michael Hoffman]
[Antoon Pardon]

Well people could suggest that instead of just removing the section
there should be a replacement and then we could discuss how such
a replacement should look like.

Isn't that what I have done? And William Hamilton suggested an
alternative way of looking at it which you could have just incorporated
into your patch.

I just started with what I see as
a problem and one possible fix. Now I guess that if people would
agree that there is problem but don't agree with my fix they would
comment on my fix. Instead most reactions seem to suggest there is
not really a problem. Now I am not going to waste my time writing
a patch for something that doesn't seem to be considered a problem.

Really only one person has argued that the docs do not need to be
changed. The other two people seemed to think you were asking for help
rather than discussing how to revise the docs. Understandable, since
that's why most people come to this group in my estimation.

Your time is your own and it is good to spend your efforts on what you
think will be most fruitful. But if you are going to let the opposition
of one person stop you from doing anything, you will not accomplish very
much.

 

[sjdevnull]

That there is more complete coverage elsewhere is no good reason
to come with an explanation that suggests things working in
a way that will be contradicted by that more complete coverage.

I happen to agree with you, but that's not a completely non-
controversial position. Many tutorials/manuals will prevent a
simplified (and incorrect for the general case) description of how
something works early on, and then clarify it later for the general
case. Personally I'd usually rather have the complete description
earlier rather than an incorrect simplification, or at least have a
footnote to the effect of "this is a simple introduction, the full
behavior will be described later".

But there's a good argument to be made for omitting confounding
details early on in a tutorial if there's a pedogogical reason for
doing so--indeed, there's such a widespread belief that early
oversimplification is actually helpful that I'd guess the majority of
language tutorials engage in it to some degree.

See, for instance, the C Tutorial at http://einstein.drexel.edu/courses/CompPhys/General/C_basics/
; it contains all kinds of statements like "The while loop continues
to loop until the conditional expression becomes false." (no mention
of "break", which is mentioned later in the section only as a way to
break out of an infinite loop). It also consistently uses "void
main()" to declare main, which is simply not correct C (though it's
accepted by many compilers)--but given that _many_ tutorials, and
_many_ published books make similar decisions, it's not quite as
simple as saying "that's just wrong. Do it right!". Rather, it seems
that a certain segment of teachers have decided that
oversimplification in early instruction, even when it's erroneous, can
be a better way to get the point across than trying to convey all the
details at once.

What's my point? This is really in a large part a discussion about
the philosophy of such tutorials--is it a bad idea to present
simplifications that are incorrect in general? Or does it actually
help people get up to speed so much faster that it's worth it even if
a bit of time has to be taken later to re-teach the full details? I
think that philisophical debate needs to be had before attacking
individual cases in the docs that use such simplifications.

 

[Antoon Pardon]

Really only one person has argued that the docs do not need to be
changed. The other two people seemed to think you were asking for help
rather than discussing how to revise the docs. Understandable, since
that's why most people come to this group in my estimation.

Your time is your own and it is good to spend your efforts on what you
think will be most fruitful. But if you are going to let the opposition
of one person stop you from doing anything, you will not accomplish very
much.

(e-mail address removed) has brought a point that is worth considering.
So I retreat now a bit to see if I can come with a proposal that
bears in mind his point.

 

[Antoon Pardon]

I happen to agree with you, but that's not a completely non-
controversial position. Many tutorials/manuals will prevent a
simplified (and incorrect for the general case) description of how
something works early on, and then clarify it later for the general
case. Personally I'd usually rather have the complete description
earlier rather than an incorrect simplification, or at least have a
footnote to the effect of "this is a simple introduction, the full
behavior will be described later".

But there's a good argument to be made for omitting confounding
details early on in a tutorial if there's a pedogogical reason for
doing so--indeed, there's such a widespread belief that early
oversimplification is actually helpful that I'd guess the majority of
language tutorials engage in it to some degree.

Thank you for bringing this up so explicitly. I must confess this
point hadn't entered my mind but it is worth thinking about. I'll
see if I can come up with a new proposal bearing this in mind.

Thank you.

 

[Ant]

Hi Antoon,

The best way to remember how slices work is to think of the indices as ....
+---+---+---+---+---+
| H | e | l | p | A |
+---+---+---+---+---+
0 1 2 3 4 5
-5 -4 -3 -2 -1

This is all very well with a simple slice like:

"HelpA"[2:4] => "lp"

But that is the whole point of a language tutorial, to introduce the
language and provide a way to get started. Note that the tutorial
doesn't even go into any details on extended slicing - as far as the
beginner is concerned at this point, there *is* no extended slice
notation. Even if the tutorial *did* go into more detail about
slicing, mentioning negative steps would be folly - the tutorial
should be an easy way into the language, and in such a context the
above tool for remembering how they work is just fine.

The exact (mathematical) definition for string slices is given in the
Library reference (http://docs.python.org/lib/typesseq.html), which is
where it should be. If you are at the point where understanding what
the deal is with extended slice notation for strings, then you are
ready to look at the real manual. If the tutorial was fully
comprehensive it would be massive and daunting. You'd probably have to
split it up as well, into, say, a Language reference and a Library
reference.

 

[Tim Golden]

(e-mail address removed) has brought a point that is worth considering.
So I retreat now a bit to see if I can come with a proposal that
bears in mind his point.

Now that this thread has slowed a little I would also
point out -- while agreeing with sjdevnull's thoughtful
post -- that reaction to an idea on a mailing list is
possibly not the best means of gauging its validity.
That's not to say you shouldn't listen to other posters;
rather that, if you still feel after due consideration
of other people's points of view that what you're
proposing is right, then go ahead and create a patch.

The people who are going to accept or reject your
doc patch are (probably) not the people who are
putting forward their ideas here on this list.
Ultimately, patches aren't voted in by the denizens
of python-list / c.l.py.

Also, there may be 1000 people nodding thoughtfully
(and silently) in agreement with your point of view, but
who are unlikely to post a "me, too" comment. It seems
likely that any posters are more likely to be those in
disagreement with a point of view.

Frankly, if you think after consideration that a change
to the docs is advisable, post up a patch to the relevant
place. If there are people on this list who disagree,
they're at liberty to comment on the patch. But at that
point, you've made the effort and said your piece. It's
up to the naysayers to make the effort to comment on
the patch. And, ultimately, up to the Python development
community to accept or reject it as they see fit. (And
as they have the time and inclination

TJG

 

[Ant]

The following is part of the explanation on slices in the
tutorial:

The best way to remember how slices work is to think of the indices as ....
+---+---+---+---+---+
| H | e | l | p | A |
+---+---+---+---+---+
0 1 2 3 4 5
-5 -4 -3 -2 -1

For a tutorial this is sound advice. A tutorial is designed to give
readers an easy intro to a topic, which is what this achieves. At this
stage the target audience has no idea that extended slices even exist,
let alone that you can use negative indices with them.

This is all very well with a simple slice like:

"HelpA"[2:4] => "lp"

But it give the wrong idea when using the following extended slice:

"HelpA"[4:2:-1] => "Ap"

But that is fine. Extended slice notation (let alone using negative
indices) is beyond the scope of the tutorial. Once you start to
experiment with extended slices, it is time to look beyond the
simplified tutorial information, and to the official documentation in
the Library and Language references. The library docs (http://
docs.python.org/lib/typesseq.html) say this:

(5) The slice of s from i to j with step k is defined as the sequence
of items with index x = i + n*k such that 0 <= n < (j-i/k)

Which is exactly how it works, and describes exactly why your extended
slice example works as it does.