Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
I was probably misled by Brett's assertion that 'it's not a matter of "if" but
"when" datetime will get a pure Python version.' (msg106498) It looks like
this is not a universally shared opinion.
I am not ready to form a final opinion on datetime.py. I have ported it to 3.2
to the point where it passes the regression tests, but did not attempt to clean
up the code in any way or match C implementation on the level of doc strings
and error messages. I am attaching the diff between PyPy-2.7 and 3.2 port as
issue7989-2.7-3.2.diff here. You can find the full source in the
sandbox/py3k-datetime at r82083. I think having a working implementation will
help making a decision here.
Here are some random thoughts based on the experience with datetime.py.
The datetime module have seen very little development in the last six years.
Tracker RFEs and bug reports were languishing for years while people have been
ranting about how much better other languages handle date/time than Python.
Python-dev discussions would run into dozens of posts with an inevitable
conclusion that the situation is a mess and cannot be fixed.
It is posible that one of the reasons for the current state of affairs was that
people with the problem domain expertise did not have C skills and people with
the requisite C skills were conditioned by the C approach to time which is an
even bigger mess than what we have. I cannot rule out that if datetime.py was
easily available, we would see more patches proposed and more informed
discussions about desired features.
Raymond argues that datetime documentation is good enough and python
implementation will not add to it. I disagree. Consider this passage from
tzinfo documentation: "When a datetime object is passed in response to a
datetime method, dt.tzinfo is the same object as self. tzinfo methods can rely
on this, unless user code calls tzinfo methods directly." Is this as clear as
the following code that makes use of this?
def fromutc(self, dt):
..
if dt.tzinfo is not self:
raise ValueError("dt.tzinfo is not self")
Documentation for datetime module is indeed extensive. The reST file is over
1700 lines long. This is comparable to about 1900 lines in datetime.py (not
counting a long treatise on timezone calculations at the end of the file.) It
may be easier to find an answer in the code than in the documentation. After
all you cannot step through documentation in a debugger.
I am still between -0 and +0 about including datetime.py in the main tree. For
my own development purposes having sandbox version is adequate and maintaining
it there is easier than in-tree. It would be great, however if this discussion
would lead to clear guidelines about cases when parallel C and Python
implementations are desired and how to maintain such arrangements
----------
Added file: http://bugs.python.org/file17718/issue7989-2.7-3.2.diff
_______________________________________
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
