Changes by Berker Peksag berker.pek...@gmail.com:
--
stage: commit review - resolved
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20858
___
___
Roundup Robot added the comment:
New changeset 5313b4c0bb6c by Alexander Belopolsky in branch 'default':
Closes issue #20858: Enhancements/fixes to pure-python datetime module
https://hg.python.org/cpython/rev/5313b4c0bb6c
--
nosy: +python-dev
___
Changes by Benjamin Peterson benja...@python.org:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20858
___
Alexander Belopolsky added the comment:
Brian,
Could you, please update the summary of your changes from your first post? For
example, you did not mention caching of the timedelta hashes.
This particular chance seems to call for a discussion.
Do we cache timedelta hashes in C
Alexander Belopolsky added the comment:
Updated patch, now it also caches the result of __hash__ like the C
accelerator.
I should read your notes! Sorry, Brian. You already answered my questions.
Too bad that the latest notes are so far from the entry area.
Still, it would be helpful if
Alexander Belopolsky added the comment:
[Josh Rosenberg]
You've just given me an excuse to open my first bug.
Did you open an issue for that? (Use n code in date/datetime constructors.)
--
___
Python tracker rep...@bugs.python.org
Alexander Belopolsky added the comment:
Here is the tuple hash caching thread that I mentioned above:
https://mail.python.org/pipermail/python-dev/2003-August/037416.html
Since the C code uses caching already, I don't think we need to discuss it any
further. And the thread on tuples does not
Brian Kearns added the comment:
Updated patch, now it also caches the result of __hash__ like the C accelerator.
--
Added file: http://bugs.python.org/file35894/datetime-py35.patch
___
Python tracker rep...@bugs.python.org
Alexander Belopolsky added the comment:
Brian,
I would like to apply your changes for 3.5. Do you have any updates?
--
stage: patch review - commit review
versions: +Python 3.5 -Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
New submission from Brian Kearns:
This patch brings the pure-python datetime more in-line with the C module. We
have been running these modifications in PyPy2 stdlib for more than a year with
no issue.
Includes:
- General PEP8/cleanups
- Better testing of argument types passed to constructors
Changes by Brian Kearns bdkea...@gmail.com:
Added file: http://bugs.python.org/file34294/datetime-py33.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20858
___
Brian Kearns added the comment:
Also includes bug fixes/tests for certain rounding cases (doesn't apply to the
3.4 version).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20858
___
Changes by Brian Kearns bdkea...@gmail.com:
Added file: http://bugs.python.org/file34296/datetime-py34-v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20858
___
Brian Kearns added the comment:
Updated patch to v2 with another test/fix for type checking of __format__
argument to match the C module.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20858
Changes by Ned Deily n...@acm.org:
--
nosy: +belopolsky, lemburg, tim.peters
stage: - patch review
versions: +Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20858
___
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
assignee: - belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20858
___
Josh Rosenberg added the comment:
_check_int_field seems needlessly complex. When you want a value that is
logically an integer (not merely capable of being coerced to an integer), you
want object.__index__, per PEP 357, or to avoid explicit calls to special
methods, use operator.index. Any
Josh Rosenberg added the comment:
That's actually an argument to fix the C datetime implementation. Right now,
you get:
from decimal import Decimal as d
from datetime import datetime
datetime(d(2000.5), 1, 2)
datetime.datetime(2000, 1, 2, 0, 0)
This is wildly inconsistent;
Brian Kearns added the comment:
Right, that's the behavior as it stands, so I hope this patch can be considered
independently of that issue (and if such a change is made to the C
implementation, then a corresponding change could be made in the python
implementation).
--
Josh Rosenberg added the comment:
Oh, definitely. No reason to delay this just because I have my knickers in a
twist on a tangential matter.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20858
Alexander Belopolsky added the comment:
I would like to hear from PyPy developers before we decide what to do with this
effort. Pure Python implementation is not used by CPython,
but I am afraid that people who actually use it will not appreciate the code
churn.
--
nosy:
Alexander Belopolsky added the comment:
Oh - I did not realize that this originated in PyPy.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20858
___
Brian Kearns added the comment:
Yes, I am the PyPy developer who worked on these datetime improvements there --
just finally got around to pushing them upstream.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20858
Changes by Brian Kearns bdkea...@gmail.com:
Added file: http://bugs.python.org/file34297/datetime-py33-v3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20858
___
Changes by Brian Kearns bdkea...@gmail.com:
Added file: http://bugs.python.org/file34298/datetime-py34-v3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20858
___
25 matches
Mail list logo
