Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

don't accept Exception for one(default) #38

Open
chadwhitacre opened this issue Mar 1, 2014 · 7 comments
Open

don't accept Exception for one(default) #38

chadwhitacre opened this issue Mar 1, 2014 · 7 comments

Comments

@chadwhitacre
Copy link
Collaborator

From @zwn at 935feba#commitcomment-5532271 :

I think the default should never be raised. Instead another param called maybe raises should be added to make it clear at the call site that the function raises.

@chadwhitacre
Copy link
Collaborator Author

What's the behavior if both raises and default are given?

@zwn
Copy link
Contributor

zwn commented Mar 1, 2014

Complain?

@zwn
Copy link
Contributor

zwn commented Mar 1, 2014

Or call it default_or_raise? It just does to not feel right raising default given the dict api and the like.

@chadwhitacre
Copy link
Collaborator Author

Yeah, maybe.

I thought it was okay to use default like this because it's such a common case to want to raise something in the zero case, and default is the Python name used in the zero case. What you see at the call site (e.g.) is default=NonexistingElsewhere (in the particular case linked the return value of one is unassigned, but that's unusual). You have to know or infer that NonexistingElsewhere is an exception. Is it not obvious that NonexistingElsewhere is an exception?

@zwn
Copy link
Contributor

zwn commented Mar 1, 2014

Do we have a precedence somewhere in python world when it would be common to raise default? I was expecting one to behave like above linked dict.get. It really caught me by surprise. Actually, what raises in the zero case like you say? Maybe I am missing something.

@chadwhitacre
Copy link
Collaborator Author

Do we have a precedence somewhere in python world when it would be common to raise default?

No, not that I'm aware of.

I was expecting one to behave like above linked dict.get.

It does behave like dict.get, unless the value is an exception.

Actually, what raises in the zero case like you say?

Though raising in the zero case is a common use case, I don't know of other APIs that provide this functionality in this way, via default.

foo = db.one("select blah")
if foo is None:
    raise DoesntExist

That's the common case I'm referring to. Since default is the thing used to otherwise deal with the zero case in Python, I abbreviated this case to:

foo = db.one("select blah", default=DoesntExist)

Since this overloads default relative to dict.get, I could see changing the postgres.py API to (as you suggest) something like:

foo = db.one("select blah", or_raise=DoesntExist)

If we do that, I like the idea of complaining if both default and or_raise are provided.

I'm seeing this as a backwards incompatible change, so it would go into 3.0.

@chadwhitacre
Copy link
Collaborator Author

What I don't like about or_raise is that it's not clear when that applies. What if there is more than one result? Do we raise the value of or_raise in that case? No, we don't. We only raise if there are zero results.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants