On 11/12/06, Anthony Baxter wrote:

On Sunday 12 November 2006 22:09, Fredrik Lundh wrote:

...

Martin v. Löwis wrote:

...

Patch #1067760 deals with passing of float values to file.seek; the original version tries to fix the current implementation by converting floats to long long, rather than plain C long (thus supporting files larger than 2GiB).

...

...

b) if not, should Python 2.6 just deprecate such usage, or outright reject it?

Python 2.5 silently accepts (and truncates) a float that's within range, so a warning sounds like the right thing to do for 2.6. note that read

I agree that a warning seems best. If someone (for whatever reason) is flinging floats around where they actually meant to have ints, going straight to an error from silently truncating and accepting it seems a little bit harsh.

Right. There seem to be people who believe that 1e6 is an int. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On 11/13/06, Steve Holden wrote:

In which case an immediate transition to error status would seem to offer a way of providing an effective education. Deprecation may well be the best way to go for customer-friendliness, but anyone who believes 1e6 is an int should be hit with a stick.

Right, but what about those people who just didn't examine it? I consider myself a pretty good programmer, and was surprised by Guido's remark. A little quick self-education later, I understood. Still I find the implication that anyone using 1e6 for an integer should be (have all their users) beaten absurd in the context of backwards compatibility. Especially when they were using one of the less apparent floats in a place that accepted floats. Perhaps it would be a fine change for py3k.

Next thing you know some damned fool is going to suggest that 1e6 gets parsed into a long integer.

I can guess why it isn't, but it seems more a matter of ease than a matter of doing what's right. I had expected it to be an int because I thought of 1e6 as a shorthand for (1 * 10 ** 6), which is an int. 1e-6 would be (1 * 10 ** -6) which is a float. 1.0e6 would be (1.0 * 10 ** 6) which would also be a float. Clearly instead the e wins out as the format specifier. I'm not going to argue for it to be turned into an int, or even suggest it, after all compatibility with obscure realities of C is important. I'm just going to say that it makes more sense to me than your reaction indicates. -- Michael Urman http://www.tortall.net/mu/blog

skip@pobox.com wrote:

>> Right. There seem to be people who believe that 1e6 is an int. ... Steve> Next thing you know some damned fool is going to suggest that 1e6 Steve> gets parsed into a long integer.

Maybe in Py3k a decimal point should be required in floats using exponential notation - 1.e6 or 1.0e6 - with suitable deprecation warnings in 2.6+ about 1e6.

My remarks weren't entirely tongue in cheek. Once you have long integers seamlessly integrated there is a case to be made that if the mantissa is integral then the literal should have an integral value. Then, of course, we'll get people complaining about the length of time it takes to compute expressions containing huge integers. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden