Posts

Showing posts with the label Python

A second complaint about Python Unit Test Automation...

and some recent, similar books I have encountered: This book includes a very large number of screen shots and copies of the output of running some command or other. Now certainly, a bit of this can be useful. But truly great programming books, such as Software Tools , Programming on Purpose , or Programming Pearls , include (almost?) nothing of this sort. It is as though the authors had plenty to convey without dumping the screen output of every command or program discussed into their works. Again, I don't claim that any inclusion of such output should be forbidden. But I suggest that, say, for a series of very similar tests, it is enough to put in, "Here is an example of the output of test A," and not also show the nearly identical output for tests B, C, D and E. And, once again, I have the sneaking suspicion the publisher who asks for the output of B, C, D and E is trying to pad out a volume they fear may otherwise be too slim to sell.

"The only way to have confidence in a Python program is to write tests"

I saw this asserted (hee-hee) in a Python book I am reading. The author apparently doesn't know that, while testing is great, in the old days, we used to actually logically analyze our programs and gain great confidence in them from that exercise.

And here is the outline for my new book...

Agent-based modeling in Python .

My PyGotham Presentation

Generic Programming and Agent-Based Modeling, slide show here .

I Take It All Back

My post on Python and data abstraction was mistaken: every example I had seen of using the '@property' feature showed how to control access to a variable with the same name as the property. But last week, and found an example showing that you don't need a variable with the property name at all, so it can, indeed, be used to screen moving a variable into a different class. I stand corrected!

Do Pythonistas Understand Data Abstraction?

I was just reading this page on why not to use getter and setter functions in Python, and realized the author doesn't seem to have any idea what data abstraction is: "In Java, you have to use getters and setters because using public fields gives you no opportunity to go back and change your mind later to using getters and setters." This was never the reason I used a getter or setter method in Java! You use getters and setters to achieve data abstraction : "The representation details are confined to only a small set of procedures that create and manipulate data, and all other access is indirectly via only these procedures." I had a class GridAgent where the agent held its position on a grid, among other things. But then I wanted to re-do this, so that the position was held in a cell, which held the agent. I had (sometimes) done things the "Pythonic" way, but just accessing the position variable, and of course I had to find every instance of th...

How to make your Python classes document their own inheritance tree

Image
First we connect our base Node class to a graph, which prevents searching further up the inheritance tree and trying to add 'Object' itself, which don't care to do:                 def __init__(self, name):         self.ntype = self.__class__.__name__         if not Node.node_added:             Node.class_graph.add_node(                 Node.__name__)         # now search the class graph         # to see if the current class         # is there:         if self.ntype not in Node.class_graph:             self.__class__.connect_to_class_tree() And he...

Implementing an efficient random iterator over a multi-level data structure

FRONT UPDATE: Ken B. has pointed out that I was thinking like a C programmer in writing this: I was thinking in terms of shuffling arrays of C-like integers versus arrays of larger C data structures. In that situation, my algorithm would be more efficient. But that is not how Python does things! These are Python lists, not C arrays, and the list is a list of pointers, whether the list is of integers or of agents. So the shuffle has the same cost either way! In other words, I did a bunch of fancy coding that would be nice in a different language, but that makes no difference in the one I am actually using. Still, the coding was interesting. FRONT UPDATE II: An important lesson I learn yet again -- I guess I am rustier than I thought! -- Don't "optimize" without profiling (timing portions of) your code! I timed my fancy-pants version of the random iteration, as well as of reverse iteration, against the "naive" versions that just used basic Python op...