Re: [Python-Dev] Iterating a closed StringIO
Am 18.11.2005 um 02:16 schrieb Guido van Rossum: > On 11/17/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: >> Am 17.11.2005 um 22:03 schrieb Guido van Rossum: >> >>> On 11/17/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: [...] Should they raise the same exception? Should this be fixed for 2.5? >>> >>> I think cStringIO is doing the right thing; "real" files behave the >>> same way. >>> >>> Submit a patch for StringIO (also docs please) and assign it to >>> me and >>> I'll make sure it goes in. >> >> http://www.python.org/sf/1359365 > > Thanks! > >> Doc/lib/libstringio.tex only states "See the description of file >> objects for operations", so I'm not sure how to update the >> documentation. > > OK, so that's a no-op. > > I hope there isn't anyone here who believes this patch would be a > bad idea? I wonder whether we should introduce a new exception class for these kinds or error. IMHO ValueError is much to unspecific. What about StateError? Bye, Walter Dörwald ___ 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] isatty() on closed StringIO (was: Iterating a closed StringIO)
Guido van Rossum wrote: > On 11/17/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: > >>Am 17.11.2005 um 22:03 schrieb Guido van Rossum: >> >> >>>On 11/17/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: >>> Currently StringIO.StringIO and cStringIO.StringIO behave differently when iterating a closed stream: > [...] > > I hope there isn't anyone here who believes this patch would be a bad idea? BTW, isatty() has a similar problem: >>> import StringIO, cStringIO >>> s = StringIO.StringIO() >>> s.close() >>> s.isatty() Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/StringIO.py", line 93, in isatty _complain_ifclosed(self.closed) File "/usr/local/lib/python2.4/StringIO.py", line 40, in _complain_ifclosed raise ValueError, "I/O operation on closed file" ValueError: I/O operation on closed file >>> s = cStringIO.StringIO() >>> s.close() >>> s.isatty() False I guess cStringIO.StringIO.isatty() should raise an exception too. Bye, Walter Dörwald ___ 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] Another StringIO/cStringIO discrepancy
>>> import StringIO, cStringIO >>> s = StringIO.StringIO() >>> s.truncate(-42) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/StringIO.py", line 203, in truncate raise IOError(EINVAL, "Negative size not allowed") IOError: [Errno 22] Negative size not allowed >>> s = cStringIO.StringIO() >>> s.truncate(-42) >>> ___ 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] Memory management in the AST parser & compiler
The behavior of libiberty's alloca() replacement might be interesting as well: http://gcc.gnu.org/onlinedocs/libiberty/Functions.html#index-alloca-59 Regards, Michael On 11/18/05, Alex Martelli <[EMAIL PROTECTED]> wrote: > > On Nov 17, 2005, at 5:00 PM, Thomas Lee wrote: > > > Portability may also be an issue to take into consideration: > > Of course -- but so is anno domini... the eskimo.com FAQ is (C) 1995, > and the neohapsis.com page just points to the eskimo.com one: > > > http://www.eskimo.com/~scs/C-faq/q7.32.html > > http://archives.neohapsis.com/archives/postfix/2001-05/1305.html > > In 2006, I'm not sure the need to avoid alloca is anywhere as > strong. Sure, it could be wrapped into a LOCALLOC macro (with a > companion LOCFREE one), the macro expanding to alloca/nothing on > systems which do have alloca and to malloc/free elsewhere -- this > would keep the sources just as cluttered, but still speed things up > where feasible. E.g., on my iBook, a silly benchmark just freeing > and allocating 80,000 hunks of 1000 bytes takes 13ms with alloca, 57 > without... > > > Alex > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com > ___ 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] Iterating a closed StringIO
Guido van Rossum wrote: > > I hope there isn't anyone here who believes this patch would be a bad idea? Not me, but the Iterator protocol docs may need a minor tweak. Currently they say this: "The intention of the protocol is that once an iterator's next() method raises StopIteration, it will continue to do so on subsequent calls. Implementations that do not obey this property are deemed broken." This wording is a bit too strong, as it's perfectly acceptable for an object to provide other methods which affect the result of subsequent calls to the next() method (examples being the seek() and close() methods in the file interface). The current wording does describe the basic intent of the API correctly, but you could forgiven for thinking that it ruled out modifying the state of a completed iterator in a way that restarts it, or causes it to raise an exception other than StopIteration. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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] Iterating a closed StringIO
[Guido van Rossum] > > I hope there isn't anyone here who believes this patch would be a bad > idea? [Nick Coglan] > Not me, but the Iterator protocol docs may need a minor tweak. Currently > they > say this: > > "The intention of the protocol is that once an iterator's next() method > raises > StopIteration, it will continue to do so on subsequent calls. > Implementations > that do not obey this property are deemed broken." FWIW, here is wording for PEP 342's close() method: """ 4. Add a close() method for generator-iterators, which raises GeneratorExit at the point where the generator was paused. If the generator then raises StopIteration (by exiting normally, or due to already being closed) or GeneratorExit (by not catching the exception), close() returns to its caller. If the generator yields a value, a RuntimeError is raised. If the generator raises any other exception, it is propagated to the caller. close() does nothing if the generator has already exited due to an exception or normal exit. """ For Walter's original question, my preference is to change the behavior of regular files to raise StopIteration when next() is called on an iterator for a closed file. The current behavior is an implementation artifact stemming from a file being its own iterator object. In the future, it is possible that iter(somefileobject) will return a distinct iterator object and perhaps allow multiple, distinct iterators over the same file. Also, it is sometimes nice to wrap one iterator with another (perhaps with itertools or somesuch). That use case depends on the underlying iterator raising StopIteration instead of some other exception: f = open(somefilename) for lineno, line in enumerate(f): . . . Raymond ___ 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] Memory management in the AST parser & compiler
There is a public-domain implementation of alloca at http://www.cs.purdue.edu/homes/apm/courses/BITSC461-fall03/listen-code/listen-1.0-dave/lsl_cpp/alloca.c It would still fail on architectures that don't use a stack frame; other than that, it seems like a reasonable fallback, if alloca is otherwise desirable. -jJ ___ 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] Iterating a closed StringIO
On 11/18/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > For Walter's original question, my preference is to change the behavior > of regular files to raise StopIteration when next() is called on an > iterator for a closed file. I disagree. As long as there is a possibility that you might still want to use the iterator (even if it's exhausted) you shouldn't close the file. Closing a file is a strong indicator that you believe that there is no more use of the file, and *all* file methods change their behavior at that point; e.g. read() on a closed file raises an exception instead of returning an empty string. This is to catch the *bug* of closing a file that is still being used. Now it's questionable whether ValueError is the best exception in this case, since that is an exception which reasonable programmers often catch (e.g. when parsing a string that's supposed to represent an int). But I propose to leave the choice of exception reform for Python 3000. -- --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
Re: [Python-Dev] Another StringIO/cStringIO discrepancy
On 11/18/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: > >>> import StringIO, cStringIO > >>> s = StringIO.StringIO() > >>> s.truncate(-42) > Traceback (most recent call last): >File "", line 1, in ? >File "/usr/local/lib/python2.4/StringIO.py", line 203, in truncate > raise IOError(EINVAL, "Negative size not allowed") > IOError: [Errno 22] Negative size not allowed > >>> s = cStringIO.StringIO() > >>> s.truncate(-42) > >>> Well, what does a regular file say in this case? -- --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
Re: [Python-Dev] Another StringIO/cStringIO discrepancy
Guido van Rossum wrote: > On 11/18/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: > >> >>> import StringIO, cStringIO >> >>> s = StringIO.StringIO() >> >>> s.truncate(-42) >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/local/lib/python2.4/StringIO.py", line 203, in truncate >> raise IOError(EINVAL, "Negative size not allowed") >>IOError: [Errno 22] Negative size not allowed >> >>> s = cStringIO.StringIO() >> >>> s.truncate(-42) >> >>> > > > Well, what does a regular file say in this case? IOError: [Errno 22] Invalid argument Bye, Walter Dörwald ___ 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] isatty() on closed StringIO
Paul Svensson wrote: > On Fri, 18 Nov 2005, Walter Dörwald wrote: > >> BTW, isatty() has a similar problem: >> >> >>> import StringIO, cStringIO >> >>> s = StringIO.StringIO() >> >>> s.close() >> >>> s.isatty() >> Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/local/lib/python2.4/StringIO.py", line 93, in isatty >> _complain_ifclosed(self.closed) >> File "/usr/local/lib/python2.4/StringIO.py", line 40, in >> _complain_ifclosed >> raise ValueError, "I/O operation on closed file" >> ValueError: I/O operation on closed file >> >>> s = cStringIO.StringIO() >> >>> s.close() >> >>> s.isatty() >> False >> >> I guess cStringIO.StringIO.isatty() should raise an exception too. > > > Why ? Is there any doubt that it's not a tty ? No, but for real files a ValueError is raised too. Bye, Walter Dörwald ___ 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] str.dedent
Noam Raphael wrote:
> I just wanted to add another use case: long messages. Consider those
> lines from idlelib/run.py:133
>
> msg = "IDLE's subprocess can't connect to %s:%d. This may be due "\
> "to your personal firewall configuration. It is safe to "\
> "allow this internal connection because no data is visible on "\
> "external ports." % address
> tkMessageBox.showerror("IDLE Subprocess Error", msg, parent=root)
You are missing an important point here: There are intentionally no line
breaks in this string; it must be a single line, or else showerror will
break it in funny ways. So converting it to a multi-line string would
break it, dedent or not.
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
[Python-Dev] Enjoy a week without me
Folks, I'm off for a week with my wife's family (and one unlucky turkey :-) in a place where I can't care about email. I will be back here on Monday Nov 28. -- --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] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 379 open (+14) / 2968 closed ( +7) / 3347 total (+21) Bugs: 910 open ( +6) / 5384 closed (+17) / 6294 total (+23) RFE : 200 open ( +0) / 191 closed ( +2) / 391 total ( +2) New / Reopened Patches __ PythonD DJGPP-specific patch set for porting to DOS. (2005-11-08) http://python.org/sf/1351020 opened by Ben Decker PythonD new file: python2.4/plat-ms-dos5/djstat.py (2005-11-08) http://python.org/sf/1351036 opened by Ben Decker askyesnocancel helper for tkMessageBox (2005-11-08) http://python.org/sf/1351744 opened by Fredrik Lundh fix for resource leak in _subprocess (2005-11-09) CLOSED http://python.org/sf/1351997 opened by Fredrik Lundh [PATCH] Bug #1351707 (2005-11-10) http://python.org/sf/1352711 opened by Thomas Lee Small upgrades to platform.platform() (2005-11-10) http://python.org/sf/1352731 opened by daishi harada a faster Modulefinder (2005-11-11) http://python.org/sf/1353872 opened by Thomas Heller support whence argument for GzipFile.seek (bug #1316069) (2005-11-12) http://python.org/sf/1355023 opened by Fredrik Lundh PEP 341 - Unification of try/except and try/finally (2005-11-14) http://python.org/sf/1355913 opened by Thomas Lee Delete Python-ast.[ch] during "make depclean" (#1355883) (2005-11-14) CLOSED http://python.org/sf/1355940 opened by Thomas Lee Python-ast.h & Python-ast.c generated twice (#1355883) (2005-11-14) http://python.org/sf/1355971 opened by Thomas Lee Sort nodes when writing to file (2005-11-14) CLOSED http://python.org/sf/1356571 opened by Johan Ström potential crash and free memory read (2005-11-15) http://python.org/sf/1357836 opened by Neal Norwitz ftplib dir() problem with certain servers (2005-11-17) http://python.org/sf/1359217 opened by Stuart D. Gathman Iterating closed StringIO.StringIO (2005-11-18) http://python.org/sf/1359365 opened by Walter Dörwald Speed charmap encoder (2005-11-18) http://python.org/sf/1359618 opened by Martin v. Löwis Patch for (Doc) #1357604 (2005-11-18) http://python.org/sf/1359879 opened by Peter van Kampen Add XML-RPC Fault Interoperability to XMLRPC libraries (2005-11-18) http://python.org/sf/1360243 opened by Joshua Ginsberg correct display of pathnames in SimpleHTTPServer (2005-11-18) http://python.org/sf/1360443 opened by Ori Avtalion Auto Complete module for IDLE (2005-11-19) http://python.org/sf/1361016 opened by Jerry Patches Closed __ Redundant connect() call in logging.handlers.SysLogHandler (2005-11-07) http://python.org/sf/1350658 closed by vsajip incomplete support for AF_PACKET in socketmodule.c (2004-11-19) http://python.org/sf/1069624 closed by gustavo fix for resource leak in _subprocess (2005-11-09) http://python.org/sf/1351997 closed by effbot Info Associated with Merge to AST (2005-01-07) http://python.org/sf/1097671 closed by kbk Delete Python-ast.[ch] during "make depclean" (#1355883) (2005-11-13) http://python.org/sf/1355940 closed by montanaro Sort nodes when writing to file (2005-11-14) http://python.org/sf/1356571 closed by effbot CodeContext - an extension to show you where you are (2004-04-16) http://python.org/sf/936169 closed by kbk New / Reopened Bugs ___ win32serviceutil bug (2005-11-08) CLOSED http://python.org/sf/1351545 opened by Tim Graber Switch to make pprint.pprint display ints and longs in hex (2005-11-08) http://python.org/sf/1351692 opened by Mark Hirota zipimport produces incomplete IOError instances (2005-11-08) http://python.org/sf/1351707 opened by Fred L. Drake, Jr. CVS webbrowser.py (1.40) bugs (2005-10-26) CLOSED http://python.org/sf/1338995 reopened by montanaro SVN webbrowser.py fix 41419 didn't (2005-11-09) http://python.org/sf/1352621 opened by Greg Couch poplib.POP3_SSL() class incompatible with socket.timeout (2005-11-10) http://python.org/sf/1353269 opened by Charles Http redirection error in urllib2.py (2005-11-10) http://python.org/sf/1353433 opened by Thomas Dehn Python drops core when stdin is bogus (2005-11-10) http://python.org/sf/1353504 opened by Skip Montanaro Error in documentation for os.walk (2005-11-11) CLOSED http://python.org/sf/1353793 opened by Martin Geisler logging: Default handlers broken (2005-11-11) CLOSED http://python.org/sf/1354052 opened by Jonathan S. Joseph Interactive help fails with Windows Installer (2005-11-11) CLOSED http://python.org/sf/1354265 opened by Colin J. Williams shutil.move() does not preserve ownership (2005-11-13) http://python.org/sf/1355826 opened by lightweight Incorrect Decimal-float behavior for + (2005-11-13) http://python.org/sf/1355842 opene
