[Tutor] sensing EOF in Python 3.1

Steven D'Aprano steve at pearwood.info
Wed Nov 23 23:44:23 CET 2011


Cranky Frankie wrote:
> From: Peter Otten <__peter__ at web.de> wrote:
> snip
> <<How did you write the data into the pickle file? The normal approach is to
> write all your data in one step, e. g. (all code snippets untested)>>
> 
> Thanks Peter, that was it. I was treating pickle like standard file
> i/o when it's not that at all.

I don't understand what you mean by this.

Pickle does standard file I/O in the same way that opening a JPEG in an 
image view does standard file I/O: both programs read data from a file 
the standard, ordinary way, but expect data of a certain format. If you 
provide it too little data, you will get an EOF error. If you provide 
too much data, or messed up data, then you will some other error. But 
the file I/O is exactly the same. It's just that pickle, or your image 
viewer, handle it for you.


> The reason why I'm "pickling" is I'm trying to include information on
> Python data structures in the presentaton I'm preparing.

Pickling won't tell you anything about Python data structures. Pickling 
takes Python data structures, bashes them with a hammer until they stop 
wiggling, then runs them through a serialiser turning them into a stream 
of text or binary codes.

Pickles tell you only about pickles. You won't learn anything about 
(say) dicts by looking at a pickled dict except the bare fact that dicts 
can be pickled.

py> import pickle
py> d = {"key": "value", "another key": 42}
py> pickle.dumps(d)
"(dp0\nS'another key'\np1\nI42\nsS'key'\np2\nS'value'\np3\ns."

I don't know what you expect to learn about dicts from that.


> Here are the two programs that now work correctly together:
> 
> import pickle
> pickle_file = open("d:/Work/pickle_file", "wb")
> 
> Qb_dict = { ... contents of dict skipped ... }
> pickle.dump(Qb_dict, pickle_file)
> pickle_file.close()

Take note that you are pickling a dict. This is important later on.


> #
> # pickle_in.py
> # program to read in a pickled file
> #
> # Frank L. Palmeri
> #
> 
> import pickle                            # import the pickle module

Really? Wow! I thought "import pickle" meant sort the database!!! *wink*

Sarcasm aside, what else could "import pickle" mean other than import 
the pickle module? The comment adds absolutely nothing to the code. At 
best it is superfluous. At worst it is harmful, because code and 
comments have a regrettable tendency to get out of sync.

Every comment should carry its weight. If the code is particularly 
convoluted, you might write comments explaining *how* you do something, 
but generally the code speaks for itself regarding the how, so comments 
should explain *why* you do something. If a comment doesn't tell you 
something that the code doesn't, that you need to know (or at least 
should know). Otherwise it should be throw out into the back alley for 
the stray cats to eat.

> pickle_file = open("d:/Work/pickle_file", "rb") # open the pickled file
> read_list = pickle.load(pickle_file)            # read the first pickled row

And this is what I'm talking about. It does NOT read the first pickled 
row. Pickles don't have rows. In this case, you are reading the first 
and only pickled object, which happens to be a dict.


> print(read_list)              # print the input row from the pickled file
> pickle_file.close()           # close the pickled file

Every comment in your second file is either unnecessary, or wrong. This 
is a good example of the need to "comment smart" rather than "comment 
hard".

# Bad:
i += 1  # Add one to i.

# Good:
i += 1  # Adjust i for one-based indexing.


-- 
Steven



More information about the Tutor mailing list