I was just using the sqlite3 package and was very confused when trying to open an sqlite database from a relative path, because the only error provided was:

  File "/path/to/filepy", line 50, in __init__
    self.connection = sqlite3.connect(path)
sqlite3.OperationalError: unable to open database file

It turns out I was just executing Python from the wrong location and therefore my relative path was broken. Not a big problem. But it was confusing because it only throws this generic OperationalError.

Could it instead throw a FileNotFoundError if the db simply doesn't exist at the specified path?

> Could it instead throw a FileNotFoundError if the db simply doesn't exist at the specified path?

We pass the database path pretty much straight to sqlite3_open_v2(), via the os.PathLike interface, so any errors we get come straight from SQLite (apart from os.PathLike errors). We translate SQLite error codes to the corresponding DP-API exception, as defined per PEP 249.

Raising FileNotFoundError would mean adding support for validating the path prior to calling sqlite3_open_v2() _and_ maintaining backwards compatibility (in-memory database, creating new database file if the path points to a valid directory, etc.). This will complicate the code unnecessary, IMO. I suggest to keep the current behaviour.

See also the slightly related bpo-24139.

Such a change would be backwards incompatible and no longer in line with PEP 249.

I also don't understand what you regard as confusing about the message "unable to open database file". The message could be extended to include the path, but apart from that, it's as clear as it can get :-)