[Python-Dev] Passing floats to file.seek
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). I propose a different approach: passing floats to seek should be an error. My version of the patch uses the index API, this will automatically give an error. Two questions: a) should floats be supported as parameters to file.seek b) if not, should Python 2.6 just deprecate such usage, or outright reject it? Regards, Martin ___ 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] Passing floats to file.seek
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). I propose a different approach: passing floats to seek should be an error. My version of the patch uses the index API, this will automatically give an error. Two questions: a) should floats be supported as parameters to file.seek I don't really see why. 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 already produces such a warning: f = open(hello.txt) f.seek(1.5) f.read(1.5) __main__:1: DeprecationWarning: integer argument expected, got float 'e' /F ___ 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] Passing floats to file.seek
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. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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
[Python-Dev] ready-made timezones for the datetime module
I guess I should remember, but what's the rationale for not including even a single concrete tzinfo implementation in the standard library? not even a UTC class? or am I missing something? /F ___ 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] ready-made timezones for the datetime module
Fredrik Lundh schrieb: I guess I should remember, but what's the rationale for not including even a single concrete tzinfo implementation in the standard library? not even a UTC class? or am I missing something? If you are asking for a time-zone database, such as pytz (http://sourceforge.net/projects/pytz/), then I think there are two reasons for why no such code is included: a) such a database is not available in standard C, or even in POSIX. So it is not possible to provide this functionality by wrapping a widely-available library. b) no code to provide such functionality has been contributed. Normally, b) would be the bigger issue. In this case, I think there might also be resistance to including a large database (as usual when inclusion of some database is proposed). Regards, Martin ___ 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] ready-made timezones for the datetime module
Martin v. Löwis wrote: I guess I should remember, but what's the rationale for not including even a single concrete tzinfo implementation in the standard library? not even a UTC class? or am I missing something? If you are asking for a time-zone database I was more thinking of basic stuff like the UTC, FixedOffset and LocalTimezone classes from the library reference: http://docs.python.org/lib/datetime-tzinfo.html I just wrote a small RSS generator; it took more more time to sort out how to get strftime(%z) to print something meaningful than it took to write the rest of the code. would anyone mind if I added the above classes to the datetime module ? /F ___ 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] ready-made timezones for the datetime module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 12, 2006, at 3:55 PM, Fredrik Lundh wrote: would anyone mind if I added the above classes to the datetime module ? +1. I mean, we have an example of UTC in the docs, so, er, why not include it in the stdlib?! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRVePLHEjvBPtnXfVAQIyGAQAi18TdI55P1vDp7sTuHS7eQMZmXMAr4+M 8i2RpWZrxtgi4c21J/qiwEIoY3KdANiUyzb8PbScf8LuFzZZTiDPsuMuTDC8IhBR w6bvU/AOpsmWpkuSKyjPaVdgZlOQ8IsHOJUQtYAVDsfMCh4D0Y65jMHENi1gYzud JJky5a6DifM= =BxZL -END PGP SIGNATURE- ___ 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
[Python-Dev] Summer of Code: zipfile?
Hello, wasn't there a project about the zipfile module in the Summer of Code? How did it go? Giovanni Bajo ___ 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] ready-made timezones for the datetime module
IMO it was an oversight. Or we were all exhausted. I keep copying those three classes from the docs, which is silly. :-) On 11/12/06, Fredrik Lundh [EMAIL PROTECTED] wrote: I guess I should remember, but what's the rationale for not including even a single concrete tzinfo implementation in the standard library? not even a UTC class? or am I missing something? -- --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
Re: [Python-Dev] Passing floats to file.seek
On 11/12/06, Anthony Baxter [EMAIL PROTECTED] 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/) ___ 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] Summer of Code: zipfile?
You probably need to contact the authors for more info: https://svn.sourceforge.net/svnroot/ziparchive/ziparchive/trunk/ http://wiki.python.org/moin/SummerOfCode n -- On 11/12/06, Giovanni Bajo [EMAIL PROTECTED] wrote: Hello, wasn't there a project about the zipfile module in the Summer of Code? How did it go? Giovanni Bajo ___ 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/nnorwitz%40gmail.com ___ 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] ready-made timezones for the datetime module
Guido van Rossum wrote: IMO it was an oversight. Or we were all exhausted. I keep copying those three classes from the docs, which is silly. :-) I'll whip up a patch. would the embedded python module approach I'm using for _elementtree be okay, or should this go into a support library ? /F ___ 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
