[Tutor] List exercise

[alan.gauld@bt.com]

> On Mon, 10 Feb 2003 alan.gauld@bt.com wrote:
> > The only problem with this approach is that learning by experience
> > can teach an awful lot of bad habits that are hard to break. Using
> > a tutorial that teaches good habits early saves a lot of time 

> When I remember correctly the threads "list exercise" wasn't 
> such a shiny example of good programming style, was it?

But that wasn't a tutorial teaching, it was a bunch of folks on this 
list presenting different solutions to a problem. Hopefully a 
pre written tutorial would resolve those issues before commitying 
to 'print'.

> Taking up bad habits while learning by experience is truely a 
> weightfull argument, but isn't it said that python protects the 
> learner from bad habits? 

If itb is its wrong. Python encourages good programming style but it 
allows bad habits too. Consider how many times the use of exec/eval 
comes up from beginners who think they've found a solution to a 
problem. Yet exec/eval are hardly ever the best way of dealing 
with the problem at hand.

> and *grow with* the language? A python learner doesn't start with bad
> habits (solong s/he doesn't come from a bad habit language ;-); s/he
> writes somewhat simpleminded code that's all.

If they are following a structured training path that should be the 
case, but if they are just learning the basics then going off to 
do their own thing the potential is there for lots of bad habits 
to form.

> I don't want to suggest never read a tutorial - but I can't 
> see a need to elaborate about tutorial examples when the real 
> world is that near.

I am ambivalent about exercises etc, if you have a real problem 
to solve do that instead! But if your imagination can't come up 
with a pertinent example then the tutors offer an alternative.

> wont often get a list of ints, strings, lists all mixed together in a
> reasonable programm-design, will you?

Actually yes you will. A real world order record is typically 
exactly that. Or a real world bank account, or...

Of course is we move to OOP we use classes but the data internal to 
the class will be a mixture of types. Classes are just specialised 
containers after all.

 
> Anybody who comes to the tutor-list claiming that s/he got a 
> internal data structur like:
> ['spam!', 1, ['Brie', 'Roquefort', 'Pol le Veq'], [1, 2, 3]]

We might question whether it needs to be that way. One of the best 
programming habits is to structure the data before structuring the 
code. In fact the code should reflect the data structure... But 
there is nothing intrinsically wriong with it as it stands if 
that is the real nature of the data

A name = string
An account number = integer
A list of order items = 3 strings
A corresponding list of prices = 3 numbers

The last two should maybe be a single dictionary, but maybe the 
3 numbers represent something else - a list of employees involved 
in the transaction say...

> It's very interesting - for me as a student of educational 
> sience - how tutorials claim to explain something but tries to accomplish 
> this effort on objects, which are harder than necessary (to say the
least).

Not sure what you mean here? Do you mean objects are harder than 
necessary(if so in what way?) or do you mean the tutors are harder 
than necessary? Or both?

> Reading (well-written) existing code is a way out - as Erik 
> Price recently suggests.

Thats true. However well written code at the level of the pythion library 
say, will be extremely difficult for a beginner to comprehend. Thats where 
Useless Python plays an invaluable (and unique) role within the Python 
community.

Alan G


> 
> Michael
> 
>