Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Added file: http://bugs.python.org/file18148/datetimetester.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7989
___
Brian Curtin cur...@acm.org added the comment:
One additional change was needed to compile on Windows:
Index: PC/config.c
===
--- PC/config.c (revision 83087)
+++ PC/config.c (working copy)
@@ -116,7 +116,7 @@
{parser,
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Brian, thanks for the fix and for testing. I am attaching a commit-ready patch
issue7989e.diff, that includes Brian's fix and a few white-space changes.
I hope I've resolved the SVN issue: I was working in a read-only
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Committed in r83112.
--
resolution: accepted - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
[datetime.c] needs to be renamed in Modules/Setup.dist, and most
importantly in PC/config.c
Fixed in issue7989d.diff, thanks.
In order to commit this patch I need an SVN advise. I would like to copy
datetime.py from
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
s/strictly necessary/not strictly necessary/
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7989
___
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Removed file: http://bugs.python.org/file17913/issue9206a.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7989
___
Changes by David Fraser dav...@sjsoft.com:
--
nosy: +davidfraser
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7989
___
___
Python-bugs-list
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Is anyone interested in giving this a final review? I would like to check this
in unless someone objects or needs time to review.
--
___
Python tracker rep...@bugs.python.org
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Technically, since the C module is now named _datetime, it needs to be renamed
in Modules/Setup.dist, and most importantly in PC/config.c (because on Windows
datetime is built in the main interpreter)
--
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +merwok
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7989
___
___
Python-bugs-list mailing
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
In issue7989c.diff, I reverted to lazy import of _strptime, added cleanup of
_xyz helper functions, and made test_datetime more robust by restoring
sys.modules more thoroughly.
Unfortunately I've encountered an issue
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
issue9206b.diff fixes test_datetime in issue9206a.diff by restoring sys.modules
in-place in tearDown method.
Based on python-dev discussion, I am marking this as accepted and uploading the
patch to Rietveld for commit
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Added file: http://bugs.python.org/file17977/issue9206b.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7989
___
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Removed file: http://bugs.python.org/file17976/issue9206b.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7989
___
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Added file: http://bugs.python.org/file17978/issue9206b.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7989
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
issue7989a.diff is a partial success implementing Nick Coghlan's testing idea.
Unfortunately, datetime implementation with it's circular dependency on
_strftime is not very robust with respect to import trickery.
I am
Tim Peters tim.pet...@gmail.com added the comment:
...
Another is tzinfo attribute of time. With time t,
t.utcoffset() is kid of useless given that you
cannot subtract it from t
Sure you can - but you have to write your code to do time arithmetic. The time
implementation does so under the
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7989
___
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
- I find the _cmp() and __cmp() indirection poor style in 3.x,
especially when you simply end up comparing self._getstate() and
other._getstate() (it is also suboptimal because it can do more
comparisons than needed)
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I am talking specifically about this kind of assert:
assert 1 = month = 12, 'month must be in 1..12'
I think it should be replaced with:
if month 1 or month 12:
raise ValueError('month must be in
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
If they abuse the _ methods and complain that the C version doesn't
work, we just say we *told* you not to do that. It is not the Python
philosophy to try to protect users from mistakes that they willfully
make.
OK.
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
assert daysecondswhole == int(daysecondswhole) # can't overflow
Since int is long in 3.x, this assert does not check anything
Even with 2.5 int(x) cannot overflow, and returns a long when needed!
This assert probably checks that
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
This comment in datetime.__new__ makes me +0.5 on s/__/_/:
self = date.__new__(cls, year, month, day)
# XXX This duplicates __year, __month, __day for convenience :-(
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Fri, Jul 2, 2010 at 5:23 PM, Amaury Forgeot d'Arc
rep...@bugs.python.org wrote:
..
Even with 2.5 int(x) cannot overflow, and returns a long when needed!
This assert probably checks that the number has no fractional
Tim Peters tim.pet...@gmail.com added the comment:
I thought x was coming from integer
arithmetics, but apparently datetime.py loves floats!
The arguments to __new__ can be floats, so it's necessary to deal with floats
there.
--
___
Python
Tim Peters tim.pet...@gmail.com added the comment:
I thought x was coming from integer
arithmetics, but apparently datetime.py loves floats!
The arguments to __new__ can be floats, so it's necessary to deal with floats
there.
--
___
Python
Changes by Tim Peters tim.pet...@gmail.com:
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7989
___
___
Python-bugs-list mailing list
Tim Peters tim.pet...@gmail.com added the comment:
Do you remember why it was a good idea to
derive datetime from date?
Why not? A datetime is a date, but with additional behavior. Makes
inheritance conceptually natural.
--
___
Python tracker
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Fri, Jul 2, 2010 at 6:00 PM, Tim Peters rep...@bugs.python.org wrote:
Tim Peters tim.pet...@gmail.com added the comment:
Do you remember why it was a good idea to
derive datetime from date?
Why not? A datetime is
Tim Peters tim.pet...@gmail.com added the comment:
I'm not going to argue about whether datetime should have been subclassed
from date - fact is that it was, and since it was Guido's idea from the start,
he wouldn't change it now even if his time machine weren't out for repairs ;-)
--
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Fri, Jul 2, 2010 at 6:26 PM, Tim Peters rep...@bugs.python.org wrote:
..
I'm not going to argue about whether datetime should have been subclassed
from date - fact is that it was, and since it was
Guido's idea from
Marc-Andre Lemburg m...@egenix.com added the comment:
Alexander Belopolsky wrote:
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Fri, Jul 2, 2010 at 6:00 PM, Tim Peters rep...@bugs.python.org wrote:
Tim Peters tim.pet...@gmail.com added the comment:
Do you
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Fri, Jul 2, 2010 at 6:52 PM, Marc-Andre Lemburg
rep...@bugs.python.org wrote:
..
That said, I don't think redesigning the datetime module is part
of this ticket, just adding a second implementation of what we
already
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I am attaching a patch from issue 5288 as an example of a change that I would
favor more than issue7989-cmp.diff. This patch eliminates _utcoffset and _dst
methods that duplicate utcoffset and dst, but return integer
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
stage: needs patch - patch review
Added file: http://bugs.python.org/file17848/issue7989.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7989
Antoine Pitrou pit...@free.fr added the comment:
In any case, my threshold for moving this forward is for someone to
review the code in sandbox.
Ok some comments:
- I find the _cmp() and __cmp() indirection poor style in 3.x, especially when
you simply end up comparing self._getstate() and
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Thanks a lot for the review. Please see my replies below.
On Thu, Jul 1, 2010 at 12:09 PM, Antoine Pitrou rep...@bugs.python.org wrote:
..
- I find the _cmp() and __cmp() indirection poor style in 3.x,
especially when
R. David Murray rdmur...@bitdance.com added the comment:
If they abuse the _ methods and complain that the C version doesn't work, we
just say we *told* you not to do that. It is not the Python philosophy to
try to protect users from mistakes that they wilfully make.
--
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
R. David Murray rdmur...@bitdance.com added the comment:
If they abuse the _ methods and complain that the C version doesn't
work, we just say we *told* you not to do that. It is not the Python
philosophy to try to
Antoine Pitrou pit...@free.fr added the comment:
I agree. Do you think I should just define __lt__ and use
functools.total_ordering decorator?
I had forgotten about functools.total_ordering. Yes, very good idea.
Note that current implementation mimics what is done in C, but I
think
anatoly techtonik techto...@gmail.com added the comment:
About importance to have a maintainable pure libraries and speedups for them.
Believe it or not, but the only reason why Python 2.x did not get RFC 3339
implementation in standard library is that datetime module is in C. I hope
Antoine Pitrou pit...@free.fr added the comment:
Le samedi 26 juin 2010 à 00:50 +, Alexander Belopolsky a écrit :
For io, we find this quite manageable indeed, although it is quite more
complex and quirkier than datetime.
I don't understand how something being more complex and
R. David Murray rdmur...@bitdance.com added the comment:
Alexander and Antoine, you are talking past each other.
Alexander: Antoine was trying to point out that the fact that io is quirky has
not impacted their ability to maintain parallel versions significantly. So if
datetime is less
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I see. I misunderstood AP's although as however, but he probably meant
even though or in spite the fact that.
Antoine, can I count you as +1?
In any case, my threshold for moving this forward is for someone to review
R. David Murray rdmur...@bitdance.com added the comment:
Victor: that was exactly the point of my post that you partially quoted :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7989
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Adding tim_one to the nosy list.
Tim,
It would be great if you could shed some light on the history behind pure
python implementation. Why was it developed in the first place? What was the
reason not to ship it with
Tim Peters tim.pet...@gmail.com added the comment:
It would be great if you could shed
some light on the history behind pure
python implementation. Why was it
developed in the first place?
It was rapid prototyping - design decisions were changing daily, and it goes a
lot faster to change
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Tim, thanks for your prompt reply.
What would be your opinion on adding datetime.py to the main python tree today?
There is momentum behind several features to be added to datetime module and
having easily accessible
Antoine Pitrou pit...@free.fr added the comment:
It is hard for me to judge the significance of maintenance burden, but
others reported that having parallel versions of the io module was
helpful. I believe that with proper support in the regression test
suit, it should be quite manageable.
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
For io, we find this quite manageable indeed, although it is quite more
complex and quirkier than datetime.
I don't understand how something being more complex and quirkier, can make it
more manageable.
While
Tim Peters tim.pet...@gmail.com added the comment:
What would be your opinion on adding
datetime.py to the main python tree
today?
The funny thing is I can't remember why we bothered creating the C version - I
would have been happiest leaving it all in Python.
Provided the test suite
STINNER Victor victor.stin...@haypocalc.com added the comment:
Why do you need a pure Python version of datetime:
- it's easier to work on a new feature first in Python: there are more people
are able to write Python code, than people able to write C code (especially C
code using the Python C
R. David Murray rdmur...@bitdance.com added the comment:
Brett's assertion comes from the decision made at the language summit at the
last pycon. Which does not negate Raymond's assertion that there may be more
important stuff to pythonize. However, Alexander is maintaining datetime, and
if
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
One, we should not blindly pull in the PyPy code
without some core PyPy developer being in on this
You can count me among the PyPy developers.
I concur. Much of PyPy code is written for a restricted subset of
Python instead of
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
If both implementations can exist in the same interpreter, how will they
cooperate?
For example, Time instances created with datetime.py won't pass PyTime_Check().
--
___
Python tracker
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I've been thinking about this feature request and am starting to question
whether it is necessary. Usually we need a pure python version when 1) the
python module is developed first, with the subsequent C code needing to
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Let me just add a story to show how an alternate python implementation may be
useful for users. As I was porting datetime.py to 3.x, I saw many failures
from pickle tests. It was not easy to figure out what was going on
R. David Murray rdmur...@bitdance.com added the comment:
My understanding is that the desire to have pure python versions of standard
library modules is to decouple the standard library from dependency on CPython
as far as practical. Perhaps all existing Python implementations have dealt
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
My understanding is that the desire to have pure
python versions of standard library modules is
to decouple the standard library from dependency
on CPython as far as practical.
That is a bit of a broad brush. I do not
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
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I would like to move this forward. The PyPy implementation at
http://codespeak.net/pypy/dist/pypy/lib/datetime.py
claims to be based on the original CPython datetime implementation from the
time when datetime was a
Marc-Andre Lemburg m...@egenix.com added the comment:
Alexander Belopolsky wrote:
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I would like to move this forward. The PyPy implementation at
http://codespeak.net/pypy/dist/pypy/lib/datetime.py
claims to be
Antoine Pitrou pit...@free.fr added the comment:
Is this still the state of the art? What about parsing overhead?
The io module has three modules:
- io.py just imports everything from _io
- _io is the default C implementation
- _pyio.py must be imported explicitly to get the pure Python
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Thu, Jun 17, 2010 at 10:31 AM, Marc-Andre Lemburg rep...@bugs.python.org
wrote:
..
To avoid the wasted memory and import time, it's better to use:
try:
from _cmodule import *
except ImportError:
from
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
To avoid the wasted memory and import time, it's better to use:
try:
from _cmodule import *
except ImportError:
from _pymodule import *
.. also this makes it harder to prototype things in Python or have mixed
R. David Murray rdmur...@bitdance.com added the comment:
I think we have no standard for this yet, though it has been discussed. If you
can't find a python-dev thread about it, you should probably start a new one.
As one example, heapq does:
try:
from _heapq import *
except
Marc-Andre Lemburg m...@egenix.com added the comment:
Alexander Belopolsky wrote:
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Thu, Jun 17, 2010 at 10:31 AM, Marc-Andre Lemburg rep...@bugs.python.org
wrote:
..
To avoid the wasted memory and import time,
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Thu, Jun 17, 2010 at 10:32 AM, Antoine Pitrou rep...@bugs.python.org wrote:
..
Is there direct regrtest support for this?
You can take a look at test_io, test_memoryio or test_heapq for inspiration.
I looked at
Antoine Pitrou pit...@free.fr added the comment:
I looked at test_io and don't like that approach. It seems to require
subclassing each TestCase twice for C and Python. There is no
mechanism to assure that all tests are replicated that way.
Subclassing /is/ the mechanism :)
Furthermore,
Marc-Andre Lemburg m...@egenix.com added the comment:
Alexander Belopolsky wrote:
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
To avoid the wasted memory and import time, it's better to use:
try:
from _cmodule import *
except ImportError:
from
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
The only alternative is to manually duplicate tests, these leads to very
poor test coverage because of the average developer's laziness (json is
an example).
No, here is another alternative:
== _example.py ==
def
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Porting PyPy implementation to 2.7 was fairly easy. I am posting the patch
which makes PyPy datetime.py pass regression tests when dropped in the trunk.
I expect 3.x port to be uneventful as well. Raising the priority
R. David Murray rdmur...@bitdance.com added the comment:
I don't see how moving the import to setUp is going to avoid having to
explicitly run each set of tests twice, though.
--
___
Python tracker rep...@bugs.python.org
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7989
___
___
Python-bugs-list
Brett Cannon br...@python.org added the comment:
A couple of things about all of this.
One, we should not blindly pull in the PyPy code without some core PyPy
developer being in on this; just common courtesy and I don't think anyone
participating in this discussion is a PyPy developer (but I
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
One, we should not blindly pull in the PyPy code
without some core PyPy developer being in on this
I concur. Much of PyPy code is written for a restricted subset of Python
instead of clean, idiomatic modern Python.
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Also, this should not be marked as high priority. It may be a
personal priority for you, ...
Reverting priority. I thought once an issue is assigned, the priority becomes
the priority that assignee places on the
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
One, we should not blindly pull in the PyPy code
without some core PyPy developer being in on this
I concur. Much of PyPy code is written for a restricted subset of
Python instead of clean, idiomatic modern Python.
Brett Cannon br...@python.org added the comment:
I would simply email their developer mailing list (find it at
http://pypy.org/contact.html) and say that you are willing to work on this.
Maciej and I have discussed this before, so this won't be a total shock to them.
As for Raymond's comment,
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I am attaching datetime-sandbox-pypy.diff, a plain diff between six-year-old
sandbox and pypy versions. (Plain diff is cleaner than unified diff.)
You can see that the differences are trivial. I notice, however that
Brett Cannon br...@python.org added the comment:
I would not worry about the history too much; the code has been forked and
pulling it back in means there is already some history missing. Just do what is
easiest.
--
___
Python tracker
Marc-Andre Lemburg m...@egenix.com added the comment:
Brett Cannon wrote:
Brett Cannon br...@python.org added the comment:
So yes, cPickle/pickle, cStringIO/StringIO, heapq, etc. are all examples of
the approach. One could choose to write the pure Python version first,
profile the
STINNER Victor victor.stin...@haypocalc.com added the comment:
I like the idea of a pure Python implementation of the datetime module, for
different reasons:
- it will become the reference implementation
- other Python interpreters can use it
- it can be used to test another implementation,
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
I like the idea of a pure Python implementation of the datetime module, for
different reasons:
- it will become the reference implementation
-
Marc-Andre Lemburg m...@egenix.com added the comment:
Oops, sorry. Looks like the Roundup email interface changed the ticket
title back to the old one again (I was replying to Brett's comment under the
old title).
--
title: Transition time/datetime C modules to Python - Add pure Python
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Even from pypy perspective, a pure python implementation is not ideal because
it makes it difficult to implement the C API.
--
nosy: +amaury.forgeotdarc
___
Python tracker
anatoly techtonik techto...@gmail.com added the comment:
On Tue, Jun 8, 2010 at 2:06 PM, Amaury Forgeot d'Arc
rep...@bugs.python.org wrote:
Even from pypy perspective, a pure python implementation is not ideal because
it makes it difficult to implement the C API.
C API
must die
a shadow of
88 matches
Mail list logo
