shelve error

[7stud]

test1.py:
--------------------
import shelve

s = shelve.open("/Users/me/2testing/dir1/aaa.txt")
s['x'] = "red"
s.close()
--------output:------

$ python test1.py
Traceback (most recent call last):
File "test1.py", line 3, in ?
s = shelve.open("/Users/me/2testing/dir1/aaa.txt")
File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/shelve.py", line 231, in open
return DbfilenameShelf(filename, flag, protocol, writeback,
binary)
File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/shelve.py", line 212, in __init__
Shelf.__init__(self, anydbm.open(filename, flag), protocol,
writeback, binary)
File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/anydbm.py", line 80, in open
raise error, "db type could not be determined"
anydbm.error: db type could not be determined
Exception exceptions.AttributeError: "DbfilenameShelf instance has no
attribute 'writeback'" in ignored

 

[mik3l3374]

test1.py:
--------------------
import shelve

s = shelve.open("/Users/me/2testing/dir1/aaa.txt")
s['x'] = "red"
s.close()
--------output:------

$ python test1.py
Traceback (most recent call last):
File "test1.py", line 3, in ?
s = shelve.open("/Users/me/2testing/dir1/aaa.txt")
File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/shelve.py", line 231, in open
return DbfilenameShelf(filename, flag, protocol, writeback,
binary)
File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/shelve.py", line 212, in __init__
Shelf.__init__(self, anydbm.open(filename, flag), protocol,
writeback, binary)
File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/anydbm.py", line 80, in open
raise error, "db type could not be determined"
anydbm.error: db type could not be determined
Exception exceptions.AttributeError: "DbfilenameShelf instance has no
attribute 'writeback'" in ignored

how did you generate aaa.txt?

 

[7stud]

test1.py:
--------------------
import shelve

s = shelve.open("/Users/me/2testing/dir1/aaa.txt")
s['x'] = "red"
s.close()
--------output:------

$ python test1.py
Traceback (most recent call last):
File "test1.py", line 3, in ?
s = shelve.open("/Users/me/2testing/dir1/aaa.txt")
File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/shelve.py", line 231, in open
return DbfilenameShelf(filename, flag, protocol, writeback,
binary)
File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/shelve.py", line 212, in __init__
Shelf.__init__(self, anydbm.open(filename, flag), protocol,
writeback, binary)
File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/anydbm.py", line 80, in open
raise error, "db type could not be determined"
anydbm.error: db type could not be determined
Exception exceptions.AttributeError: "DbfilenameShelf instance has no
attribute 'writeback'" in ignored

how did you generate aaa.txt?

In a text editor, which I then saved to that directory.

 

[7stud]

how did you generate aaa.txt?

Ok, I got it to work by supplying a filename that didn't previously
exist. Neither the book I am reading, "Beginning Python: From Novice
to Professional" nor the book I am using as a reference, "Python in
Nutshell", happens to mention that important fact.

 

[Steve Holden]

Ok, I got it to work by supplying a filename that didn't previously
exist. Neither the book I am reading, "Beginning Python: From Novice
to Professional" nor the book I am using as a reference, "Python in
Nutshell", happens to mention that important fact.

It seems to make sense that you have to open a file as writable in order
to be able to change its contents, though, doesn't it?

regards
Steve

 

[7stud]

It seems to make sense that you have to open a file as writable in order
to be able to change its contents, though, doesn't it?

My text file was writable.

 

[Alex Martelli]

Ok, I got it to work by supplying a filename that didn't previously
exist. Neither the book I am reading, "Beginning Python: From Novice
to Professional" nor the book I am using as a reference, "Python in
Nutshell", happens to mention that important fact.

I notice that the Nutshell (2nd ed) has a small errata that may be
what's confusing you. On p. 284, under "The shelve module", I say:

shelve supplies a function open that is polymorphic to anydbm.open .

