[Python-Dev] Website documentation - link to descriptor information
I just spent 10 minutes hunting through the Python website for this link: http://www.python.org/doc/newstyle.html I knew it was there somewhere, I just couldn't find the darn thing. It turns out the major mistake I made was to start from "docs.python.org" instead of "www.python.org/doc". Would it be possible for the "New-style classes" link to be added to the sidebar menu for the individual version's documentation pages? Or else given its own link on the Topic Guides page? Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ 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.
-> > 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
[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.
-> > 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
[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.
Titus Brown <[EMAIL PROTECTED]> writes: > -> > 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? When the float is so large that it is the closest approximation to more than one integer? (i.e. larger than 2**53 for 754 doubles). Cheers, mwh -- #ifndef P_tmpdir printf( "Go buy a better computer" ); exit( ETHESKYISFALLINGANDIWANTMYMAMA ); -- Dimitri Maziuk on writing secure code, asr ___ 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.
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 [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.
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 [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] Website documentation - link to descriptor information
> It turns out the major mistake I made was to start from "docs.python.org" > instead of "www.python.org/doc". If you ask me that wasn't your mistake but the mistake of whoever decided to create a subdomain for docs (or for anything else). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
[Python-Dev] PyCon Registration Opens Today!
Dear Python User: Following my last message, I am pleased to be able to announce that you can register for PyCon DC 2005 on the web at http://www.python.org/pycon/2005/register.html starting at 1700 EST today (December 23). Thanks to George Belotsky of Open Light Software for assistance in preparing the credit card processing software. As always, further information about PyCon is available in the usual places: http://www.pycon.org/ http://www.python.org/pycon/ I look forward to meeting you at PyCON DC 2005. In the meantime please let me offer my best wishes for a happy and peaceful holiday season. regards Steve Holden Chairman, PyCON DC 2005 -- PyCon DC 2005: The third Python Community Conference http://www.pycon.org/ http://www.python.org/pycon/ The scoop on Python implementations and applications ___ 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
[Python-Dev] Build extensions for windows python 2.4 what are the compiler rules?
I see that, as expected, windows python 2.4 was built with MSVC 7.1 rather then msvc 6.0. It seems that I can build extensions with msvc 6.0 that work with the python 2.4 windows binary kit. Is this safe? I recall warning a while ago about mixing msvc 6.0 and msvc 7.1 runtime DLL's. Is this an issue with python 2.4? I'm also surprised that the python 2.4 source kit only mentions MSVC 6.0 and not the compiler that you actually built python 2.4 with. Barry ___ 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] Build extensions for windows python 2.4 what are the compiler rules?
Barry Scott wrote: It seems that I can build extensions with msvc 6.0 that work with the python 2.4 windows binary kit. Is this safe? No, it isn't. This emerges as a Python 2.4 FAQ. I recall warning a while ago about mixing msvc 6.0 and msvc 7.1 runtime DLL's. Is this an issue with python 2.4? Yes, it is. I'm also surprised that the python 2.4 source kit only mentions MSVC 6.0 and not the compiler that you actually built python 2.4 with. Why do you say that? PCbuild/readme.txt starts with Building Python using VC++ 7.1 - This directory is used to build Python for Win32 platforms, e.g. Windows 95, 98 and NT. It requires Microsoft Visual C++ 7.1 (a.k.a. Visual Studio .NET 2003). (For other Windows platforms and compilers, see ../PC/readme.txt.) 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] Build extensions for windows python 2.4 what are the compiler rules?
On Dec 23, 2004, at 23:12, Martin v. Löwis wrote: Barry Scott wrote: It seems that I can build extensions with msvc 6.0 that work with the python 2.4 windows binary kit. Is this safe? No, it isn't. This emerges as a Python 2.4 FAQ. I recall warning a while ago about mixing msvc 6.0 and msvc 7.1 runtime DLL's. Is this an issue with python 2.4? Yes, it is. I'm also surprised that the python 2.4 source kit only mentions MSVC 6.0 and not the compiler that you actually built python 2.4 with. Why do you say that? PCbuild/readme.txt starts with I recursive grep'ed and missed this ref. However I did read this in README.TXT: > Building on non-UNIX systems > > For Windows (2000/NT/ME/98/95), assuming you have MS VC++ 6.0, the > project files are in PCbuild, the workspace is pcbuild.dsw. See > PCbuild\readme.txt for detailed instructions. Which says that PCbuild/readme.txt is about VC++ 6.0 Building Python using VC++ 7.1 - This directory is used to build Python for Win32 platforms, e.g. Windows 95, 98 and NT. It requires Microsoft Visual C++ 7.1 (a.k.a. Visual Studio .NET 2003). (For other Windows platforms and compilers, see ../PC/readme.txt.) Regards, Martin Barry ___ 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
