[Python-bugs-list] [ python-Bugs-422177 ] Results from .pyc differs from .py
noreply@sourceforge.net
noreply@sourceforge.net
Tue, 08 May 2001 01:06:42 -0700
Bugs item #422177, was updated on 2001-05-07 18:09
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422177&group_id=5470
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Results from .pyc differs from .py
Initial Comment:
Guido, the following is from c.l.py. It *seems* to be
due to marshal using damagingly low precision for
float->string conversion. If you don't object to my
fixing it, assign this back to me. But I'll still be
baffled by why the .py result differs from the .pyc
result (which I reproduced under current CVS, under
Windows):
-----Original Message-----
From: python-list-admin@python.org
On Behalf Of Scott Ransom
Sent: Monday, May 07, 2001 4:27 PM
To: python-list@python.org
Cc: Scott Ransom
Subject: Variables different between .py and .pyc
Hello,
I'm running Python 2.0 on Linux and seem to have found
a strange problem when importing floating point
variables defined in modules. I have not
tried this in Python 2.1 so I don't know if the
problem exists there as well.
Here is a simple module (vars.py):
PI = 3.14159265358979324
TWOPI = 6.28318530717958648
When I import this and check the variable values here
is what I get:
presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535897931, 6.2831853071795862)
All is well, so far. Now, if I try again (and this
time the interpreter loads from the newly created
vars.pyc file):
presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535900001, 6.2831853071800001)
My variables are truncated at ~12 decimal points of
precision.
Removing the .pyc file makes things "better" again...
presto:~$ rm vars.pyc
presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535897931, 6.2831853071795862)
...
----------------------------------------------------------------------
>Comment By: Tim Peters (tim_one)
Date: 2001-05-08 01:06
Message:
Logged In: YES
user_id=31435
Quoting a msg of mine to c.l.py that may clarify things a
bit:
[Aahz Maruch, on a proposed change to make .pyc/.pyo files
store repr(float) instead of str(float)]
> Ouch. This is the kind of situation where I was thinking
> that a distinction between "bugfix release"
> and "maintenance release" might be useful. OTOH, it's
> hard to imagine a case where fixing this would make
> things worse.... I mean, really, what could this break?
Perhaps you have no experience with floating-point code
<2/3 wink>? Over the years I've spent a good (distributed)
half year of my life tracking down gross problems in
numerically naive algorithms triggered by measly 1-bit
differences. This is a much bigger change than that. Even
a good algorithm will return *different* results, and of
course some people will scream "different" == "broken".
You can't fix *any* bug that changes a result without
somebody feeling abused.
Trivial:
CONST = 0.0054794520547945206
i = int(CONST * 365)
The difference between current .pyc precision and
proposed .pyc precision there is the difference between
i==1 and i==2. Can you imagine why changing an integer
could break something?
Maybe this is more obvious (although it's really the same
thing):
x = 9007199254740992.0
print long(x)
Stick that in a module and import it. The first time you
import it, it should print
9007199254740992
Which isn't surprising -- the number happens to be exactly
2.**53. Import it a second time and it will print
something closer to
9007199254740000
If people have been getting bad numeric approximations out
of their float literals in Python code for 10 years without
knowing it, they've also been fiddling their algorithms to
compensate for the "mysterious problems" they haven't
tracked down. Change what the literals denote, and the
algorithmic compensations are suddenly wrong too.
It's a mess.
nevertheless-it's-clearly-broken-and-there's-only-one-
way-to-fix-it-ly y'rs - tim
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-05-07 21:05
Message:
Logged In: YES
user_id=31435
I'm attaching a patch so people can try the fix x-
platform. You need a current CVS Python (one with
test/double_const.py) first.
If you apply *just* the test_import.py part of this patch,
then I expect test_import to fail if and only if
double_const.pyc exists.
After the whole patch, I expect test_import never to fail.
But x-platform FP stuff is tricky, so I'd like a little x-
plat pre-testing before risking a checkin. Works fine
under Windows, of course.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422177&group_id=5470