[Python-Dev] PEP 321 and Gustavo's DateUtil (original) (raw)

Robert Brewer fumanchu at amor.org
Sat Apr 10 18:14:17 EDT 2004

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.

  1. 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:

  1. dateutil.parser imports os.path and sys but doesn't reference them.
  2. _resultbase uses slots for some odd reason.
  3. 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.
  4. 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

More information about the Python-Dev mailing list