[issue7989] Transition time/datetime C modules to Python
Marc-Andre Lemburg m...@egenix.com added the comment: Brett Cannon wrote: Brett Cannon br...@python.org added the comment: So I see a couple of objections here to the idea that I will try to address. First is MAL's thinking that this will undo any C code, which it won't. The idea is that stdlib modules that do not inherently rely on other C code (e.g. sqlite3 does not fall underneath this) would have a pure Python implementation with possible C enhancements. In the case of datetime that code is done, so it won't go anywhere. In this case it would be bringing in a pure Python implementation like the one PyPy maintains. You can look at heapq if you want an existing example of what it looks like to maintain a pure Python and C version of a module. So the proposal is to have something like we have for pickle, with cPickle being the fast version and pickle.py the slow Python one ? Since no CPython would use the Python version, who would be supporting the Python-only version ? -- title: Add pure Python implementation of datetime module to CPython - Transition time/datetime C modules to Python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Transition time/datetime C modules to Python
Marc-Andre Lemburg m...@egenix.com added the comment: Alexander Belopolsky wrote: Alexander Belopolsky belopol...@users.sourceforge.net added the comment: As far as I remember, the datetime module started as a pure python module and was reimplemented in C around year 2003 or so. One of the important additions at that time was the C API to datetime functionality. I am afraid that with the _timemodule.c/timemodule.py split there will be more an more functionality that is awkward to access from C API. That's correct, though the main reason for rewriting the module in C was to gain performance - this is essential for basic types like date/time types. -1 on undoing the C rewrite. It would be much better to spell out the problems you mention and provide patches to implement solutions for them. -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Transition time/datetime C modules to Python
Changes by Daniel Urban urban.dani...@gmail.com: -- nosy: +durban ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Transition time/datetime C modules to Python
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: For the datetime module there are also a few more subtle issues that would make it difficult to make a hybrid C/Python implementation. The problem is that unlike the time module where most of the functionality is implemented in module level functions, datetime functionality is entirely in class methods. One may suggest to use inheritance and derive datetime classes from those implemented in _datetime.c, but this will not work because for example datetime + timedelta will return a _datetime class unless __add__ is overridden in Python. There is another even less obvious issue with inheriting from datetime classes: see issue #5516. Therefore, it looks like there are only two choices: 1. Replicate all functionality in both _datetime.c and datetime.py and thus double the cost of implementing new features in CPython. (OK, maybe not double because Python development is easier than C, but increase instead of decrease.) 2. Incur a performance penalty in every method because every C call wil have to be wrapped in Python. Another -1 from me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Transition time/datetime C modules to Python
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: -- versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Transition time/datetime C modules to Python
Brian Curtin cur...@acm.org added the comment: It seems like this might not be worth it or a good idea, and I have no strong feeling for this being done. Feel free to close/reject this one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Transition time/datetime C modules to Python
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Brett Cannon wrote in a comment (msg106498) on another issue: The stated long-term goal of the stdlib is to minimize the C extension modules to only those that have to be written in C (modules can still have performance enhancing extension back-ends). Since datetime does not meet that requirement it's not a matter of if but when datetime will get a pure Python version and use the extension code only for performance. I'll keep this open for a while to give Brett and others a chance to respond to opposition. -- nosy: +brett.cannon priority: normal - low type: behavior - feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Transition time/datetime C modules to Python
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Also, my opposition is only to splitting datetime. While I am not against splitting the time module, I believe it should be phased out eventually and posix compatibility portion folded into posix module. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Transition time/datetime C modules to Python
Brett Cannon br...@python.org added the comment: So I see a couple of objections here to the idea that I will try to address. First is MAL's thinking that this will undo any C code, which it won't. The idea is that stdlib modules that do not inherently rely on other C code (e.g. sqlite3 does not fall underneath this) would have a pure Python implementation with possible C enhancements. In the case of datetime that code is done, so it won't go anywhere. In this case it would be bringing in a pure Python implementation like the one PyPy maintains. You can look at heapq if you want an existing example of what it looks like to maintain a pure Python and C version of a module. Alexander is worried about performance because of Python shims and duplication of work. For the performance issue, there is none. If you look at something like heapq you will see that there is an `import *` in there to pull in all extension code; there is no Python shim to pass through if you don't engineer the extension that way. So in datetime's case all of the extension code would just get pulled into datetime.py directly and not have any indirection cost. As for duplication of work, we already have that with datetime in the other Python VMs. IronPython, Jython, and PyPy have to do their own version of datetime because the stdlib doesn't provide a pure Python version for them to use. So while CPython might not be duplicating work, other people are. Besides, people typically prototype in Python anyway (including you, Alexander, for the UTC patch) and then write the C code, so there really isn't any wasted development cycles by having the Python and C version already. The key thing to remember is that this is so the VMs other than CPython are not treated as second-class. They are legit implementations just like CPython, but because we have this legacy stuff written in C in the stdlib they are put at a disadvantage. It would be better to pool resources and make sure everyone gets to use an equivalent standard library when possible. And I should also mention I expect the PyPy folks to be the ones to move their code over; I would never expect anyone to re-implement datetime from scratch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Transition time/datetime C modules to Python
anatoly techtonik techto...@gmail.com added the comment: It would be nice to see the transition accompanied by some tutorial that could be used as an example for other similar tasks. -- nosy: +techtonik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Transition time/datetime C modules to Python
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Brett, Thanks for your explanation. It looks like I misunderstood the proposal. I though the idea was to have some methods of e.g. date type implemented in python and some in C. What you propose is much simpler. Effectively, your proposal is let's distribute a pure python implementation of datetime with CPython. I don't have any problem with this. Patches welcome! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Transition time/datetime C modules to Python
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: As far as I remember, the datetime module started as a pure python module and was reimplemented in C around year 2003 or so. One of the important additions at that time was the C API to datetime functionality. I am afraid that with the _timemodule.c/timemodule.py split there will be more an more functionality that is awkward to access from C API. -- assignee: - belopolsky nosy: +belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Transition time/datetime C modules to Python
New submission from Brian Curtin cur...@acm.org: After discussion on numerous issues, python-dev, and here at the PyCon sprints, it seems to be a good idea to move timemodule.c to _timemodule.c and convert as much as possible into pure Python. The same change seems good for datetime.c as well. -- components: Library (Lib) messages: 99774 nosy: brian.curtin priority: normal severity: normal stage: needs patch status: open title: Transition time/datetime C modules to Python type: behavior versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Transition time/datetime C modules to Python
Brian Curtin cur...@acm.org added the comment: Correct, your wording is better than mine. I'll ask around and see where that datetime module may be and what it's state is. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
