This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients
Date 2004-05-03.15:26:28
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=38388

About the Py_BUILD_CORE issue:

Sorry, I didn't know that Python does not define this macro for
core modules. Nevertheless, looking at the datetime module code
I don't really understand why you would need such a macro 
in the first place. Since the datetime module is the only code
including the datetime.h header file it should be easy to add
a macro definition just before importing datetime.h.

On the TimeFromTicks() issue:

The whole point of this discussion is to make the datetime
module easily usable for authors of database modules.
Since the DB API specifies that the module will need
to export the three functions, two of which are available
through the datetime module already, I don't really see
your point in not wanting to add it.

BTW, you are wrong in the assumption that the DB API spec
will move away from a generic API for date/time objects.
The DB API has always been defined in terms of interfaces
and does not force a certain set of tools onto the developer.
The datetime module will become one possible choice for
DB API authors, others will want to stick to mxDateTime,
use strings, ticks integers or more specific objects for 
interfacing. That won't change, so there is no 
"transition period".
History
Date User Action Args
2007-08-23 15:31:56adminlinkissue876130 messages
2007-08-23 15:31:56admincreate