[ python-Bugs-1292634 ] The _ssl build process for 2.3.5 is broken
Bugs item #1292634, was opened at 2005-09-16 15:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1292634&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Cheung (robertcheung) Assigned to: Nobody/Anonymous (nobody) Summary: The _ssl build process for 2.3.5 is broken Initial Comment: I have attempted to build the _ssl library for 2.3.5 and it is broken (see attached output 1). Basically it is complaining that the _ssl.pyd file could not be build because several symbols (GetUserObjectInformation, etc) could not be linked. Those symbols are suppose to be located in User32.[lib|dll]. Appending User32.lib to line 15 of _ssl.mak fixed this problem (see attachment 2). Hopefully this will be helpful for other people that also had build problems with the ssl library. Regards Robert Cheung Attached output 1-- C:\downloads\python\Python-2.3.5\PCbuild>python build_ssl.py Found a working perl at 'C:\Perl\bin\perl.exe' Found an SSL directory at 'C:\downloads\python\openssl-0.9.8' Executing nmake over the ssl makefiles... Building OpenSSL copy nul+ .\crypto\buildinf.h tmp32\buildinf.h nul .\crypto\buildinf.h 1 file(s) copied. cl /nologo ../Modules/_ssl.c C:\downloads\python\openssl-0.9.8/out32/libeay32.lib C:\downloads\python\openssl-0.9.8/out32/ssleay32.lib /Ox /MD /LD /Fox86-temp-release/_ssl\_ssl.obj -I ../Include -I ../PC -I C:\downloads\python\openssl-0.9.8/inc32 /link /out:_ssl.pyd gdi32.lib wsock32.lib /libpath:C:\downloads\p ython\openssl-0.9.8/out32 libeay32.lib ssleay32.lib _ssl.c Creating library _ssl.lib and object _ssl.exp libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _OPENSSL_isservice libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _OPENSSL_isservice libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _OPENSSL_isservice libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _OPENSSL_showfatal _ssl.pyd : fatal error LNK1120: 4 unresolved externals NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. Attachment 2 - _ssl.mak line 15 - LIBS=gdi32.lib wsock32.lib /libpath:$(SSL_LIB_DIR) libeay32.lib ssleay32.lib User32.lib -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1292634&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1242657 ] list(obj) can swallow KeyboardInterrupt
Bugs item #1242657, was opened at 2005-07-22 01:22 Message generated for change (Comment added) made by stevea_zope You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1242657&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Steve Alexander (stevea_zope) Assigned to: Raymond Hettinger (rhettinger) Summary: list(obj) can swallow KeyboardInterrupt Initial Comment: The example below shows that list(f) swallows the KeyboardInterrupt. It swallows any other exception too, such as MemoryError or application-specific ConflictErrors. I think the "get the length of the object" optimisation should catch only AttributeError and TypeError. >>> class F(object): ... def __iter__(self): ... yield 23 ... def __len__(self): ... print "len called. raising Keyboard Interrupt." ... raise KeyboardInterrupt ... >>> f = F() >>> list(f) len called. raising Keyboard Interrupt. [23] -- >Comment By: Steve Alexander (stevea_zope) Date: 2005-09-16 12:02 Message: Logged In: YES user_id=492001 Interestingly, I just saw some code that was causing a problem in the SchoolTool project. It had a __len__ method that used list(self), causing great slowness without this fix, and a RuntimeError "maximum recursion depth exceeded" with this fix. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-21 14:10 Message: Logged In: YES user_id=80475 Okay, fixed in several places. This little fragment occurred in a number of places including code listextend(), map(), zip(), filter(), and PySequence_Tuple(). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1242657&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Bugs item #1112856, was opened at 2005-01-31 00:58
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Initial Comment:
Patch 1079734 "Make cgi.py use email instead of rfc822
or mimetools" seems to have broken the cgi.FieldStorage
in cases where the request is a multipart post (for
instance, when a file upload form field is used).
See the attached test program.
With cgi.py revision <1.83 (python 2.4 for instance) I
get the expected results;
374
FieldStorage(None, None, [FieldStorage('param1', None,
'Value of param1'), FieldStorage('param2', None, 'Value
of param2'), FieldStorage('file', '', ''),
FieldStorage(None, None, '')])
but with cgi.py rev 1.83 (current) I get this:
374
FieldStorage(None, None, [FieldStorage('param1', None,
'')])
Another thing that I observed (which isn't reproduced
by this test program) is that cgi.FieldStorage.__init__
never completes when the fp is a socket-file (and the
request is again a multipart post). It worked fine with
the old cgi.py.
--
>Comment By: Armin Rigo (arigo)
Date: 2005-09-16 11:52
Message:
Logged In: YES
user_id=4771
The problem is still there now (5 months later), so should I go ahead and
revert the cgi.py changes of r1.83? I does break user code out there.
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-04-17 23:39
Message:
Logged In: YES
user_id=693077
I've been playing with using the email parser to do the
whole job of parsing the data, and I think it's too big of a
change. It'd be very hard to ensure API compatibility and
the same behaviour. I think that in the long run, it's the
right thing to do, but I think that the API should change
when that change is made. My recommendation for the time
being is to revert the original patch that I made.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-02-08 21:40
Message:
Logged In: YES
user_id=129426
I've added a test that shows the 'freezing' problem I talked
about.
Start the server.py, it will listen on port 9000. Open the
post.html in your web browser, enter some form data, and
submit the form.
It will POST to the server.py and if you started that one
with cvs-python (2.5a0) it will freeze on the marked line.
If you start server.py with Python 2.4, it will work fine.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-02-06 22:58
Message:
Logged In: YES
user_id=129426
Yes, I'll try to make a test case for that within the next
few days.
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-02-04 23:02
Message:
Logged In: YES
user_id=693077
Irmen, can you try to create a test case where the
cgi.FieldStorage never completes, so I can make sure that
any fix I come up with resolves it?
I will try to put together an implementation where the email
parser parses the whole multipart message.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-02-04 22:06
Message:
Logged In: YES
user_id=129426
Johannes: while your patch makes my cgibug.py test case run
fine, it has 2 problems:
1- it runs much slower than the python2.4 code (probably
because of the reading back thing Josh is talking about);
2- it still doesn't fix the second problem that I observed:
cgi.FieldStorage never completes when fp is a socket. I
don't have a separate test case for this yet, sorry.
So Josh: perhaps your idea doesn't have these 2 problems?
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-02-04 15:45
Message:
Logged In: YES
user_id=693077
Johannes, your patch looks fine to me. It would be nice if
we didn't have to keep reading back each part from the
parsed message, though.
I had an idea for another approach. Use email to parse the
MIME message fully, then convert it to FieldStorage fields.
Parsing could go something like:
== CODE ==
from email.FeedParser import FeedParser
parser = FeedParser()
# Create bogus content-type header...
parser.feed('Content-type: %s ; boundary=%s \r\n\r\n' %
(self.type, self.innerboundary))
parser.feed(self.fp.read())
message = parser.close()
# Then take parsed message and convert to FieldStorage fields
== END CODE ==
T
[ python-Bugs-1289136 ] distutils extension library path bug on cygwin
Bugs item #1289136, was opened at 2005-09-12 14:04
Message generated for change (Comment added) made by jlt63
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289136&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Whitley (jwhitley)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils extension library path bug on cygwin
Initial Comment:
A while back I reported a problem on the Cygwin mailing
list where all python extension packages would fail
"python setup.py install" at the link step due to a
mangled lib dir (-L) option. distutils was producing a
link line with "-L.", instead of the desired
"-L/usr/lib/python2.4/config". I've finally rooted out
the cause of this problem.
The relevant code is the if-block starting at line 188 of:
/usr/lib/python2.4/distutils/command/build_ext.py
I've reproduced that block here for clarity of
discussion (indentation truncated for redability)
if sys.platform[:6] == 'cygwin' or sys.platform[:6]
== 'atheos':
if string.find(sys.executable, sys.exec_prefix)
!= -1:
# building third party extensions
self.library_dirs.append(os.path.join(sys.prefix, "lib",
"python" +
get_python_version(),
"config"))
else:
# building python standard extensions
self.library_dirs.append('.')
The test "string.find(...) != -1" attempts to test
whether "/usr" appears in the full executable name.
This incorrectly fails in the case that /bin is in the
user's path before /usr/bin. (i.e.
string.find("/bin/python","/usr") == -1) Note that a
vagary of Cygwin is that /usr/bin is a Cygwin mount to
/bin.
The user-side workaround is to ensure that /usr/bin
appears in your path before /bin. It looks like a new
and improved Cygwin special case test is needed to fix
this problem; I'm not sure offhand what the best case
would be. Perhaps an outright test as follows would work:
sys.executable.startswith(sys.exec_prefix) or
sys.executable.startswith(os.sep+"bin")
--
>Comment By: Jason Tishler (jlt63)
Date: 2005-09-16 04:04
Message:
Logged In: YES
user_id=86216
John,
Thanks for the excellent analysis!
All,
Unfortunately, I'm not sure what is the best way to solve this
problem. Does anyone have any suggestions? Thanks.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289136&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Bugs item #1112856, was opened at 2005-01-31 01:58
Message generated for change (Comment added) made by irmen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Initial Comment:
Patch 1079734 "Make cgi.py use email instead of rfc822
or mimetools" seems to have broken the cgi.FieldStorage
in cases where the request is a multipart post (for
instance, when a file upload form field is used).
See the attached test program.
With cgi.py revision <1.83 (python 2.4 for instance) I
get the expected results;
374
FieldStorage(None, None, [FieldStorage('param1', None,
'Value of param1'), FieldStorage('param2', None, 'Value
of param2'), FieldStorage('file', '', ''),
FieldStorage(None, None, '')])
but with cgi.py rev 1.83 (current) I get this:
374
FieldStorage(None, None, [FieldStorage('param1', None,
'')])
Another thing that I observed (which isn't reproduced
by this test program) is that cgi.FieldStorage.__init__
never completes when the fp is a socket-file (and the
request is again a multipart post). It worked fine with
the old cgi.py.
--
>Comment By: Irmen de Jong (irmen)
Date: 2005-09-16 15:40
Message:
Logged In: YES
user_id=129426
I vote for revert, so that my code may run again on Python 2.5.
Also see Josh's comment , with which I agree.
--
Comment By: Armin Rigo (arigo)
Date: 2005-09-16 13:52
Message:
Logged In: YES
user_id=4771
The problem is still there now (5 months later), so should I go ahead and
revert the cgi.py changes of r1.83? I does break user code out there.
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-04-18 01:39
Message:
Logged In: YES
user_id=693077
I've been playing with using the email parser to do the
whole job of parsing the data, and I think it's too big of a
change. It'd be very hard to ensure API compatibility and
the same behaviour. I think that in the long run, it's the
right thing to do, but I think that the API should change
when that change is made. My recommendation for the time
being is to revert the original patch that I made.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-02-08 22:40
Message:
Logged In: YES
user_id=129426
I've added a test that shows the 'freezing' problem I talked
about.
Start the server.py, it will listen on port 9000. Open the
post.html in your web browser, enter some form data, and
submit the form.
It will POST to the server.py and if you started that one
with cvs-python (2.5a0) it will freeze on the marked line.
If you start server.py with Python 2.4, it will work fine.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-02-06 23:58
Message:
Logged In: YES
user_id=129426
Yes, I'll try to make a test case for that within the next
few days.
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-02-05 00:02
Message:
Logged In: YES
user_id=693077
Irmen, can you try to create a test case where the
cgi.FieldStorage never completes, so I can make sure that
any fix I come up with resolves it?
I will try to put together an implementation where the email
parser parses the whole multipart message.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-02-04 23:06
Message:
Logged In: YES
user_id=129426
Johannes: while your patch makes my cgibug.py test case run
fine, it has 2 problems:
1- it runs much slower than the python2.4 code (probably
because of the reading back thing Josh is talking about);
2- it still doesn't fix the second problem that I observed:
cgi.FieldStorage never completes when fp is a socket. I
don't have a separate test case for this yet, sorry.
So Josh: perhaps your idea doesn't have these 2 problems?
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-02-04 16:45
Message:
Logged In: YES
user_id=693077
Johannes, your patch looks fine to me. It would be nice if
we didn't have to keep reading back each part from the
parsed message, though.
I had an idea for another approach. Use email to parse the
MIME message fully, then convert it to FieldStorage fields.
Parsing could go something like:
== CODE ==
from email.FeedParser import FeedParser
[ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Bugs item #1112856, was opened at 2005-01-30 16:58
Message generated for change (Comment added) made by joshhoyt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Initial Comment:
Patch 1079734 "Make cgi.py use email instead of rfc822
or mimetools" seems to have broken the cgi.FieldStorage
in cases where the request is a multipart post (for
instance, when a file upload form field is used).
See the attached test program.
With cgi.py revision <1.83 (python 2.4 for instance) I
get the expected results;
374
FieldStorage(None, None, [FieldStorage('param1', None,
'Value of param1'), FieldStorage('param2', None, 'Value
of param2'), FieldStorage('file', '', ''),
FieldStorage(None, None, '')])
but with cgi.py rev 1.83 (current) I get this:
374
FieldStorage(None, None, [FieldStorage('param1', None,
'')])
Another thing that I observed (which isn't reproduced
by this test program) is that cgi.FieldStorage.__init__
never completes when the fp is a socket-file (and the
request is again a multipart post). It worked fine with
the old cgi.py.
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-09-16 08:58
Message:
Logged In: YES
user_id=693077
Yes, please revert the patch.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-09-16 06:40
Message:
Logged In: YES
user_id=129426
I vote for revert, so that my code may run again on Python 2.5.
Also see Josh's comment , with which I agree.
--
Comment By: Armin Rigo (arigo)
Date: 2005-09-16 04:52
Message:
Logged In: YES
user_id=4771
The problem is still there now (5 months later), so should I go ahead and
revert the cgi.py changes of r1.83? I does break user code out there.
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-04-17 16:39
Message:
Logged In: YES
user_id=693077
I've been playing with using the email parser to do the
whole job of parsing the data, and I think it's too big of a
change. It'd be very hard to ensure API compatibility and
the same behaviour. I think that in the long run, it's the
right thing to do, but I think that the API should change
when that change is made. My recommendation for the time
being is to revert the original patch that I made.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-02-08 13:40
Message:
Logged In: YES
user_id=129426
I've added a test that shows the 'freezing' problem I talked
about.
Start the server.py, it will listen on port 9000. Open the
post.html in your web browser, enter some form data, and
submit the form.
It will POST to the server.py and if you started that one
with cvs-python (2.5a0) it will freeze on the marked line.
If you start server.py with Python 2.4, it will work fine.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-02-06 14:58
Message:
Logged In: YES
user_id=129426
Yes, I'll try to make a test case for that within the next
few days.
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-02-04 15:02
Message:
Logged In: YES
user_id=693077
Irmen, can you try to create a test case where the
cgi.FieldStorage never completes, so I can make sure that
any fix I come up with resolves it?
I will try to put together an implementation where the email
parser parses the whole multipart message.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-02-04 14:06
Message:
Logged In: YES
user_id=129426
Johannes: while your patch makes my cgibug.py test case run
fine, it has 2 problems:
1- it runs much slower than the python2.4 code (probably
because of the reading back thing Josh is talking about);
2- it still doesn't fix the second problem that I observed:
cgi.FieldStorage never completes when fp is a socket. I
don't have a separate test case for this yet, sorry.
So Josh: perhaps your idea doesn't have these 2 problems?
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-02-04 07:45
Message:
Logged In: YES
user_id=693077
Johannes, your patch looks fine to me. It would be nice if
we didn't have to keep reading back each part from the
parsed message, though.
I
[ python-Bugs-1289118 ] timedelta multiply and divide by floating point
Bugs item #1289118, was opened at 2005-09-12 16:41 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: timedelta multiply and divide by floating point Initial Comment: In python 2.4.1, the datetime.timedelta type allows for the multiplication and division by integers. However, it raises a TypeError for multiplication or division by floating point numbers. This is a counterintutive restriction and I can't think of any good reason for it. For example: >>> import datetime >>> datetime.timedelta(minutes=5)/2 datetime.timedelta(0, 150) >>> datetime.timedelta(minutes=5)*0.5 Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float' -- >Comment By: Skip Montanaro (montanaro) Date: 2005-09-16 20:48 Message: Logged In: YES user_id=44345 >> Thus, I have to either write my own special functions, or convert >> the timedelta objects to integers first (then convert them back >> afterwards). How about adding tolong() that returns the number of microseconds in the timedelta and fromlong() that accepts a long representing microseconds and returns a timedelta object? That way the timedelta object does a reasonably simple thing and the user is still responsible for overflow the normal arithmetic stuff. You can do any sort of arithmetic operations on the long (including converting to other numeric types) with all the attendant caveats, then convert back to a timedelta object at the end. -- Comment By: Daniel Stutzbach (agthorr) Date: 2005-09-15 17:00 Message: Logged In: YES user_id=6324 Let me elaborate on the use-case where I originally ran into this. I'm conducting a series of observation experiments where I measure the duration of an event. I then want to do various statistical analysis such as computing the mean, median, etc. Originally, I tried using standard functions such as lmean from the stats.py package. However, these sorts of functions divide by a float at the end, causing them to fail on timedelta objects. Thus, I have to either write my own special functions, or convert the timedelta objects to integers first (then convert them back afterwards). Basically, I want timedelta objects to look and act like fixed-point arithmetic objects so that I can reuse other functions on them that were originally developed to operate on floats. More importantly, I'd rather not have to maintain two different versions of the functions to deal with different types. For implementation, why not multiply the float times .day, .seconds, and .microseconds separately, then propagate and fraction parts into the next smallest group (e.g., 0.5 days becomes 24*60*60*0.5 seconds). I agree it'd be possible to lose information with the wrong sequence of operations, but that's always the case when using floating point numbers. In other words, that, too, is what I would expect from the timedelta implementation. -- Comment By: Tim Peters (tim_one) Date: 2005-09-15 16:04 Message: Logged In: YES user_id=31435 timedelta arithmetic is 100% portable now, and wholly explainable in terms of universally understood integer arithmetic. Throw floats into it, and that's lost. That said, I don't have a strong objection to complicating the implementation if there _are_ strong use cases. The OP's example isn't "a use case": it's not worth anything to let someone multiply a timedelta by 0.5 instead of dividing by 2. I don't have a use case to offer in its place (never felt a need here). If someone wants to work on it, note that a timedelta can contain more than 53 bits of information, so, e.g., trying to represent a timedelta as an IEEE double-precision number of microseconds can lose information. This makes a high- qualty "computed as if to infinite precision with one rounding at the end" implementation of mixed datetime/float arithmetic tricky to do right. -- Comment By: Michael Chermside (mcherm) Date: 2005-09-15 11:03 Message: Logged In: YES user_id=99874 I, too, would like to know what Tim thinks, but for what it's worth (not much) I find Daniel's point fairly convincing... multiplication by floats is an operation that makes sense, has only one possible obvious meaning, and is not particularly likely to c
