Creation of new DB is akward

[GoogleCodeExporter]

What steps will reproduce the problem?
1. wrong way of going about it (although more intuitive for me)
def create_db(server, name):
       try:
            return server[name]
       except KeyError:
            return server.create(name)
2. right way (works):
def create_db(server, name):
    if name in server:
        return server[name]
    else:
        return server.create(name)

print create_db(server, 'test') outputs: <Database 'test'> in both cases
print [x for x in server] outputs all dbs but 'test' if using fn 1

Ideally I would expect the Exception KeyError to be raised by accessing the
server dict if the db didn't exist in the first implementation.

What version of the product are you using? On what operating system?
couchdb 0.8.1, svn couchdb-python

Original issue reported on code.google.com by ulises.cervino on 21 Sep 2008 at 11:23

[GoogleCodeExporter]

So the issue is that server[name] raises a ResourceNotFound exception instead 
of KeyError?

I don't think that masking the original error raised by the CouchDB server 
would be a good idea, personally.

Original comment by cmlenz on 5 Nov 2008 at 4:57

[GoogleCodeExporter]

At the time I just found it counter intuitive that if the Server object was to 
act as
a Python dict it would raise a different exception than the one originally 
raised
when an item is not found in the dict's keys.

No big deal really, just a feeling.

Original comment by ulises.cervino on 5 Nov 2008 at 5:12

[GoogleCodeExporter]

In this case, it makes sense to make ResourceNotFound a subclass of KeyError. 
That
way both checks would work.

Original comment by crack...@gmail.com on 25 Nov 2008 at 8:56

[GoogleCodeExporter]

I'm using the latest couchdb-python from svn and when I try the following in an
interpreter, I don't get any error which is odd. 

>>> from couchdb import Server
>>> s = Server('http://localhost:5984/')
>>> 'foobar' in s
False
>>> s['foobar']
<Database 'foobar'>

Since this is a common case, perhaps a method similar in spirit to 
dict.setdefault
would be useful.

Original comment by kochhar...@gmail.com on 4 Dec 2008 at 11:04

[GoogleCodeExporter]

I would agree that making ResourceNotFound a subclass of KeyError would be a 
nice
idea. Also makes it much easier to check for (no need to import RNF from 
somewhere
deep in the bowels of couchdb).

Original comment by djc.ochtman on 19 Mar 2009 at 1:47

[GoogleCodeExporter]

I would also expect KeyError rather than ResourceNotFound.

Original comment by whit537@gmail.com on 17 Oct 2009 at 6:00

[GoogleCodeExporter]

I'm about to commit the simple change to make ResourceNotFound inherit KeyError 
after
reviewing client.py and noticing that pretty much it is always raised by a 
dict-like
operation.

However, I'd like to open it up to any counter-arguments for a day or so just 
in case.

Original comment by randall....@gmail.com on 17 Oct 2009 at 9:10

[GoogleCodeExporter]

Original comment by randall....@gmail.com on 17 Oct 2009 at 9:10

[GoogleCodeExporter]

@Comment #6 I completely agree with that implementation. Just raising a 
KeyError is
just too general. Specifically raising ResourceNotFound as a subclass of 
KeyError is
understandable and easy to code around without having to do a bunch of research.

Original comment by wenda...@essentialed.org on 18 Oct 2009 at 1:13

[GoogleCodeExporter]

KeyError is too general, it should raise a ResourceNotFound error. However, I 
don't 
think ResourceNotFound should subclass KeyError - "ResourceNoFound is a 
KeyError" just 
doesn't make sense.

Personally, I think people should accept that they're dealing with HTTP 
resources and 
catch couchdb.ResourceNotFound (is it really that difficult?). Server and 
Database 
instances are not dicts so don't expect dict-like errors.

Original comment by matt.goo...@gmail.com on 18 Oct 2009 at 10:04

[GoogleCodeExporter]

Well. I tend to agree with you on all those points, Matt. The problem is that 
there
are dict-like operations that are not throwing KeyErrors and that *is* very 
unintuitive.

The only compromise I could imagine would be to catch the ResourceNotFound 
error in
the __*item__ methods and re-raise KeyError. Or perhaps we could create another
exception which inherits from both ResourceNotFound and KeyError which is only 
raised
in the context of a dict-like call. By taking the multiple inheritance route we 
would
not be masking the original CouchDB error nor violating the dict-like 
properties of
our objects.

Original comment by randall....@gmail.com on 18 Oct 2009 at 8:21

[GoogleCodeExporter]

@matt.goodall: I respectfully disagree.

"Personally, I think people should accept that they're dealing with HTTP 
resources 
and catch couchdb.ResourceNotFound" Isn't the point of the Database/Server 
abstraction precisely to pretend that we're *not* dealing with HTTP resources? 
If we 
wanted to deal with HTTP resources we would use httplib2 directly rather than 
couchdb-python. As it is, why should our abstraction not extend to error 
handling? 
Why draw the line there?

"Server and Database instances are not dicts so don't expect dict-like errors." 

Sure, they're not *technically* dicts (in that they don't subclass dict), but 
they 
implement most of the dictionary interface, and are clearly intended to be used 
as 
dictionaries. Again, why would this not extend to error handling? Why draw the 
line 
there?

Original comment by whit537@gmail.com on 19 Oct 2009 at 1:37

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

@matt.goodall

It looks like dict, but it doesn't act like one. You're breaking duck typing.

Original comment by temotor on 1 Dec 2009 at 7:54

[GoogleCodeExporter]

cmlenz doesn't really like any of the options here. The Database is not a dict.

Original comment by djc.ochtman on 10 Dec 2009 at 11:32

• Changed state: WontFix