Ned Batchelder wrote:
[...]
> The point of the example was to demonstrate what happens
> when slicing beyond the bounds of the list. It's beyond
> the scope of the thread to debate whether you might want to
> perform an action in that case.
But, nevertheless, the else-clause is there! And that's the
point i've been trying to make. The inclusion of this else-
clause only serves to distract from the intent of the lesson
and also the main topic of the thread. Hence my objection.
> I think we've demonstrated the slicing semantics well.
Indeed. And i never questioned this aspect. I merely wanted
to inform the lurkers that the else-clause was handling a
non-action, and therefore, could be omitted.
I believe strongly that bad examples are worse than no
examples at all. Consider the following:
Take for example the Tkinter method `root.quit()`, a method
that was presented in a famous web tutorial many years ago,
and has since (even to this _day_!) caused misconceptions in
the mind's of noobs as to its _true_ function. Sure, part of
that misconception can be blamed on a poor name choice, as
root.suspend_event_processing() would have been self-
explanatory. But this method is for advanced usage, and
thus, should not be a part of _any_ introductory or even
intermediate lesson. Of course, once the tut owner posted
this bad code, other tut owners just blindly copy/pasted,
and the damage has spread all over the web.
Or the example code presented as an introductory to defining
functions in the official Python documentation, one which
distracts from the main topic with an algorithm which builds
a Fibonacci sequence.
Both of these examples underscore the importance of clear
presentation, and what can go wrong if one fails to heed
this protocol of good teaching.
--
https://mail.python.org/mailman/listinfo/python-list
