Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
On Fri, Aug 6, 2010 at 3:44 AM, Marc-Andre Lemburg <rep...@bugs.python.org> wrote: .. > Why are you calling the ticket "*Add* pure Python implementation of time > module to CPython" when you appear to be after *replacing* the C > implementation of the time module with a Python version ? > I have deliberately made the title similar to issue 7989 so that it is clear that the idea is the same: add python implementations of time module functions which are overridden by existing C implementations in CPython. The only difference with datetime is that for Python implementation to work, it needs access to some system facilities. The datetime.py module needs access to some of these facilities as well, but currently it works around this problem by importing them from time module. The current situation has several problems: 1. Datetime.py time source (time.time()) represents time as a floating point number which leads to system dependent behavior and introduces floating point operations where they are not needed. 2. Datetime.strftime function is restricted to years >= 1900 even on platforms where system strftime is perfectly good over full range of datetime. This is done expressly because semantics of time.strftime dictate such behavior. See issue 1777412. 3. The datetime module could benefit from access to tm_zone and tm_gmtoff components of the tm structure, but introducing those in the output of time.localtime() would require either hidden member hackery or loss of backwards compatibility. See issues #1647654, #7662, and #9527. > The same argument as for the datetime module applies: you can *add* > a compatible Python version of the same module for other Python > implementations to use, but undoing the work that has been done > in order to provide a faster implementation of the Python version > is a no-go. > I completely agree. Actually my outline in the first post is incomplete. What I would like to do is: 1. Rename timemodule.c to _timemodule.c 2. Convert non-module _time.c (home of code shared between time and datetime C implementations) to a proper C extension. See issue 9012, msg109221 for description of the problem with the current strategy. For luck of better name, I'll call the resulting module _basictime, so _time.c will get renamed to _basictimemodule.c. 3. Make _basictime module expose C and Python API to basic time facilities: integer-valued time sources (gettimeofday, clock, etc.), integer-based sleep method (say nanosleep), thin wrappers around system strftime and strptime functions and tzset method. 4. No changes will be done to timemodule.c other than renaming. The new time.py will import _basictime to implement it's methods in python, but will end with from _time import *. The _time module will not depend on _basictime. 5. In the future, but not as a part of this proposal, datetime C and python implementations can start using _basictime for low level access rather than time. > Both datetime and time module functionalities need to be as fast as > possible, since they are used a lot in Python code. That was the > main reason for having a C implementation of the datetime and time > modules. > Absolutely. In fact this proposal will open the door to implementing *faster* C API to basic time facilities. I do want _basictime to properly expose its C API similarly to the way datetime module already does. The current situation is somewhat cheating: datetime module advertises fast C API, but under the hood imports time module and makes python calls to its methods. BTW, this brings a point that I think I missed when I introduced datetime.py. Should PyDateTime_CAPSULE_NAME be changed from "datetime.datetime_CAPI" to "_datetime.datetime_CAPI" in order to eliminate even small overhead that loading datetime rather than _datetime carries? > Python C function calls are still a lot faster than Python function > calls. You can't just replace a C function call with a Python one > without taking this into account. For these modules, it's not just > the API compatibility that matters, performance is just as > relevant and I don't really see a point in making CPython slower > just to make maintenance of stdlib modules that are not needed by > CPython easier. Brett addressed this point responding to my own concerns in msg107295 and msg108047. I will just repeat: this proposal will make no changes to the functions that CPython users will import from time module. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9528> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