On p. 286, you find the whole page explaining anydbm.open (which is why
I didn't want to duplicate all that info), including the detail that the
default value for argument flag is 'r' (meaning read-only operation, and
on a file that must already exist). However, shelve.open is not
_entirely_ polymorphic to anydbm.open, in this small but crucial detail:
the defaulf value for argument flag is 'c' (meaning, as p. 286 correctly
says, that it creates a new file if it doesn't exist, but also accepts
and opens an existing file, and operation is read-write).

Of course, if the existing file was not created by the shelve module,
there may well be errors -- shelve uses DBM-like archive files, as
clearly explained on p. 284, not arbitrary text files (nor for that
matter arbitrary binary files). As the documentation for anydbm.open
explicitly says, it's all about DBM files; adding "will not work right
if you try to open just any random textfile or other file you may happen
to have laying around on your favourite storage device" would be
insulting to the reader and a waste of space, so I don't consider it a
valid errata.

But if you open an errata for the missing explanation for the different
default value of the flag argument (use URL
<http://www.oreilly.com/catalog/pythonian2/errata/>), I'll be glad to
fix it for the next printing, changing the previously quoted sentence
to:

shelve supplies a function open that is polymorphic to anydbm.open
(except that the default value of argument flag is 'c' rather than 'n').


BTW, if you DO want to call shelve.open on a path f that may correspond
to an arbitrary existing file (and want to toss away the previous
contents of that file, if any) the correct way to call is then:

s = shelve.open(whatever_path, 'n')

since 'n' truncates an existing file, or creates a new one, as needed.

That is also shown in the code example for module shelve in the Nutshell
(the 'n' occurs just at the top of p. 285).


Alex

 

[David Pratt]

Hi. I am on a PPC and have been getting the same undefined symbols
traceback when linking applications after compiling. A few weeks back I
posted on a problem to (e-mail address removed) after attempting to
build mod_python, today its pylucene - same problem. I initially
shrugged off the problem with mod_python as likely an issue with the mac
port.

Crazy thing is that I built the same version of pylucene successfully
just before upgrading to universal build of 2.4.4 python for mac without
problems. So I recompiled the same version of pylucene I had previously
built with a PPC only build of python to evaluate whether my thoughts
were right. I had a hunch universal python was causing my trouble with
mod_python and a newer build of pylucene and it appears I was right. I
am currently using Mac OSX 10.3.9 on a PPC with universal build of
2.4.4. I should say that other than linking problem I am experiencing,
the python functions as it should.

From mod_python build:

ld: Undefined symbols:
_fstatvfs referenced from Python expected to be defined in libSystem
_lchown referenced from Python expected to be defined in libSystem
_statvfs referenced from Python expected to be defined in libSystem
apxs:Error: Command failed with rc=65536
..
make[1]: *** [mod_python.so] Error 1
make: *** [do_dso] Error 2

From pylucene build:

ld: Undefined symbols:
_fstatvfs referenced from Python expected to be defined in libSystem
_lchown referenced from Python expected to be defined in libSystem
_statvfs referenced from Python expected to be defined in libSystem
gmake: *** [release/_PyLucene.so] Error 1

I have googled to see there have been others with this issue however
they have tended to communicate about the problem on software lists or
forums specific to the software they were attempting to build. I did not
see this resolved in any case that I have read.

I am hoping someone may be able to advise a possible solution. I am
planning on upgrading to OSX 10.4 within a week since mac is not making
the JDK 1.5.0 available for OSX 10.3 users - so pretty much being forced
into upgrading in any case.

If you had the same linking issue with the universal build of python it
would be good to hear from you - better yet would be some way of solving
this or at least understanding what may be going on. I have posted to
(e-mail address removed) in the interim but there is very little traffic
on this list. In the meantime I thought there may other OSX 10.3.9 users
out there who may have run into the same fate. Many thanks.

Regards,
David

 

[7stud]

Discussion subject changed to "Python universal build, OSX 10.3.9 and undefined symbols when

linking" by David Pratt

What gives? How come you can change the title of my thread?

But if you open an errata for the missing explanation for the different
default value of the flag argument (use URL
<http://www.oreilly.com/catalog/pythonian2/errata/>), I'll be glad to
fix it for the next printing...

In my opinion, the most valuable thing you could do for a next
printing would be to expand the index to 3 times its current length.
As it is now, I think the index is woefully inadequate, which I find
surprising for a reference book. I haven't been able to find 3/4 of
the things I have looked up in the index. For instance __get__(),
__set__(), and sorted() are nowhere to be found in the index.

Also, the book is brand new, yet the cover has completely separated
from the spine of the book, and now the cover is only attached to the
first and last pages with a bit of glue.

 

[Alex Martelli]

In my opinion, the most valuable thing you could do for a next
printing would be to expand the index to 3 times its current length.

Suggest that to O'Reilly: they're the one who prepare the index, not me;
I only get to point out errors I may notice on it during the roughly 4-5
days I get to review it in the late phases of production.

I don't believe any major change in the index can be contemplated
between one printing and another, but your complaint, if directed to the
appropriate ears, might possibly infuence some future edition.

Also, the book is brand new, yet the cover has completely separated
from the spine of the book, and now the cover is only attached to the
first and last pages with a bit of glue.

Similarly, I have no control on any aspect of the physical production of
the book: again, telling me about your complaints is absolutely useless,
if you want any chance to have an effect, tell O'Reilly.


Alex

 

[Peter Otten]

BTW, if you DO want to call shelve.open on a path f that may correspond
to an arbitrary existing file (and want to toss away the previous
contents of that file, if any) the correct way to call is then:

s = shelve.open(whatever_path, 'n')

since 'n' truncates an existing file, or creates a new one, as needed.

It's not entirely arbitrary since you get an exception if that file is not a
valid database:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.5/shelve.py", line 225, in open
return DbfilenameShelf(filename, flag, protocol, writeback)
File "/usr/local/lib/python2.5/shelve.py", line 209, in __init__
Shelf.__init__(self, anydbm.open(filename, flag), protocol, writeback)
File "/usr/local/lib/python2.5/anydbm.py", line 80, in open
raise error, "db type could not be determined"
anydbm.error: db type could not be determined

Peter

 

[Alex Martelli]

It's not entirely arbitrary since you get an exception if that file is not a
valid database:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.5/shelve.py", line 225, in open
return DbfilenameShelf(filename, flag, protocol, writeback)
File "/usr/local/lib/python2.5/shelve.py", line 209, in __init__
Shelf.__init__(self, anydbm.open(filename, flag), protocol, writeback)
File "/usr/local/lib/python2.5/anydbm.py", line 80, in open
raise error, "db type could not be determined"
anydbm.error: db type could not be determined

You're right -- anydbm.open, even when asked to "truncate the file",
still does mandate that the file, if it exists, be in some proper DBM
format (to determine which DBM module it will use to open it). This is
not intuitive, and needs to be mentioned in the Nutshell.


Alex

 

[Steve Holden]

What gives? How come you can change the title of my thread?




In my opinion, the most valuable thing you could do for a next
printing would be to expand the index to 3 times its current length.
As it is now, I think the index is woefully inadequate, which I find
surprising for a reference book. I haven't been able to find 3/4 of
the things I have looked up in the index. For instance __get__(),
__set__(), and sorted() are nowhere to be found in the index.

Also, the book is brand new, yet the cover has completely separated
from the spine of the book, and now the cover is only attached to the
first and last pages with a bit of glue.

That's not something an author can do much about ...

regards
Steve

 

[John J. Lee]

Also, the book is brand new, yet the cover has completely separated
from the spine of the book, and now the cover is only attached to the
first and last pages with a bit of glue.

I think they used to advertise that as a feature -- "stay-flat
binding" or something...


John