Tutorial creates confusion about slices

[Antoon Pardon]

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.

OK. But eventually they will come into contact with negative indexes.
If they still rely on the above representation for understanding slices
that may cause confusions. It is possible that the time lost in clearing
up these later confusions will be bigger than the time gained by using
this simplification in the tutorial.

So I'm not so sure it is sound advice in this case.

If the consensus is that something like this should remain, I would
suggest replacing:

"The best way to remember how slices work is"

with:

"A way to remember how slices work, it is not entirly correct
but may be usefull, is"

Or something similar.


Wording to that effect makes it more clear that it is a crutch
that can be usefull now but that it should be discarded later.

 

[Steve Holden]

OK. But eventually they will come into contact with negative indexes.
If they still rely on the above representation for understanding slices
that may cause confusions. It is possible that the time lost in clearing
up these later confusions will be bigger than the time gained by using
this simplification in the tutorial.

So I'm not so sure it is sound advice in this case.

If the consensus is that something like this should remain, I would
suggest replacing:

"The best way to remember how slices work is"

with:

"A way to remember how slices work, it is not entirly correct
but may be usefull, is"

Or something similar.


Wording to that effect makes it more clear that it is a crutch
that can be usefull now but that it should be discarded later.

Most people reading a tutorial are aware that they are being given the
knowledge they need to put the subject matter to immediate use, and that
there may well be refinements that are glossed over or covered in detail
later or elsewhere.

I don't believe this needs to be made explicit wherever it applies.

regards
Steve

 

[Duncan Booth]

Most people reading a tutorial are aware that they are being given the
knowledge they need to put the subject matter to immediate use, and that
there may well be refinements that are glossed over or covered in detail
later or elsewhere.

The authors of 'The Science of Discworld' coined a term for this 'lies to
children' where an explanation to a student is technically wrong but is
pitched at the appropriate level for the student.

See http://en.wikipedia.org/wiki/Lie-to-children

 

[Neil Cerutti]

That's how everything I've ever learned has been taught. Start
with a simple explanation that may not be completely accurate
but is functional, then fill in the details later when there is
a context to put them in. The tutorial could start out by
explaining everything at the implementation level; it doesn't
because it is a _tutorial_, intended to give new users the
context they need to understand the more complicated nuances of
the language.

If it covered every fiddly little detail, it wouldn't be a
tutorial. It would be a language reference document instead.

Presenting a simplified model is a good technique, but when a
simplified model is presented it should be clearly stated wether
or not that model will eventually prove inadequate.

Is the divider-between-elements model presented in the tutorial
really the "best way" to understand half-open range notation?

I vote we change the word "best" to "possible" in the excerpt.

 

[Ant]

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

The best way to remember how slices work is ....
+---+---+---+---+---+
| 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"

I think that the tutorial example is absolutely fine as it is. It
gives the new python programmer (the target demographic of the
tutorial) a visual tool to understand what simple slicing is. Extended
slicing (in particular ones using negative indices) are beyond the
scope of the tutorial, and thus are irrelevant as far as the example
goes.

Adding examples / memory aids to cover all the many varied and
possibly degenerate ways you can slice a string would merely confuse
the python newbie. By the time you actually *are* interested in the
more advanced slicing capabilities, it's time to read the Library
reference where the formula stating *exactly* how slicing works is
stated.

A tutorial has every reason to be simplistic, so as far as I'm
concerned, -1 for changing the docs.

Apologies if this turns out to be my third near identical post - I've
tried sending variations on this message twice already today from
Google Groups, and they seem to have got lost in the ether...

 

[Antoon Pardon]

Most people reading a tutorial are aware that they are being given the
knowledge they need to put the subject matter to immediate use, and that
there may well be refinements that are glossed over or covered in detail
later or elsewhere.

I agree with that.

However there is a difference between information that will help you
on the way now that will be refined later and information that will
help you on the way now and will be contradicted later.

I also understand that the line between the two is rather fuzzy.

In my opinion the text in the tutorial as it stands now, is more
of the latter than of the former type and that is why I would
prefer a change.

 

[Steve Holden]

I agree with that.

However there is a difference between information that will help you
on the way now that will be refined later and information that will
help you on the way now and will be contradicted later.

I also understand that the line between the two is rather fuzzy.

In my opinion the text in the tutorial as it stands now, is more
of the latter than of the former type and that is why I would
prefer a change.

I had already deduced that from your arguments so far in this thread. Do
you *have* to make every trivial conclusion explicit?

Warning: this is an explicit test to see whether you can sit on your
hands and refrain from replying. It's hard to find a thread where you
don't make the last comment on every branch you get involved in.

regards
Steve

 

[Neil Cerutti]

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

The best way to remember how slices work is ...
+---+---+---+---+---+
| 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"

I think that the tutorial example is absolutely fine as it is.

I object only to the word "best". I don't like the above model
because it divorces the indexes that appear in subscripts from
those that appear in slices. I 't find it complicated to think:
a[2:4] is the contiguous slice of elements starting at the gap
between element 1 and 2, and ending at the gap between element 3
and 4. I've always found thinking of [2:4] as a half-open range
much easier.

I suppose the above model could avoid this notational problem if
you say that a[k] means the one element slice a[k:k+1]
(technically true for strings, but false for lists), rather than
ever thinking of item indexes as pointing directly at an item.

So I vote that the word "best" be removed.

 

[Michael Hoffman]

>
I object only to the word "best". I don't like the above model
because it divorces the indexes that appear in subscripts from
those that appear in slices. I 't find it complicated to think:
a[2:4] is the contiguous slice of elements starting at the gap
between element 1 and 2, and ending at the gap between element 3
and 4. I've always found thinking of [2:4] as a half-open range
much easier.

I suppose the above model could avoid this notational problem if
you say that a[k] means the one element slice a[k:k+1]
(technically true for strings, but false for lists), rather than
ever thinking of item indexes as pointing directly at an item.

So I vote that the word "best" be removed.

I agree. It would be better to say that, "One way to help you understand
how slices work is to think of..."

 

[Steve Holden]

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

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

I object only to the word "best". I don't like the above model
because it divorces the indexes that appear in subscripts from
those that appear in slices. I 't find it complicated to think:
a[2:4] is the contiguous slice of elements starting at the gap
between element 1 and 2, and ending at the gap between element 3
and 4. I've always found thinking of [2:4] as a half-open range
much easier.

I suppose the above model could avoid this notational problem if
you say that a[k] means the one element slice a[k:k+1]
(technically true for strings, but false for lists), rather than
ever thinking of item indexes as pointing directly at an item.

So I vote that the word "best" be removed.

I agree. It would be better to say that, "One way to help you understand
how slices work is to think of..."

I have just checked in that change.

regards
Steve

 

[Antoon Pardon]

I had already deduced that from your arguments so far in this thread. Do
you *have* to make every trivial conclusion explicit?

Well my problem was I had the feeling your remark totally ignored that.

I honestly don't understand what you thought your remark would
contribute if you had deduced the above.

It is very possible that this is a failing of mine in recognizing
when people have understood the point I am trying to make.

Warning: this is an explicit test to see whether you can sit on your
hands and refrain from replying. It's hard to find a thread where you
don't make the last comment on every branch you get involved in.

Well I guess I failed.

 

[Steve Holden]

Well I guess I failed.

Yes, that just about says it all.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
------------------ Asciimercial ---------------------
Get Python in your .sig and on the web. Blog and lens
holdenweb.blogspot.com squidoo.com/pythonology
tag items: del.icio.us/steve.holden/python
All these services currently offer free registration!
-------------- Thank You for Reading ----------------