possibly "rounding up" to the next whole second.

PySequence_GetItem of the time.strptime() result. Not a high probability
bug, but not inconceivable either, considering people can provide their own
'time' module.

returns a non-string when converting %Z.

Will backport.

Probably should be backported.

In C++, it's an error to pass a string literal to a char* function
without a const_cast().  Rather than require every C++ extension
module to put a cast around string literals, fix the API to state the
const-ness.

I focused on parts of the API where people usually pass literals:
PyArg_ParseTuple() and friends, Py_BuildValue(), PyMethodDef, the type
slots, etc.  Predictably, there were a large set of functions that
needed to be fixed as a result of these changes.  The most pervasive
change was to make the keyword args list passed to
PyArg_ParseTupleAndKewords() to be a const char *kwlist[].

One cast was required as a result of the changes:  A type object
mallocs the memory for its tp_doc slot and later frees it.
PyTypeObject says that tp_doc is const char *; but if the type was
created by type_new(), we know it is safe to cast to char *.

accepts strings only for unpickling reasons.  This check prevents the honest
mistake of passing a string like '2:59.0' to time() and getting an insane
object.

the changes.

Treat comparing a date to a datetime like a mixed-type comparison.

The LaTeX is untested (well, so is the new API, for that matter).
Note that I also changed NULL to get spelled consistently in concrete.tex.
If that was a wrong thing to do, Fred should yell at me.

New include file timefuncs.h exports private API function
_PyTime_DoubleToTimet() from timemodule.c.  timemodule should export
some other functions too (look for painful bits in datetimemodule.c).

Added insane-argument checking to datetime's assorted fromtimestamp()
and utcfromtimestamp() methods.  Added insane-argument tests of these
to test_datetime, and insane-argument tests for ctime(), localtime()
and gmtime() to test_time.

datetime.datetime and datetime.time could yield insane objects.  Thanks
to Jiwon Seo for the fix.

Bugfix candidate.  I'll backport it to 2.3.

It's possible to create insane datetime objects by using the constructor
"backdoor" inserted for fast unpickling.  Doing extensive range checking
would eliminate the backdoor's purpose (speed), but at least a little
checking can stop honest mistakes.

Bugfix candidate.

are within proper boundaries as specified in the docs.

This can break possible code (datetime module needed changing, for instance)
that uses 0 for values that need to be greater 1 or greater (month, day, and
day of year).

Fixes bug #897625.

(From SF patch #810751)

* Py_BuildValue("(OOO)",a,b,c)  -->  PyTuple_Pack(3,a,b,c)
* Py_BuildValue("()",a)         -->  PyTuple_New(0)
* Py_BuildValue("O", a)         -->  Py_INCREF(a)

The interning of short strings violates the refcnt==1 assumption for
_PyString_Resize().

A simple fix is to boost the initial value of "totalnew" by 1.
Combined with an NULL argument to PyString_FromStringAndSize(),
this assures that resulting format string is not interned.
This will remain true even if the implementation of
PyString_FromStringAndSize() changes because only the uninitialized
strings that can be interned are those of zero length.

Added a test case.

perpetrated by the time and datetime classes.

one good use:  a subclass adding a method to express the duration as
a number of hours (or minutes, or whatever else you want to add).  The
native breakdown into days+seconds+us is often clumsy.  Incidentally
moved a large chunk of object-initialization code closer to the top of
the file, to avoid worse forward-reference trickery.

s/isofomat/isoformat/, by Steven Taschuk.

(This is only the tip of the iceberg; the time and datetime classes
need the same treatment.)

of datetime does, accept instances of subclasses too.

__ne__ no longer complain if they don't know how to compare to the other
thing.  If no meaningful way to compare is known, saying "not equal" is
sensible.  This allows things like

    if adatetime in some_sequence:
and
    somedict[adatetime] = whatever

to work as expected even if some_sequence contains non-datetime objects,
or somedict non-datetime keys, because they only call __eq__.

It still complains (raises TypeError) for mixed-type comparisons in
contexts that require a total ordering, such as list.sort(), use as a
key in a BTree-based data structure, and cmp().

functions.  Reworked {time,datetime}_new() to do what their corresponding
setstates used to do in their state-tuple-input paths, but directly,
without constructing an object with throwaway state first.  Tightened
the "is this a state tuple input?" paths to check the presumed state
string-length too, and to raise an exception if the optional second state
element isn't a tzinfo instance (IOW, check these paths for type errors
as carefully as the normal paths).

anymore either, so don't.  This also allows to get rid of obscure code
making __getnewargs__ identical to __getstate__ (hmm ... hope there
wasn't more to this than I realize!).

attr, and copy_reg.safe_constructors.

not the maze it was.

delta_reduce():  Simplified.

(pickling no longer needs them, and immutable objects shouldn't have
visible __setstate__() methods regardless).  Rearranged the code to
put the internal setstate functions in the constructor sections.
Repaired the timedelta reduce() method, which was still producing
stuff that required a public timedelta.__setstate__() when unpickling.

is just as easy.

classes have a __reduce__ that returns (self.__class__,
self.__getstate__()).  tzinfo.__reduce__() is a bit smarter, calling
__getinitargs__ and __getstate__ if they exist, and falling back to
__dict__ if it exists and isn't empty.

compare against "the other" argument, we raise TypeError,
in order to prevent comparison from falling back to the
default (and worse than useless, in this case) comparison
by object address.

That's fine so far as it goes, but leaves no way for
another date/datetime object to make itself comparable
to our objects.  For example, it leaves Marc-Andre no way
to teach mxDateTime dates how to compare against Python
dates.

Discussion on Python-Dev raised a number of impractical
ideas, and the simple one implemented here:  when we don't
know how to compare against "the other" argument, we raise
TypeError *unless* the other object has a timetuple attr.
In that case, we return NotImplemented instead, and Python
will give the other object a shot at handling the
comparison then.

Note that comparisons of time and timedelta objects still
suffer the original problem, though.