On 01/15/2016 05:14 PM, Vernon D. Cole wrote: > Mike: > > Thank you for your long explanation. I got lost somewhere in the > middle there, though. > > If you are suggesting that better documentation be added to PEP-249, > then perhaps you could include a suggestion as to a (brief) note which > could be appended.
Well, I wasn't even going that far. I'm trying to get a handle on what pep-249's position is as far as portability of datatypes. It has always struck me as very weak. > > If you are suggesting that the PEP be expanded to provide a service > not now generally available, then perhaps you ought to start the > long-talked-about-but-never-tried task of writing a DBAPI level 3 PEP. Well if a DBAPI driver would like to accept a Python unicode object to a Binary() and produce bytes, some conversion is needed, and there are many possible conversions that could take place - there is every possible encoding, and at typically at least four potential candidates among those available. It's my position that the Binary() type should *not* offer to automatically choose such a conversion and should only accept Python types (or 3rd party extension types, sure) that are explicitly 1-1 mappable to a stream of bytes without a "conversion decision" being made. The type of conversion should not be guessed among a choice of several / hundreds within the Binary type. So definitely, not proposing any new service other than "disallow ambiguous input". > The present PEP (written long before Python 3) is lacking (and in at > least one case, actually wrong) any specific Python 3 implementation > details. Several enhancements and improvements to the PEP have been > talked about, most of which -- like the one you seem to be making -- > would significantly enhance a programmer's experience. There are also > several "standard extensions" and frequently added extras which could > be included in the body of a new PEP. I'd love to write the pep for DBAPI3. That task doesn't daunt me, but the task of evaluating reactions and changes to it and shepherding it to acceptance certainly does. I seem to generally be on the other side of most issues on this list and the task would be more surmountable if I had some allies to assist during the long process of defense. that said if we could at least produce / point me to a document that lists out the general things people are looking for, for me I know its fewer bindparam formats and explicitness about how unicode / strings should be handled, also there's the prepared statement thing. Oh, and the tuple/list thing for result rows that I think I'm the only person who cares about that. > _______________________________________________ DB-SIG maillist - DB-SIG@python.org https://mail.python.org/mailman/listinfo/db-sig
