[Python-Dev] Broken strptime in Python 2.3a1 & CVS

[Guido van Rossum]

> Subject: RE: [Python-Dev] Broken strptime in Python 2.3a1 & CVS
> From: Tim Peters <tim.one@comcast.net>
> To: guido@python.org
> Cc: Brett Cannon <bac@OCF.Berkeley.EDU>, python-dev@python.org
> Date: Tue, 14 Jan 2003 08:47:58 -0500
> X-warning: 24.153.64.2 in blacklist at unconfirmed.dsbl.org
>     (http://dsbl.org/listing.php?24.153.64.2)
> X-Spam-Level: 
> X-MailScanner: Found to be clean
> 
> [Tim]
> >> I think we should lose the C version of strptime and use
> >> _strptime.py everywhere now -- allowing x-platform accidents to
> >> sneak thru is un-Pythonic (unless they're *valuable* x-platform
> >> accidents <wink> -- strptime accidents are random crap).
> 
> [Guido]
> > Guess what.  Through clever use of the time-machine, we *are* using
> > _strptime.py everwhere now.  There's an #undef HAVE_STRPTIME in
> > timemodule.c.

[Tim]
> I know.  I want to delete the C wrapper too and get rid of
> HAVE_STRPTIME: full steam ahead, no looking back.  This is pushing
> back against the growing notion that the way to deal with legacy
> platform strptime quirks is to keep an option open to recompile
> Python, to avoid using the portable code.  Since that will be the
> easiest way out (one person here has already taken it), we'll never
> get Python's own strptime story straight so long as it's an option.

OK.  Let's get rid of the C wrapper around the C library's strptime().

The C wrapper around _strptime.strptime() stays, of course.  It
currently has a bit of an inefficiency (what happens when it tries to
import _strptime is a lot more than I'd like to see happen for each
call) but that's a somewhat tricky issue that I'd like to put off for
a little while; I've added a SF bug report as a reminder.  (667770)

--Guido van Rossum (home page: http://www.python.org/~guido/)