473,322 Members | 1,431 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

Tutorial creates confusion about slices

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.
--
Antoon Pardon
Apr 23 '07 #1
31 1685

Antoon Pardon wrote:
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'

--
Regards,
Rob

Apr 23 '07 #2
On 2007-04-23, Rob Wolfe <rw@smsnet.plwrote:
>
Antoon Pardon wrote:
>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"

--
Antoon Pardon
Apr 23 '07 #3

On Apr 23, 2007, at 7:38 AM, Antoon Pardon wrote:
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

---
"Those who don't understand UNIX are condemned to reinvent it,
poorly." --Henry Spencer

Apr 23 '07 #4
On 2007-04-23, Michael Bentley <mi*****@jedimindworks.comwrote:
>
On Apr 23, 2007, at 7:38 AM, Antoon Pardon wrote:
>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.
Apr 24 '07 #5

On Apr 24, 2007, at 1:39 AM, Antoon Pardon wrote:
On 2007-04-23, Michael Bentley <mi*****@jedimindworks.comwrote:
>>
On Apr 23, 2007, at 7:38 AM, Antoon Pardon wrote:
>>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...

Apr 24 '07 #6
On 2007-04-24, Michael Bentley <mi*****@jedimindworks.comwrote:
>
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.
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?

--
Antoon Pardon
Apr 24 '07 #7

On Apr 24, 2007, at 4:47 AM, Antoon Pardon wrote:
On 2007-04-24, Michael Bentley <mi*****@jedimindworks.comwrote:
>>
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.
>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?
.... or even continue the thread?
Apr 24 '07 #8
On 2007-04-24, Michael Bentley <mi*****@jedimindworks.comwrote:
>
On Apr 24, 2007, at 4:47 AM, Antoon Pardon wrote:
>On 2007-04-24, Michael Bentley <mi*****@jedimindworks.comwrote:
>>>
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 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?

... 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.

--
Antoon Pardon
Apr 24 '07 #9

On Apr 24, 2007, at 6:35 AM, Antoon Pardon wrote:
On 2007-04-24, Michael Bentley <mi*****@jedimindworks.comwrote:
>>
On Apr 24, 2007, at 4:47 AM, Antoon Pardon wrote:
>>On 2007-04-24, Michael Bentley <mi*****@jedimindworks.comwrote:

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).
>
>>>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?

... 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.
Submit a patch if you want it changed. I'm sure your valuable
insights will greatly improve the quality of the python documentation.

Apr 24 '07 #10
On 2007-04-24, Michael Bentley <mi*****@jedimindworks.comwrote:
>
On Apr 24, 2007, at 6:35 AM, Antoon Pardon wrote:
>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).
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.

--
Antoon Pardon
Apr 24 '07 #11
Antoon Pardon wrote:
>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.
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.
--
Michael Hoffman
Apr 24 '07 #12
On 2007-04-24, Michael Hoffman <ca*******@mh391.invalidwrote:
Antoon Pardon wrote:
>>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.

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.

--
Antoon Pardon
Apr 24 '07 #13
[Michael Hoffman]
>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]
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.
--
Michael Hoffman
Apr 24 '07 #14

Antoon Pardon wrote:
On 2007-04-24, Michael Bentley <mi*****@jedimindworks.comwrote:

On Apr 24, 2007, at 6:35 AM, Antoon Pardon wrote:
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).

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/C...eral/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.

Apr 24 '07 #15
On 2007-04-24, Michael Hoffman <ca*******@mh391.invalidwrote:
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.
sj*******@yahoo.com 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

Apr 25 '07 #16
On 2007-04-24, sj*******@yahoo.com <sj*******@yahoo.comwrote:
>
Antoon Pardon wrote:
>On 2007-04-24, Michael Bentley <mi*****@jedimindworks.comwrote:
>
On Apr 24, 2007, at 6:35 AM, Antoon Pardon wrote:

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).

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.
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.

--
Antoon Pardon
Apr 25 '07 #17
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.

Apr 25 '07 #18
Antoon Pardon wrote:
On 2007-04-24, Michael Hoffman <ca*******@mh391.invalidwrote:
>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.

sj*******@yahoo.com 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
Apr 25 '07 #19
Ant
On Apr 23, 1:38 pm, Antoon Pardon <apar...@forel.vub.ac.bewrote:
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.


Apr 25 '07 #20
On 2007-04-25, Ant <an****@gmail.comwrote:
On Apr 23, 1:38 pm, Antoon Pardon <apar...@forel.vub.ac.bewrote:
>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.
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.

