On Tue, 25 Oct 2005, Nir Soffer wrote: > On 24 Oct, 2005, at 20:18, guy keren wrote: > > > > > On Sun, 23 Oct 2005, Nir Soffer wrote: > > > >> While reading > >> <http://users.actcom.co.il/~choo/python/data-structs-python-and-the- > >> wardrobe/data-structures-and-python.html>, I noticed that the example > >> code is not really in Python, I would call this code C in Python :-) > > > > no wonder, as i didn't learn python in order to learn python - i > > wanted to > > write something, and i went to look in the documentation > > (http://docs.python.org/) in order to find a way to do it. > > > >> I tried to make the first 3 programs comparing list, array and deque > >> more pythonic > >> <http://faassen.n--tree.net/blog/view/weblog/2005/08/06/0> and example > >> of best practice in general: > >> * Don't repeat the same code more then once > > > > i think you're confusing 2 things here. i was demonstrating 3 > > _seperate_ > > programs - so this is not code-repetition per-ce. > > Which are the same except one or two lines...
again, you're missing the point of how _new_ programmers grasp material. remember - i'm not talking to people with experience in programming - this is the first programming language. what to you might look like a "nice and clean and easy abstraction" - would look confusing to them. what i could do, perhaps, is write the 3 seperate programs, and _then_ show that they can be combined in this manner. you can't show people just the end result and hope they figure how you got there - you need to make the whole path explicit. otherwise, they won't learn how to make the whole path on similar occasions. > >> * Avoid non relevant command line parsing code > > > > i had that in order to allow running the program with different > > parameters, without altering the code. it is true, however, that in a > > script, "changing the code" is not something that should be feared, as > > with compiled languages. > > > > i do have, however, a problem with code that requires changing in > > order to > > change parameters - this is often the difference between scripts that > > get > > used, and scripts that get neglected. once you realise that there's a > > differencebetween the writer of the script and the user of the script > > - > > you tend to favor using command-line arguments. > > > > in this specific case, your approach might be better. > >> * Use Python idioms > > > > once i get used to them, and only those i agreewith ;) > > Experience tell that once you write code that other use and use code > that other write, you tend to agree with most idioms, because it makes > like easier for everyone. not my experience - but lets leave this argument - it's irrelevant for teaching purposes. > > plus, since some of the programs i demonstrate (e.g. playing checkers) > > are > > computationaly heavy, i have to sacrifice cleanliness in favor of > > speed. > > I think that the correct way it to write a very clear code thats easy > to understand - nobody cares abut performance in this course. If you > want to talk aboutperformance, add a chapter about profiling, and then > make the slow parts faster. look at the chapter about mini-max trees (after which readers will be able to write a checkers game) - performance is crucial to make a checkers game that is debugable and play-able. this time, it is my turn to say "if you teach people how to write slow programs, they'll get habbits of writing slow programs" ;) please note that the code i wrote was not un-clear. i will probably use xrange and the matching 'for' - if i find that it makes the concept of lists/arrays easier to understand. > Speeding Python code is usually by using better algorithms, caching or > using C extension modules :-) and choosing the appropriate data structures, which is what this mini-book is all about. > > > > what i could do is point these places out, and then show the > > alternatives. > > i'll see how much time i have to do that. > > Because you don't have time in this course to talk about this, you can > simply show only the shorter and nicer pythonic code, without talking > about the alternatives. no no no. you're confusing the course given in lessons, and this self-reading mini-book. the idea is to teach lessons in class according to the meetings plan found on my temporary site. then, in order to allow the faster/more-motivated pupils to learn more, they'll be given a mini-book, to learn in parallel with the python course (the only thing missing in the course plan, that's required by this mini-book, is an explanation about dictionaries - as far as i can tell). so with the mini-book, which i am NOT going to teach in class, there is no _teaching time_ shortage - pupils who want to can choose to read it for as many hours as they wish to. when i said shortage of time, i said shortage of my _material preparation time_ - since i have to spend time on preparing the frontal course as well (including various technical issues such as the environment in which the pupils will work, tools they will use, preparing slides, recruiting pupils, etc). > >> * Show howto format output > > > > which means that i'm losing focus... > > You can avoid the formatting but you will have hard to read output. > This is the cost of using one program instead of running 3 programs 5 > times each. but i do not care about this cost - because it costs nothing special. what i will do, i imagine, is teach them text formatting in the frontal class. then this code will look less alient, and they'll be able to focus on the important issue - which is the data structures. > >> * Use only nice readable names > > > > you're again losing the focus. in a very small program, a short > > variable > > name is easier to read. you made the program long - so ofcourse you > > need > > to "work harder" on variable names. > > True, but example code should be always nice, its easier to understand > and the students will remember those examples as the "correct" way of > doing things. there are many "correct" ways of doing things. you are focusing on elegancy of the code. i am trying to focus on didactic simplicity first - and this dictates breaking down ideas into several small steps, in order to make things easy to grasp. so, to sum it up, i think what i will do is: 1. add the pre-section about python issues such as timing code (perhaps add it right after i explain time and space complexity - which reminds me, i need a good way to measure the ammount of memory data structures take. anyone has an idea?). 2. teach more about text formatting in the frontal classes (i'll see where to add that to the study plan). 3. show this example code as 3 seperate programs, and then combine them all into one larger program in your style. -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy
