Re: [Python-Dev] Patches: 1 for the price of 10.
- 1067760 -- float--long conversion on fileobj.seek calls, rather than
- float--int. Permits larger floats (2.0**62) to match large
- int (2**62) arguments. rhettinger marked as won't fix in
- the original bug report; this seems like a clean solution,
- tho. Recommend apply.
-
- Wouldn't this cause subtle errors when the float - long conversion is
- no longer precise? Or is this a non issue because it could only happen
- when seeking on impossibly large files?
When would the float -- long conversion not be precise? The docs
say PyLong_FromDouble takes the integer part, so it's like doing
a floor(), yes?
The current behavior is to convert directly from float to int, even
though seek() can take longs as an argument. Thus 2.0**31 works,
2**31 works, 2**62 works, but 2.0**62 doesn't. This seems mildly
inconsistent and prompted the guy to submit a bug report, and then
a patch.
The patch (with a bit more code context) is:
--
if (!PyArg_ParseTuple(args, O|i:seek, offobj, whence))
return NULL;
#if !defined(HAVE_LARGEFILE_SUPPORT)
offset = PyInt_AsLong(offobj);
#else
+ if(PyFloat_Check(offobj)) {
+ offobj = PyLong_FromDouble(PyFloat_AsDouble(offobj));
+ }
offset = PyLong_Check(offobj) ?
PyLong_AsLongLong(offobj) : PyInt_AsLong(offobj);
#endif
--
so the issue only comes into play with large file support.
Heh, and I just noticed that PyLong_FromDouble returns a new reference,
so this is a memory leak, I believe. Whps. I'll fix that.
cheers,
--titus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patches: 1 for the price of 10.
- Apparently file.seek doesn't have this DeprecationWarning though..
- Strange, that.
-f.seek(3.6)
-f.tell()
- 3L
-
- That's a bug. Who'll fix it?
Added:
+ if (PyFloat_Check(offobj))
+ PyErr_Warn(PyExc_DeprecationWarning,
+integer argument expected, got float );
see attached diff. I also attached it to the patch at SourceForge,
with a comment, just to keep the record straight.
The DeprecationWarning wasn't given because a manual PyObject --
int/long conversion was being done, rather than the usual conversion
implicit in ParseTuple.
Regression tests run w/o problem on RH 9.0/i386. Now you get the
correct behavior:
--
f = open('/dev/zero')
f.seek(5)
f.tell()
5L
f.seek(5.2)
__main__:1: DeprecationWarning: integer argument expected, got float
f.tell()
5L
--
This seems like a reasonable resolution to patch #1067760, to me...
cheers,
--titus
? Objects/.fileobject.c.swp
Index: Objects/fileobject.c
===
RCS file: /cvsroot/python/python/dist/src/Objects/fileobject.c,v
retrieving revision 2.193
diff -c -c -r2.193 fileobject.c
*** Objects/fileobject.c7 Nov 2004 14:15:28 - 2.193
--- Objects/fileobject.c23 Dec 2004 08:19:20 -
***
*** 462,467
--- 462,472
whence = 0;
if (!PyArg_ParseTuple(args, O|i:seek, offobj, whence))
return NULL;
+
+ if (PyFloat_Check(offobj))
+ PyErr_Warn(PyExc_DeprecationWarning,
+integer argument expected, got float );
+
#if !defined(HAVE_LARGEFILE_SUPPORT)
offset = PyInt_AsLong(offobj);
#else
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patches: 1 for the price of 10.
Titus Brown [EMAIL PROTECTED] writes: - Apparently file.seek doesn't have this DeprecationWarning though.. - Strange, that. -f.seek(3.6) -f.tell() - 3L - - That's a bug. Who'll fix it? Added: + if (PyFloat_Check(offobj)) + PyErr_Warn(PyExc_DeprecationWarning, +integer argument expected, got float ); see attached diff. I also attached it to the patch at SourceForge, with a comment, just to keep the record straight. You should check the return value of PyErr_Warn in case the user passed -Werror on the command line. This seems like a reasonable resolution to patch #1067760, to me... I guess I could look at that -- but when I'm not on dialup at my parents' house... Cheers, mwh -- I love the way Microsoft follows standards. In much the same manner that fish follow migrating caribou. -- Paul Tomblin -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patches: 1 for the price of 10.
Titus Brown [EMAIL PROTECTED] wrote: - 1067760 -- float--long conversion on fileobj.seek calls, rather than - float--int. Permits larger floats (2.0**62) to match large - int (2**62) arguments. rhettinger marked as won't fix in - the original bug report; this seems like a clean solution, - tho. Recommend apply. - - Wouldn't this cause subtle errors when the float - long conversion is - no longer precise? Or is this a non issue because it could only happen - when seeking on impossibly large files? When would the float -- long conversion not be precise? The docs say PyLong_FromDouble takes the integer part, so it's like doing a floor(), yes? Precision. 2.0**52 4503599627370496.0 2.0**52+1 4503599627370497.0 2.0**53 9007199254740992.0 2.0**53+1 9007199254740992.0 Anything above float(2**53-1) (one must be careful about the order of float conversions) are basically useless for offsets into files. The current behavior is to convert directly from float to int, even though seek() can take longs as an argument. Thus 2.0**31 works, 2**31 works, 2**62 works, but 2.0**62 doesn't. This seems mildly inconsistent and prompted the guy to submit a bug report, and then a patch. works and doesn't work aren't precise. doesn't raise an exception and does raise an exception are precise. Note the above float precision precision example about why even non-exceptions may not work. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patches: 1 for the price of 10.
Jeremy Hylton wrote: I got started on these this morning, will likely finish them tomorrow. It would be perverse to apply your patch last, wouldn't it? It turns out that Titus' patch might be more involved than he thought it would be. In any case, the review itself is a highly appreciated contribution. In the hope that this progress can trigger more contributions like this, I'll happily reduce the requirements to 5 reviews. Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patches: 1 for the price of 10.
Martin v. Löwis wrote: Jeremy Hylton wrote: I got started on these this morning, will likely finish them tomorrow. It would be perverse to apply your patch last, wouldn't it? It turns out that Titus' patch might be more involved than he thought it would be. In any case, the review itself is a highly appreciated contribution. In the hope that this progress can trigger more contributions like this, I'll happily reduce the requirements to 5 reviews. And to help this along I am willing to officially toss my hat into the fray by being another person who will review a patch if someone does 5 reviews (sans anything that doesn't work on OS X, which leaves out Tkinter). -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patches: 1 for the price of 10.
- Jeremy Hylton wrote: - I got started on these this morning, will likely finish them tomorrow. - It would be perverse to apply your patch last, wouldn't it? - - It turns out that Titus' patch might be more involved than he thought - it would be. *shrug* that's life ;). I stole my patch from the other HTMLParser thought that would be sufficient; now I'll have to fix both! - In any case, the review itself is a highly appreciated contribution. It was very educational; just wish I could remember to always submit context diffs! sigh The only patch that I think deserves some actual discussion - here or on c.l.p, not sure which -- is patch 755660, which deals with HTMLParser.HTMLParser. The goal of the original submitter was to allow subclasses of HTMLParser deal with bad HTML in a more robust way; essentially this comes down to allowing returns from self.error() calls. I have now come across the same problem in my work with PBP (pbp.berlios.de): it turns out that many Web pages (such as the SourceForge mailman admindb page...) contain errors that cause HTMLParser to raise an exception. It's simply not possible to reliably change this behavior within either htmllib.HTMLParser or HTMLParser.HTMLParser as they're currently written. This is a big problem for people basing packages on either HTMLParser class. An additional problem is that both HTMLParser.HTMLParser and htmllib.HTMLParser are based on other classes that call self.error(), so those base classes would have to altered to fit the new behavior. What I proposed doing in my comment on patch 755660 was changing HTMLParser.HTMLParser (and its base class markupbase, too) to call _fail() when a hard failure was called for, and otherwise to call error() and proceed parsing on an as-best-possible basis. This wouldn't change the *behavior* of the existing code, but would allow for it to be overridden when necessary. Right now the error() call is undocumented and so it's probably ok to change what happens upon return. As is it can leave the parser in a borked state upon return, and that's the behavior I propose to fix. I'd of course be willing to do the work submit the more involved patch. Your opinions are not only welcome but (as I understand it) necessary ;). cheers, --titus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patches: 1 for the price of 10.
1067760 -- float--long conversion on fileobj.seek calls, rather than float--int. Permits larger floats (2.0**62) to match large int (2**62) arguments. rhettinger marked as won't fix in the original bug report; this seems like a clean solution, tho. Recommend apply. Wouldn't this cause subtle errors when the float - long conversion is no longer precise? Or is this a non issue because it could only happen when seeking on impossibly large files? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patches: 1 for the price of 10.
On Dec 23, 2004, at 12:36 AM, Timothy Fitz wrote: 1067760 -- float--long conversion on fileobj.seek calls, rather than float--int. Permits larger floats (2.0**62) to match large int (2**62) arguments. rhettinger marked as won't fix in the original bug report; this seems like a clean solution, tho. Recommend apply. Wouldn't this cause subtle errors when the float - long conversion is no longer precise? Or is this a non issue because it could only happen when seeking on impossibly large files? I think that Raymond marked as won't fix because automatic float - integer conversion has been deprecated since Python 2.3.0 (if not earlier), for exactly the reason you state. It's dumb. range(2.7) __main__:1: DeprecationWarning: integer argument expected, got float [0, 1] Apparently file.seek doesn't have this DeprecationWarning though.. Strange, that. f.seek(3.6) f.tell() 3L -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patches: 1 for the price of 10.
Apparently file.seek doesn't have this DeprecationWarning though.. Strange, that. f.seek(3.6) f.tell() 3L That's a bug. Who'll fix it? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
