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...
* 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 ;)
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.
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 about performance, add a chapter about profiling, and then
make the slow parts faster.
Speeding Python code is usually by using better algorithms, caching or
using C extension modules :-)
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.
* Show how to 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.
* 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.
Best Regards,
Nir Soffer
