On Jan 31, 8:49 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
> Maybe process_record expects some minimum buffer size? The cpp example
> uses char record[100], but you are allocating only a few bytes with the
> string "My Record"
No, I've already tried padding record out to the full size. Bu
I'm attempting to use ctypes on a DLL with the following
signature:
__declspec(dllimport) void process_record(char *, char *);
An example .cpp file has code like this:
int main(int argc, char **argv)
{
char record[100];
char code[6];
...
process_record(code, recor
> Could [RFC 3339] be a candidate for a "default" consumption
> format for date-time strings?
+1
--
http://mail.python.org/mailman/listinfo/python-list
Yeah, it's a trivial function that's rewritten for each new project
that passes datetime objects as strings <0.2 wink>. On the basis of it
being a trivial convenience, I could propose removing hundreds of
"redundant" functions from the library. ;-)
Never mind. I'll drop it.
Jeff Bauer
Rubicon,
Magnus,
Thanks for your reply. I wasn't clear in my
prior post. Rather than support the entire
range of iso8601 formats, how about *just* the
format that datetime emits? Call it the
parse_datetime() function. Then it would be
possible to take the output string of a datetime
object and read it
I was a little surprised to recently discover
that datetime has no method to input a string
value. PEP 321 appears does not convey much
information, but a timbot post from a couple
years ago clarifies things:
http://tinyurl.com/epjqc
> You can stop looking: datetime doesn't
> support any kind o
