[Python-Dev] PEP 321 and Gustavo's DateUtil

[Robert Brewer]

There was some discussion about Gustavo Niemeyer's DateUtil module back
in March:

http://aspn.activestate.com/ASPN/Mail/Message/python-dev/2022361

...and an immediate question was whether it fulfilled (or exceeded ;)
the requirements of PEP 321:

http://www.python.org/peps/pep-0321.html

I looked at the dateutil.parser.py module today in some detail; with a
few slight modifications, it could very well meet PEP 321. The issues as
I see them:

1. I am *not* proposing the whole dateutil module be accepted.
Recurrence and relativedelta brought up too many unresolved questions
among developers back in March. Therefore, if dateutil.parser were to be
considered, it should stand alone, and be named independently, for
example, "dateparse" or "dateparser", IMO a sibling of the datetime
module, not a child.

2. If it were to stand on its own, it only needs about a dozen lines
modified to reduce dependency on:

    dateutil.relativedelta (1 mention, line 304):
            ret = ret+relativedelta.relativedelta(weekday=res.weekday)

...which could be replaced inline by simply distilling the relevant
chunk of relativedelta.__radd__. The only other dependency is on:

    dateutil.tz (5 mentions, lines 314-326), for example:
            ret = ret.replace(tzinfo=tz.tzutc())

...every use of which simply returns a concrete subclass of
datetime.tzinfo. To resolve this, we could:

a) include dateutil.tz in the library as its own module, "timezones", or
b) include dateutil.tz as "datetime.timezones", or
c) drop the 5 necessary tz classes into the new "dateparse" module, or
d) strip that particular functionality from dateparse, making it
effectively tz-naive.

3. Locale-dependent data is nicely separated into a "parserinfo" class,
which might benefit from built-in subclasses for major languages;
currently, the default is English.

There are minor cleaning issues, but none of them are show-stoppers:

4. dateutil.parser imports os.path and sys but doesn't reference them.
5. _resultbase uses __slots__ for some odd reason.
6. There's a mix of old- and new-style classes. I haven't see any reason
in the code not to make them all new-style.
7. Some PEP 8 conventions, like CapWord class names, might be nice.

In all, I think we could finish up yet another PEP and get some solid,
long-desired functionality out to the Python community with a minimum of
effort and even less breakage, since Gustavo's done all the hard work
already. ;)

Thoughts?


Robert Brewer
MIS
Amor Ministries
fumanchu at amor.org