[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