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? > _______________________________________________ DB-SIG maillist - DB-SIG@python.org https://mail.python.org/mailman/listinfo/db-sig