--
Antoon Pardon
Apr 25 '07 #21
Antoon Pardon wrote:
On 2007-04-25, Ant <an****@gmail.comwrote:
>On Apr 23, 1:38 pm, Antoon Pardon <apar...@forel.vub.ac.bewrote:
>>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.

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
--
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
Recent Ramblings http://holdenweb.blogspot.com

Apr 25 '07 #22
Steve Holden <st***@holdenweb.comwrote:
>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.
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

Apr 25 '07 #23
On 2007-04-25, Hamilton, William <wh*****@entergy.comwrote:
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.

--
Neil Cerutti
Apr 25 '07 #24
Ant
On Apr 23, 1:38 pm, Antoon Pardon <apar...@forel.vub.ac.bewrote:
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...
Apr 25 '07 #25
On 2007-04-25, Steve Holden <st***@holdenweb.comwrote:
Antoon Pardon wrote:
>On 2007-04-25, Ant <an****@gmail.comwrote:
>>On Apr 23, 1:38 pm, Antoon Pardon <apar...@forel.vub.ac.bewrote:
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.

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 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.

--
Antoon Pardon
Apr 26 '07 #26
Antoon Pardon wrote:
On 2007-04-25, Steve Holden <st***@holdenweb.comwrote:
[...]
>>>
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.
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
--
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
Recent Ramblings http://holdenweb.blogspot.com

Apr 26 '07 #27
On 2007-04-25, Ant <an****@gmail.comwrote:
On Apr 23, 1:38 pm, Antoon Pardon <apar...@forel.vub.ac.bewrote:
>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.

--
Neil Cerutti
When "yearn" was sung, the performers ounded like they were in a state of
yearning. --Music Lit Essay
Apr 26 '07 #28
Neil Cerutti wrote:
>On Apr 23, 1:38 pm, Antoon Pardon <apar...@forel.vub.ac.bewrote:
>>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..."
--
Michael Hoffman
Apr 26 '07 #29
Michael Hoffman wrote:
Neil Cerutti wrote:
>>On Apr 23, 1:38 pm, Antoon Pardon <apar...@forel.vub.ac.bewrote:
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
--
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
Recent Ramblings http://holdenweb.blogspot.com

Apr 26 '07 #30
On 2007-04-26, Steve Holden <st***@holdenweb.comwrote:
Antoon Pardon wrote:
>On 2007-04-25, Steve Holden <st***@holdenweb.comwrote:
[...]
>>>>
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.
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.

--
Antoon Pardon
Apr 27 '07 #31
Antoon Pardon wrote:
On 2007-04-26, Steve Holden <st***@holdenweb.comwrote:
[...]
>
>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.
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 ----------------

Apr 28 '07 #32

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: CPK Smithies | last post by:
Just joined this group, fascinated by Python. Many thanks to those who have worked so hard on it! One big problem, though: I was completely thrown by this, which I quote from the Tutorial: >...
29
by: George Sakkis | last post by:
Why does slicing a tuple returns a new tuple instead of a view of the existing one, given that tuples are immutable ? I ended up writing a custom ImmutableSequence class that does this, but I...
11
by: Magnus Lycka | last post by:
While the official Python Tutorial has served its purpose well, keeping it up to date is hardly anyones top priority, and there are others who passionately create really good Python tutorials on...
1
by: xahlee | last post by:
Elisp Tutorial: Make Google Earth Xah Lee, 2006-12 This page shows a example of writing a emacs lisp function that creates a Google Earth file, and creates a link to the file, as well a link...
8
by: At_sea_with_C | last post by:
Hello, I'm considering reading some C tutorials. I found this one. http://www.crasseux.com/books/ctutorial/ (The GNU C Programming Tutorial) Can anyone tell me if it is good or not? Also do...
3
slightlybefuddled
by: slightlybefuddled | last post by:
(Exporting ImageReady slices as CSS rather than tables) apparently means it'll work just fine in Firefox, but do wacky stuff in IE? Can anyone help me figure out why on earth the slices are not...
5
by: NuberSteve | last post by:
I'm very new to using CSS and also the concept of slices for mouse-overs, and have made my first attempt at using ImageReady to generate slices of a world map. I basically wanted a map that would...
3
by: David | last post by:
That xpairs() generator is nice, but it's not the best possible code What do you mean by best possible? Most efficient? Most readable? And why don't you use islice? eg: def xpairs(seq):...
182
by: Bill Cunningham | last post by:
I understand this code. int a; int b; for (b=0;b<5;b=b+1) int a; This should take every element of the array a and set it to 1,2,3,4,5. Great. Now for the big question. How would you work...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.