[Python-Dev] strptime recapped

[Guido van Rossum]

(I'm still here, for maybe another hour.)

> I am getting more and more frustrated with the way things are going here
> lately.  At this point I would be more than happy to pass off anything
> that's assigned to me to other people and just unsubscribe from python-dev.
> I feel like there are enormous contradictions in the way different changes
> to Python are being addressed.

This sounds like a reference to something I've said but I don't get it.

> If you want to take over any of these bugs or patches, feel free:
> 
>     411881 Use of "except:" in modules
>     569574 plain text enhancement for cgitb
>     542562 clean up trace.py
>     474274 Pure Python strptime() (PEP 42)
>     541694 whichdb unittest

>From time to time we all get frustrated.  I, too, wish things would
move along quicker.  One thing that may not be obvious is that most of
PythonLabs' resources (myself to some extent excluded) have been
consumed by Zope projects recently, significantly reducing the time we
can spend on moving Python projects along.  This is part of our deal
with Zope Corp: they pay our salaries, we have to spend over half our
time on Zope Corp projects.  That's on average: sometimes we spend
weeks or more exclusively on Python stuff, other times we spend weeks
working on Zope Corp stuff nearly full time.

>     >> I would prefer a time.py module be created to hold Brett's strptime
>     >> function.  On import, the last thing it would try doing is to import
>     >> * from _time, which would obliterate Brett's Python version if the
>     >> platform supports strptime().
> 
>     Guido> That's only a good idea if Brett's Python code has absolutely no
>     Guido> features beyond the C version.
> 
> I don't understand what you mean.  Guido's probably gone by now.  Perhaps
> someone can channel him.  I am clearly missing something obvious, but I
> don't see any support for the argument that having the existing time module
> call out to a separate Python module makes a lot of sense.  (Other than the
> fact that it comes from the BDFL, of course.)

I meant that if Brett's code has useful features not found in the
standard strptime, it should be available explicitly (for those who
want the extra features) and not be overwritten by the C version even
if it exists.

I'm not sure what your objection is against calling out to Python from
C.  We do it all the time, e.g. in PyErr_Warn().

I guess my objection (of -0 strength) against renaming time to _time
is that you'd have to fix a dozen or so build recipes for all sorts of
exotic platforms.  The last time something like this was done (for
new, a much less popular module than time) the initial change set
broke the Windows build, and I think I saw Mac build changes for this
issue checked in today or yesterday.

We can avoid all that if the time module calls out to strptime.py.

> If we put Brett's changes into time.py (I'd argue that initially all we want
> is strptime(), but can live with the other stuff assuming it's tested -
> after all, it has to go somewhere), then
> 
>     from _time import *
> 
> at the bottom, the only thing to be eliminated would be his version of
> strptime(), and only if the platform libc didn't support it.  The
> Gregorian/Julian date stuff would remain.  If you don't want them exposed in
> time, just prefix them with underscores and don't add them to time.all.

It's not that I don't want to expose them.  I haven't seen them, so I
don't know how useful they are.

However (as I have tried to point out a few times now in response to
proposed changes to calendar.py) I plan to introduce the new datetime
type that's currently living in nondist/sandbox/datetime/, either the
Python version or the C version if we find time to finish it.  This
has all the date/time calculations you want, can represent years from
AD 0 till 9999 (we can easily extend it if that's not enough :-) and I
would like all code in need of date/time calculations to be based on
this rather than grow more ad-hoc approaches to doing essentially the
same.

> The original patch
> 
>     http://python.org/sf/474274
> 
> was just about adding strptime() to the time module.  All PEP 42 asked for
> was
> 
>     Add a portable implementation of time.strptime() that works in clearly
>     defined ways on all platforms.
> 
> All the other stuff is secondary in my mind to making time.strptime()
> universally available and should be dealt with separately.

Correct.

> If performance isn't a big issue (I doubt it will be most of the time), I
> can see dropping the C version of time.strptime altogether.  I still think
> the best way to add new stuff which is written in Python to the time module
> is to have time.py be the front-end module and have it import other stuff
> from a C-based _time module.

I hope I can dissuade you from this.

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