homepage

This patch brings the pure-python datetime more in-line with the C module. We have been running these modifications in PyPy2 stdlib for more than a year with no issue.
Includes:
- General PEP8/cleanups
- Better testing of argument types passed to constructors
- Removal of duplicate operations (in some paths values were checked twice for validity)
- Optimization of timedelta creation (brings it from 8-9usec to ~6 usec on CPython 3.3 on local machine)
- Enhancements/bug fixes in tests

Also includes bug fixes/tests for certain rounding cases (doesn't apply to the 3.4 version).

Updated patch to v2 with another test/fix for type checking of __format__ argument to match the C module.

_check_int_field seems needlessly complex. When you want a value that is logically an integer (not merely capable of being coerced to an integer), you want object.__index__, per PEP 357, or to avoid explicit calls to special methods, use operator.index. Any reason to not just use operator.index directly?

The C datetime module uses the 'i' code for parsing these args, not 'n' (which would correspond to operator.index). Using operator.index fails a test case I added (cases for classes like decimal.Decimal, implementing __int__ but not __index__).

That's actually an argument to fix the C datetime implementation. Right now, you get:
 >>> from decimal import Decimal as d
 >>> from datetime import datetime
 >>> datetime(d("2000.5"), 1, 2)
 datetime.datetime(2000, 1, 2, 0, 0)
This is wildly inconsistent; if you passed 2000.0, it would raise an exception because float (even floats directly equivalent to an int value) are forbidden. But the logically equivalent Decimal type will work just fine, silently truncating. Basically any user defined type with integer coercion (but not integer equivalence) would have the same problem; str doesn't, because str is special cased (it doesn't actually have __int__), but any user-defined str-like class that defined int coercion would work as a datetime arg in a way str does not.
You've just given me an excuse to open my first bug. Thanks! :-)

Right, that's the behavior as it stands, so I hope this patch can be considered independently of that issue (and if such a change is made to the C implementation, then a corresponding change could be made in the python implementation).

Oh, definitely. No reason to delay this just because I have my knickers in a twist on a tangential matter.

I would like to hear from PyPy developers before we decide what to do with this effort. Pure Python implementation is not used by CPython,
but I am afraid that people who actually use it will not appreciate the code churn.

Oh - I did not realize that this originated in PyPy.

Yes, I am the PyPy developer who worked on these datetime improvements there -- just finally got around to pushing them upstream.

Brian,
I would like to apply your changes for 3.5. Do you have any updates?

Updated patch, now it also caches the result of __hash__ like the C accelerator.

Brian,
Could you, please update the summary of your changes from your first post? For example, you did not mention caching of the timedelta hashes.
This particular chance seems to call for a discussion.
Do we cache timedelta hashes in C implementation? What is the general wisdom on this technique? AFAICR, such hashing is done in integer objects, but I vaguely remember an old discussion on whether the same should be done for tuples. Can you remind me what was the outcome for tuples?

> Updated patch, now it also caches the result of __hash__ like the C accelerator.
I should read your notes! Sorry, Brian. You already answered my questions. Too bad that the latest notes are so far from the entry area.
Still, it would be helpful if you could provide a self-contained description that I can copy to the NEWS file. (Don't put it in the patch - NEWS file gets out of date very quickly - put it in a tracker comment.)
Also, with your patch, are we in sync with PyPy? If so, with what version?

[Josh Rosenberg]
> You've just given me an excuse to open my first bug.
Did you open an issue for that? (Use "n" code in date/datetime constructors.)

Here is the tuple hash caching thread that I mentioned above:
https://mail.python.org/pipermail/python-dev/2003-August/037416.html
Since the C code uses caching already, I don't think we need to discuss it any further. And the thread on tuples does not give any good reason not to cache anyways.

New changeset 5313b4c0bb6c by Alexander Belopolsky in branch 'default':
Closes issue #20858: Enhancements/fixes to pure-python datetime module
https://hg.python.org/cpython/rev/5313b4c0bb6c