I could not find another example of this via internet searches, so here
it is... I am wondering if this is a python bug or otherwise. The
first example of this happened in a larger program of mine, and the
traceback reports the problem at the start of a "for" loop (making no
sense), but I cannot easily include the full code and instructions here.
So I wrote a small test program containing the offending code, and in
this case the traceback reports the problem happening "during garbage
collection." So in either case, there's something funny going on here.
The call the causes it is "os.utime()". Note that the trigger is a
rediculous timezone value that causes an overflow. But the surprize is
that the traceback does not report its happening in utime.
If anyone has a clue what's really happening, I'd love to know.
Anyway, here is the sample program:
-------------
import os
import rfc822
fp = file("foo_test_file", "w")
fp.write("hi")
fp.close()
tt = rfc822.parsedate_tz("Fri, 01 Jul 2005 05:04:23 -4000000000000")
t = rfc822.mktime_tz(tt)
print tt
print t
os.utime("foo_test_file", (t, t))
-------------
Running this gives:
(2005, 7, 1, 5, 4, 23, 0, 0, 0, -144000000000000L)
1.44001120194e+14
Exception exceptions.OverflowError: 'long int too large to convert to
int' in 'garbage collection' ignored
Fatal Python error: unexpected exception during garbage collection
I am running Fedora Core 3, and it is Python version 2.3.4 [GCC 3.4.2
20041017 (Red Hat 3.4.2-6.fc3)].
Thanks, Joe 4 1607
Joe Peterson wrote: I could not find another example of this via internet searches, so here it is... I am wondering if this is a python bug or otherwise. The first example of this happened in a larger program of mine, and the traceback reports the problem at the start of a "for" loop (making no sense), but I cannot easily include the full code and instructions here.
So I wrote a small test program containing the offending code, and in this case the traceback reports the problem happening "during garbage collection." So in either case, there's something funny going on here. The call the causes it is "os.utime()". Note that the trigger is a rediculous timezone value that causes an overflow. But the surprize is that the traceback does not report its happening in utime.
I came up with a simpler testcase. Strangely, the exception occurs in
the statement *following* the os.utime() call: import os, sys os.utime("foo_test_file", (0, float(sys.maxint+1))) print "hi"
OverflowError: long int too large to convert to int
Looks like a bug. You should report it on the SourceForge tracker.
--
Michael Hoffman
"Michael Hoffman" <ca*******@mh391.invalid> wrote in message
news:da**********@gemini.csx.cam.ac.uk... I came up with a simpler testcase. Strangely, the exception occurs in the statement *following* the os.utime() call:
import os, sys os.utime("foo_test_file", (0, float(sys.maxint+1))) print "hi" OverflowError: long int too large to convert to int
Looks like a bug. You should report it on the SourceForge tracker.
Please include this simpler test, which make clear that bug not just in
deprecated (I believe) rfc module. Also note:
Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information. import os, sys os.utime("foo_test_file", (0, float(sys.maxint+1)))
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: utime() arg 2 must be a tuple (atime, mtime)
which is quite sane. So maybe bug was introduced in 2.3 which you were
running.
Terry Reedy wrote: os.utime("foo_test_file", (0, float(sys.maxint+1)))
Traceback (most recent call last): File*"<stdin>",*line*1,*in*? TypeError: utime() arg 2 must be a tuple (atime, mtime)
which is quite sane.**So*maybe*bug*was*introduced*in*2.3*which*yo u*were running.
But arg 2 *is* a tuple. So a least the error message is wrong, too.
Peter
Yep, my thinking too. Well, maybe it's all related to the same bug
somehow. OK, I submitted a bug report, and I included a slight
modification of the test case you guys suggested:
----------------
import sys
import os
t = 2147483648L
os.utime("foo_test_file", (t, t))
print "hi"
----------------
This way, there's no "float" call, simply an asignment of a long int...
Thanks, Joe
Peter Otten wrote: Terry Reedy wrote:
>os.utime("foo_test_file", (0, float(sys.maxint+1)))
Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: utime() arg 2 must be a tuple (atime, mtime)
which is quite sane. So maybe bug was introduced in 2.3 which you were running.
But arg 2 *is* a tuple. So a least the error message is wrong, too.
Peter This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Piotr B. |
last post by:
Hello,
I use MingGW g++ 3.2.3 on Windows 2000/AMD Athlon XP.
I tried to output a "long double" variable using stdio printf().
I've tried various %formats (%llf, %Lf etc.), but none of them...
|
by: bq |
last post by:
Hello,
Two questions related to floating point support:
What C compilers for the wintel (MS Windows + x86) platform are C99
compliant as far as <math.h> and <tgmath.h> are concerned?
What...
|
by: ondekoza |
last post by:
Hello,
I need to convert the string "FFFFFFFF" to a long. To convert this
string I tried the following:
>>> 0xffffffff
-1
>>> 0xffffffffL
4294967295L
OK, this is what I want, so I tried
|
by: Zero |
last post by:
Hi everybody,
i want to write a small program, which shows me the biggest and
smallest number in dependance of the data type.
For int the command could be:
...
|
by: ext |
last post by:
"A "long" in C is an "int" in C#."
Does this mean that whenever passing a parameter to a C function which
expects a long type, the variable on C# side should be declared as int type?
What if...
|
by: DolphinDB |
last post by:
Tired of spending countless mintues downsampling your data? Look no further!
In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: jfyes |
last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
|
by: PapaRatzi |
last post by:
Hello,
I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Defcon1945 |
last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
| |