New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add C API to datetime module #39811
Comments
The datetime module does not have a C API which means |
Logged In: YES Marc-Andre, can you review this? I think you have more There's certainly no objection to giving datetime a C API, and Anthony, you probably need to add doc and test patches. |
Logged In: YES I have no objection to providing patches for doc and test. A |
Logged In: YES This is a good start. However, you should add more APIs for If you want to make the datetime module usable for database |
Logged In: YES I didn't think any additional API would be necessary for PyDateTime_GET_YEAR(o)
PyDateTime_GET_MONTH(o)
PyDateTime_GET_DAY(o)
PyDateTime_DATE_GET_HOUR(o)
PyDateTime_DATE_GET_MINUTE(o)
PyDateTime_DATE_GET_SECOND(o)
PyDateTime_DATE_GET_MICROSECOND(o)
PyDateTime_TIME_GET_HOUR(o)
PyDateTime_TIME_GET_MINUTE(o)
PyDateTime_TIME_GET_SECOND(o)
PyDateTime_TIME_GET_MICROSECOND(o) Were you thinking of something else that is needed? As for interfacing at the C level for converting from Unix DateFromTicks() --> datetime.date.fromtimestamp() TimeFromTicks() is not already exposed but discussions with Any comments? |
Logged In: YES Thanks for the clarification. I had forgotten about the As for TimeFromTicks(): Could you add C APIs for the three DB API ticks interface Other things that are missing:
I think that datetimeapi.h should be enough for a developer |
Logged In: YES Any progress on this ? |
Logged In: YES You haven't yet responded to my previous comments -- it |
Logged In: YES Oops! It looks like my own misunderstanding of SourceForge |
Logged In: YES Anthony, have you had a chance to look at the comments ? |
Logged In: YES Sorry for the delay. Things here have been quite busy
|
Logged In: YES Thanks for the comments...
|
Logged In: YES I am back at work after finishing my move so I think I can 1-4) The main reason for datetimeapi.h as opposed to simply
|
Logged In: YES Any chance to look at this? Any hope of this being included |
Logged In: YES Sorry for not getting back to you earlier: I didn't see you last 1-4) Python defines a macro during the Python build process
|
Logged In: YES I spent some time getting the two include files merged On the DateFromTicks(), TimestampFromTicks(), |
Logged In: YES About the Py_BUILD_CORE issue: Sorry, I didn't know that Python does not define this macro for On the TimeFromTicks() issue: The whole point of this discussion is to make the datetime BTW, you are wrong in the assumption that the DB API spec |
Logged In: YES About the Py_BUILD_CORE issue: You are suggesting that I define this in datetimemodule.c On the TimeFromTicks() issue: You obviously consider it important that the three methods As for the transition period, I assumed that with the |
Logged In: YES Macro: I don't know whether you need the macro or not (you probably TimeFromTicks(): I' ve stated my point. I don't think there's anything IMHO, a product that's aimed at developers Transition: This was already discussed on the db-api list. We love |
Logged In: YES I don't understand what TimeFromTicks() is supposed to do. The datetime module should certainly have a method to Do any databases really store time-of-day as a seconds-from- |
Logged In: YES From the DB API specs: TimeFromTicks(ticks)
This function constructs an object holding a
time value
from the given ticks value (number of seconds
since the
epoch; see the documentation of the standard
Python time
module for details).
The reason for this having this API is to be able to construct
an object suitable for passing to the database given a Unix
ticks value. Since the ticks value contains both a date and
a time part and most databases have a special column type
for time value, we need two constructor APIs, one to extract
just the date part and one for the time part. Here's the mxDateTime implementation for reference: def TimeFromTicks(ticks,
# Locals:
DateTimeDelta=DateTimeDelta,localtime=_time.localtime):
local time
|
Logged In: YES Attached are the modified patches based on your suggestions. As for the TimeFromTicks() routine, Oracle has absolutely no |
Logged In: YES Thanks, but I don't have time to review it. As for the TimeFromTicks() API: I can understand that you don't feel like implementing it, I'm not very interested in datetime myself, since I'll Feel free to check in your changes. Thanks. |
Logged In: YES Tim, please review. Thanks. |
Logged In: YES Under the belief that the *intent* of this patch is to add a C I would not add TimeFromTicks() to the Python datetime API If people want time-of-day from a POSIX timestamp, it |
Logged In: YES I would agree with your assessment of the issue regarding Did you have a chance to review the actual code? The changes |
Logged In: YES Assigned to me for the next review. Can't do it immediately, |
Logged In: YES Sure. What's the chance of it being reviewed prior to the |
Logged In: YES I intend to do it this week, but have no time today or |
Logged In: YES Heh. Just noticed there are 6 patches attached to this |
Logged In: YES Assuming the current state of the proposal consists of the The one necessary thing I don't see are docs: how are users Don't let that discourage you -- you're very close! If I don't |
Logged In: YES Yes, the top two files are the ones involved. As per your I understand the concern for documentation. I'll see what I |
Logged In: YES I have attached a patch for the documentation as requested.
Please review and give me your feedback. Thanks. |
Logged In: YES Thanks for your patience, Anthony! I checked this in after Doc/api/concrete.tex; new revision: 1.45 The answers to your questions are implicit in what I checked The DB API functions don't bother me one way or the other, |
Logged In: YES Yes, this has been a long time coming. Collaboration by I just noticed that I missed the macros that are defined in |
Logged In: YES Good eye! Yes, the accessor macros should be documented |
Logged In: YES The additional changes to the documentation are available in |
Logged In: YES This API is seriously broken. datetime.h says which means that including this file from two C (or C++) I double checked, and this happens with both C and C++. This needs to be revised so that there is indeed only one |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: