[DB-SIG] Remaining issues with DB API 1.1
Sun, 28 Mar 1999 17:16:49 +0200
Greg Stein wrote:
> M.-A. Lemburg wrote:
> > Greg: Are there going to be generic conversion C APIs for buffer types
> > in 1.5.2 ? And is there some resource I could point to for more
> > documentation on the types and their usage ?
> Some alternatives:
> 1) str = PyObject_Str(buf);
> 2) use buf->ob_type->tp_as_buffer-> ...
Na, we (the C programmers) don't want to fiddle with type slots...
as you said: there should be an abstract API for either calling the
type slot (if available) and reverting to the string method otherwise.
This should return a char* read-only buffer, something like
PyBuffer_AsStringAndSize(PyObject *buffer, char **mem, int **len).
> The former creates a new string object based on the buffer contents. The
> latter provides direct access to the contents without allocating
> additional memory. The tp_as_buffer stuff is not documented (beyond "the
> code is the spec/doc").
> The buffer() builtin function is documented.
> Your meta-comment about the lack of "Abstract Functions" is well-taken,
> though. There are abstract functions for most of the type slots in an
> object. However: this was done because if you're operating against a
> class instance, then it would need to invoke a method rather than use a
> type slot. There are no equivalent methods for the buffer interface, so
> the need for abstract functions is arguable. The functions would merely
> save you a bit of typing, rather than encapsulate any real
Ah, it would make things more "abstract" with all the nice
features that go with it. That's what I'm interested in. There
might some useful update to Python in the future and if I were
to hard code the current setting into my extension then I could
get into trouble a later point or simply be missing that new
nifty feature in 2.1 ;-)
> > I'm asking this because I the current CVS version of Python 1.5.2
> > doesn't have to much docs about the types and seems to be missing
> > a way to extract information out of the buffer types other than
> > going through PyArg_ParseTuple().
> That is a slow way to do it. People should use the tp_as_buffer slots'
> functions. For example, you could bind right against the address
> returned using the getreadbuffer type slot function.
> Interesting note: memory-mapped files export the buffer interface. You
> could mmap a file and then start shoving the bytes into a database by
> passing the file as a column value. hehe...
Now that's cool ;-)
> > Another issue:
> > How should we define the mapping of Unix ticks to date/time/timestamp
> > values ? ... or should we define them at all ?
> IMO, that is module-dependent. A ticks value specifies a distinct point
> in time. If a database is interacting with a column type which has less
> precision, then some kind of truncation will occur in a
> database-dependent fashion.
> Part of my pushback against the three varieties is that they attempt to
> provide coverage, when that really isn't the case. For example, MySQL
> and Informix allow you to specify DATE columns with near-arbitrary
> precision. Want just a year? No problem. How about a year and a month?
> Sure. Just an hour and minute? Yup.
> Providing a generic "type" of column called a "DATE" can encompass all
> these varieties. Subtypes (per the scheme you posted which uses __cmp__)
> can refine the generic type down to whatever precision or subtype is
This works fine on the output side (for which I proposed the
DATETIME type object wrapping DATE, TIME and TIMESTAMP), but on
the input side the constructors are simply needed to distinguish
between the different aspects. As always, the implementor can go
and map all three constructors to just one in Python using e.g.
a string in some database specific format... really no big deal.
So should we nuke the DATE, TIME and TIMESTAMP type objects from the
spec and have a generic DATETIME type object instead ?!
> > Since ticks always refer to timestamp like values, converting them
> > to date and time values will have to cause some kind of factoring.
> > In the examples I gave, local time broken down values are used
> > as basis. This could, of course, also be done using GM time.
> Historically, the ticks value was broken into specific parts using
> localtime() or its C equivalent. (and mktime() on the other side)
> If a module implementor is using a sophisticated datatype like
> mxDateTime, then they don't need to worry... it will Do The Right Thing.
> For those who don't use it, they'll have a small paragraph of C code to
So the local time assumption is correct ?!
> > I've update the spec to 1.1a12.
> Cool. I should get to updating the annotated version. It is woefully
> > The next release of mxDateTime
> > will include the new constructors for ticks based values.
> I thought it already had that. I looked thru the spec the other day. Or
> did it only have *output*, rather than constructors?
It did already have APIs for converting ticks to instances,
it's just that the naming was different. I've added a few
new Python constructors to make mxDateTime provide the
right names from the start.
Marc-Andre Lemburg Y2000: 278 days left
: Python Pages >>> http://starship.skyport.net/~lemburg/ :