get() should throw an error if more than one row exists
Sorry but that has always been a design decision I've liked, and I'm not going to change it.
 This is documented anyways, did you even bother to read it?

http://docs.peewee-orm.com/en/latest/peewee/api.html#Model.get
 just because the quirkiness of the API is documented doesn't mean there isn't room for improvement.  and i've seen no documentation/description on _why_ you like this this design decision over other alternatives.
 Who do you think you are?

> just because the quirkiness of the API is documented doesn't mean there isn't room for improvement.

You're judging the API as being _quirky_, but don't you think that's a bit rude or presumptuous, especially given that you've only been using the library for a very very short while?
 > Who do you think you are?

a developer who generally likes your API, wants to use it and contribute back improvements.  is that not welcome here?

looking back at your accepted external PRs i see many regarding minor bug fixes and documentation tweaks, but nothing beyond that, nor any other non-trivial collaborators.  at the risk of being blunt:  is this project just your baby/territory and all worthwhile ideas flow only from your brain, and all questions regarding even the most trivial design decisions personally offensive to you?
 I think you've got it backwards. You're new to the project, yet have submitted 5 issues and 4 pull-requests. Three of these issues were not actual issues - in two cases you had not read the docs, and in another (failing tests) you didn't see that it had been patched almost 2 weeks ago with a very clear commit message.  The other two (which includes this one), you state that you disagree with the semantics of methods **which are clearly documented**. You call the APIs quirky, or create issues with titles implying that the implementations are incorrect -- that rubs me the wrong way.

Regarding the pull-requests, you submitted a patch I found to be functionally useless, inelegantly implemented, potentially inefficient, and error-prone (are you sure you got _all_ the SQL reserved words? what about differences in database engines? what about folks who want to add a backend for a new database that has additional reserved words?). Oh, and best of all, you got your 3 buddies at work to come by and put emojis on it...or maybe it's just a coincidence you're all from houston, tx (@smtheard, @neopunisher, @ajbisberg).

You even have the gall to tell me you think it's a bad idea for me to improve my library by rewriting parts of it for a new major version.

Dude, you've been here for like a week, you're embarrassing yourself.
 The build is passing locally and on Travis ci.
 This is why [Ecto](https://github.com/elixir-ecto/ecto) chose to rename `get` to `first`. 

``` python
import peewee as pw

class Person(pw.Model):
  name = pw.CharField()
  class Meta:
    database = db

alice = Person.create(name='Alice')
alice2 = Person.create(name='Alice')

print Person.get(Person.name=='Alice')
```

this generates the following SQL:

``` sql
SELECT "t1"."id", "t1"."name" FROM "person" AS t1
WHERE ("t1"."name" = ?) LIMIT 1 OFFSET 0
```

if the conditional criteria don't uniquely identify a record, you're effectively randomly choosing which row is returned to the user when the user has clearly indicated a belief that the record is unique.  as is this method is simply a shorthand for `.first()`.

it's fairly common for this feature to be implemented with a `LIMIT 2`, where the lib will throw some sort of `NotUniqueException` if more than one row are returned.

i'll be happy to implement if you don't disagree with it on principal.
