> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4