datetime iso8601 string input

[Rubic]

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 of conversion from string.
> The number of bottomless pits in any datetime
> module is unbounded, and Guido declared this
> particular pit out-of-bounds at the start so
> that there was a fighting chance to get
> *anything* done for 2.3.

I can understand why datetime can't handle
arbitrary string inputs, but why not just
simple iso8601 format -- i.e. the default
output format for datetime?

Given a datetime-generated string:

  >>> now = str(datetime.datetime.now())
  >>> print now
  '2006-02-23 11:03:36.762172'

Why can't we have a function to accept it
as string input and return a datetime object?

  datetime.parse_iso8601(now)

Jeff Bauer
Rubicon, Inc.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: datetime iso8601 string input

[Rubic]

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 back in to round-trip the
data.

>>> now = str(datetime.datetime.now())
>>> now
'2006-02-24 06:58:23.737586'
>>> datetime.parse_datetime(now)
datetime.datetime(2006, 2, 24, 6, 58, 23, 737586)

Jeff Bauer
Rubicon, Inc.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: datetime iso8601 string input

[Rubic]

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, Inc.

-- 
http://mail.python.org/mailman/listinfo/python-list

ctypes error on exit of win32 application

[Rubic]

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, record);

When I invoke it under Python everything fine
while the interpreter is running:

   >>> from ctypes import *
   >>> record = create_string_buffer("My Record")
   >>> code = create_string_buffer('\000' * 6)
   >>> cdll.grouper.process_recode(code, record)
   >>> print code.value
   ''

But when the interpreter exits, either interactively
or from a script, the following Program Error popup
gets displayed:

  "python.exe has generated errors and will be closed
   by Windows.  You will need to restart the program."

What can I do to prevent this error?
(Environment: Win2000, Python 2.5)
--
Jeff Bauer
Rubicon, Inc.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ctypes error on exit of win32 application

[Rubic]

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.  But thank
you for the suggestion.
--

Jeff Bauer
Rubicon, Inc.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: datetime iso8601 string input

[Rubic]

> Could [RFC 3339] be a candidate for a "default" consumption
> format for date-time strings?

+1

-- 
http://mail.python.org/mailman/listinfo/python-list