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. > * 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 difference between 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 agree with ;) plus, since some of the programs i demonstrate (e.g. playing checkers) are computationaly heavy, i have to sacrifice cleanliness in favor of speed. 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. > * Avoid timing Python startup time which is not the issue here you're right. i timed the code using tools i knew, and since the program startup time is negligible once you get to very large objects, i didn't bother finding out how to time things inside python. besides, the 'time' urility gives me more data then the 'time' function in python - because it also shows me user time and system time, and i wanted to make sure i'm not becoming slow due to swapping. > * More useful, a student can run the program once instead of 15 times ok. > * Show usage of module and function docstings i could do that with the original code, too. > * Show how to format output which means that i'm losing focus... > * 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. > * Show how different collections conform to the same protocol, e.g. > append, del ok - thought what you're concentrating on here is polymorphism. > The next 3 programs can be another function in the same program, > reusing the formating code. > > I attach the code here so people can discuss these changes and improve. please keep in mind, when you offer changes, the focus of the book, and the intended audiance. this book comes into play once the pupils already learned some python and some programming (but are very far from being python experts). it should focus on the new issues, which are data structures - not how to format strings and how to write comments. thus, please try to make sure your enhancements don't make us lose focus. i think that i will add a seperte program that shows how to time code (using your timing functions) - it is generaly a very bad practice to introduce too many new things together in a single program. instead, it should be broken down into smaller things. so i might add a new chapter (between chapters 2 and 3) that discusses issues such as timing code, "objects are references" (or mutable Vs. immutable objects), and other general python issues that i'll find to be repetitive in this mini-book. -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy
