[DB-SIG] Should Binary accept unicode string?

Mike Bayer mike_mp at zzzcomputing.com
Fri Jan 15 10:52:19 EST 2016

On 01/15/2016 09:47 AM, M.-A. Lemburg wrote:
> On 12.01.2016 13:59, INADA Naoki wrote:
>> Hi, all.
>> I found DB-API 2.0 defines Binary() as Binary(string).
>> https://www.python.org/dev/peps/pep-0249/#binary
>> What the string means?
>> On Python 2, should Binary accept unicode?
>> On Python 3, should Binary accept str?
> The Binary() wrapper is intended to provide extra information
> for the database module and marks the intent of the user to have
> the input parameter be bound to the binding parameter as
> binary rather than text (e.g. VARBINARY rather than VARCHAR).
> For Python 2, you'd probably use something like Binary=buffer.
> On Python 3, Binary=bytes or Binary=bytearray seem like a natural
> choices.
> The choice of possible input parameters for Binary() is
> really up to the database module author.

I still don't understand this philosophy of pep-249.   Allowing DBAPIs
to arbitrarily decide how strict / loose they want to be for
user-defined data passed to even very well known datatypes has a
negative impact on portability.   It means that code I write for one
DBAPI will fail on another.   Is it your view that databases and DBAPIs
are so fundamentally different, even for basic things like
unicodes/bytes, that attempting to provide for portability is hopeless?
 Why even have a pep-249 if I should expect that I have to rewrite my
whole application when switching DBAPIs anyway?

Obviosly, full portability between DBAPIs and databases is never going
to be possible.  But for easy things where a pro-portability decision is
clearly very feasible, like, "do / don't accept a unicode object for a
bytes type", why can't a decision be made?


More information about the DB-SIG mailing list