Mailman 3 August 2005 - Python-Dev

test_bz2 on Python 2.4.1
by A.B., Khalid 27 Aug '05

27 Aug '05

Reinhold Birkenfeld wrote: >Are you sure that you are calling the newly-built python.exe? It is strange >that >the test should pass in interactive mode when it doesn't in normal mode. >For a confirmation, can you execute this piece of code both interactively >and >from a file: Yes, both Python's tested are fresh from CVS. Here is the output of the test you asked I run #---------------------- # File: testbz2.py #---------------------- """ import os from bz2 import BZ2File data = 'BZh91AY&SY\xd9b\x89]\x00\x00\x00\x03\x80\x04\x00\x02\x00\x0c\x00 \x00!\x9ah3M\x13<]\xc9\x14\xe1BCe\x8a%t' f = open('test.bz2', "wb") f.write(data) f.close() bz2f = BZ2File('test.bz2') lines = bz2f.readlines() bz2f.close() assert lines == ['Test'] bz2f = BZ2File('test.bz2') xlines = list(bz2f.xreadlines()) bz2f.close() assert lines == ['Test'] os.unlink('test.bz2') """ ------------- RESULTS: ------------- #--------------------------- Python 2.5a0 from CVS -----------------# # Result: passes $ /g/projs/py25/python/dist/src/MinGW/python testbz2.py #--------------------------- Python 2.4.1 from CVS -----------------# # Result: fails $ /g/projs/py24/python/dist/src/MinGW/python testbz2.py Traceback (most recent call last): File "testbz2.py", line 9, in ? lines = bz2f.readlines() RuntimeError: wrong sequence of bz2 library commands used #--------------------------- Python 2.4.1 from CVS -----------------# # Interpreted session: testbz2 fails here as well now $ /g/projs/py24/python/dist/src/MinGW/python -i Python 2.4.1 (#65, Aug 26 2005, 14:38:48) [GCC 3.4.4 (mingw special)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>>import os >>>from bz2 import BZ2File >>>data = 'BZh91AY&SY\xd9b\x89]\x00\x00\x00\x03\x80\x04\x00\x02\x00\x0c\x00 >>>\x0 0!\x9ah3M\x13<]\xc9\x14\xe1BCe\x8a%t' >>>f = open('test.bz2', "wb") >>>f.write(data) >>>f.close() >>>bz2f = BZ2File('test.bz2') >>>lines = bz2f.readlines() Traceback (most recent call last): File "<stdin>", line 1, in ? RuntimeError: wrong sequence of bz2 library commands used >>>raise SystemExit #--------------------------- Python 2.5a0 from CVS -----------------# # Interpreted session: testbz2 passes $ /g/projs/py25/python/dist/src/MinGW/python -i Python 2.5a0 (#65, Aug 26 2005, 14:57:28) [GCC 3.4.4 (mingw special)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>>import os >>>from bz2 import BZ2File >>>data = 'BZh91AY&SY\xd9b\x89]\x00\x00\x00\x03\x80\x04\x00\x02\x00\x0c\x00 >>>\x0 0!\x9ah3M\x13<]\xc9\x14\xe1BCe\x8a%t' >>>f = open('test.bz2', "wb") >>>f.write(data) >>>f.close() >>>bz2f = BZ2File('test.bz2') >>>lines = bz2f.readlines() >>>bz2f.close() >>>assert lines == ['Test'] >>>bz2f = BZ2File('test.bz2') >>>xlines = list(bz2f.xreadlines()) >>>bz2f.close() >>>assert lines == ['Test'] >>>os.unlink('test.bz2') >>>raise SystemExit Regards, Khalid _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

2 1

Re: [Python-Dev] Remove str.find in 3.0?
by Guido van Rossum 27 Aug '05

27 Aug '05

On 8/26/05, Bill Janssen <janssen(a)parc.com> wrote: > Doubt it. The problem with returning None is that it tests as False, > but so does 0, which is a valid string index position. The reason > string.find() returns -1 is probably to allow a test: > > if line.find("\f"): > ... do something This has a bug; it is equivalent to "if not line.startswith("\f"):". This mistake (which I have made more than once myself and have seen many times in code by others) is one of the main reasons to want to get rid of this style of return value. > Might add a boolean "str.contains()" to cover this test case. We already got that: "\f" in line. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

Re: [Python-Dev] [Python-checkins] python/dist/src/Lib/test test_bz2.py, 1.18, 1.19
by Tim Peters 27 Aug '05

27 Aug '05

[birkenfeld(a)users.sourceforge.net] > Update of /cvsroot/python/python/dist/src/Lib/test > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4822/Lib/test > > Modified Files: > test_bz2.py > Log Message: > Add list() around xreadlines() > > > > Index: test_bz2.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/test/test_bz2.py,v > retrieving revision 1.18 > retrieving revision 1.19 > diff -u -d -r1.18 -r1.19 > --- test_bz2.py 21 Aug 2005 14:16:04 -0000 1.18 > +++ test_bz2.py 26 Aug 2005 13:23:54 -0000 1.19 > @@ -191,7 +191,7 @@ > def testSeekBackwardsFromEnd(self): > # "Test BZ2File.seek(-150, 2)" > self.createTempFile() > - bz2f = BZ2File(self.filename) > + )bz2f = BZ2File(self.filename) Note that this added a right parenthesis to the start of the line. That creates a syntax error, so this test could not have been tried before checking in. It also causes test_compiler to fail.

3 2

PEP 342: simple example, closure alternative
by Ian Bicking 26 Aug '05

26 Aug '05

I was trying to translate a pattern that uses closures in a language like Scheme (where closed values can be written to) to generators using PEP 342, but I'm not clear exactly how it works; the examples in the PEP have different motivations. Since I can't actually run these examples, perhaps someone could confirm or debug these: A closure based accumulator (using Scheme): (define (accum n) (lambda (incr) (set! n (+ n incr)) n)) (define s (accum 0)) (s 1) ; -> 1 == 0+1 (s 5) ; -> 6 == 1+5 So I thought the generator version might look like: def accum(n): while 1: incr = (yield n) or 0 n += incr >>> s = accum(0) >>> s.next() >>> s.send(1) 0 >>> s.send(5) 1 >>> s.send(1) 6 Is the order of the output correct? Is there a better way to write accum, that makes it feel more like the closure-based version? Is this for loop correct? >>> s = accum(0) >>> for i in s: ... if i >= 10: break ... print i, ... assert s.send(2) == i 0 2 4 6 8 Hmm... maybe this would make it feel more closure-like: def closure_like(func): def replacement(*args, **kw): return ClosureLike(func(*args, **kw)) return replacement class ClosureLike(object): def __init__(self, iterator): self.iterator = iterator # I think this initial .next() is required, but I'm # very confused on this point: assert self.iterator.next() is None def __call__(self, input): assert self.iterator.send(input) is None return self.iterator.next() @closure_like def accum(n): while 1: # yields should always be in pairs, the first yield is input # and the second yield is output. incr = (yield) # this line is equivalent to (lambda (incr)... n += incr # equivalent to (set! ...) yield n # equivalent to n; this yield always returns None >>> s = accum(0) >>> s(1) 1 >>> s(5) 6 Everything before the first (yield) is equivalent to the closed values between "(define (accum n)" and "(lambda" (for this example there's nothing there; I guess a more interesting example would have closed variables that were written to that were not function parameters). -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

6 7

Re: [Python-Dev] Style for raising exceptions (python-dev Summary for 2005-08-01 through 2005-08-15 [draft])
by Michael Chermside 26 Aug '05

26 Aug '05

Marc-Andre Lemburg writes: > This is from a comment in ceval.c: > > /* We support the following forms of raise: > raise <class>, <classinstance> > raise <class>, <argument tuple> > raise <class>, None > raise <class>, <argument> > raise <classinstance>, None > raise <string>, <object> > raise <string>, None > > An omitted second argument is the same as None. > > In addition, raise <tuple>, <anything> is the same as > raising the tuple's first item (and it better have one!); > this rule is applied recursively. > > Finally, an optional third argument can be supplied, which > gives the traceback to be substituted (useful when > re-raising an exception after examining it). */ > > That's quite a list of combinations that will all break > in Python 3.0 if we only allow "raise <classinstance>". Oh my GOD! Are you saying that in order to correctly read Python code that a programmer must know all of THAT! I would be entirely unsurprised to learn that NO ONE on this list... in fact, no one in the whole world could have reproduced that specification from memory accurately. I have never seen a more convincing argument for why we should allow only limited forms in Python 3.0. And next time that I find myself in need of an obfuscated python entry, I've got a great trick up my sleeve. -- Michael Chermside

2 1

operator.c for release24-maint and test_bz2 on Python 2.4.1
by A.B., Khalid 26 Aug '05

26 Aug '05

Hello there, The release24-maint check-ins for today contained this typo: =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/operator.c,v retrieving revision 2.29 retrieving revision 2.29.4.1 diff -u -d -r2.29 -r2.29.4.1 --- operator.c 4 Dec 2003 22:17:49 -0000 2.29 +++ operator.c 26 Aug 2005 06:43:16 -0000 2.29.4.1 @@ -267,6 +267,9 @@ itemgetterobject *ig; PyObject *item; + if (!_PyArg_NoKeywords("itemgetter()", kdws)) <----- kdws should be kwds + return NULL; + if (!PyArg_UnpackTuple(args, "itemgetter", 1, 1, &item)) return NULL; Also I wish to report that testBug1191043 of test_bz2 still fails in some cases on Python 2.4.1 on both WinXP Pro and Win98. Following is the output of the said test. #----------------------------Python 2.5a0------------------------------# # In intrepreted session mode #-----------------------------------------------------------------------------# $ python -i Python 2.5a0 (#65, Aug 26 2005, 14:57:28) [GCC 3.4.4 (mingw special)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>>from test import test_bz2 as t >>>t.test_main() testBug1191043 (test.test_bz2.BZ2FileTest) ... ok testIterator (test.test_bz2.BZ2FileTest) ... ok testModeU (test.test_bz2.BZ2FileTest) ... ok testOpenDel (test.test_bz2.BZ2FileTest) ... ok testOpenNonexistent (test.test_bz2.BZ2FileTest) ... ok testRead (test.test_bz2.BZ2FileTest) ... ok testRead100 (test.test_bz2.BZ2FileTest) ... ok testReadChunk10 (test.test_bz2.BZ2FileTest) ... ok testReadLine (test.test_bz2.BZ2FileTest) ... ok testReadLines (test.test_bz2.BZ2FileTest) ... ok testSeekBackwards (test.test_bz2.BZ2FileTest) ... ok testSeekBackwardsFromEnd (test.test_bz2.BZ2FileTest) ... ok testSeekForward (test.test_bz2.BZ2FileTest) ... ok testSeekPostEnd (test.test_bz2.BZ2FileTest) ... ok testSeekPostEndTwice (test.test_bz2.BZ2FileTest) ... ok testSeekPreStart (test.test_bz2.BZ2FileTest) ... ok testUniversalNewlinesCRLF (test.test_bz2.BZ2FileTest) ... ok testUniversalNewlinesLF (test.test_bz2.BZ2FileTest) ... ok testWrite (test.test_bz2.BZ2FileTest) ... ok testWriteChunks10 (test.test_bz2.BZ2FileTest) ... ok testWriteLines (test.test_bz2.BZ2FileTest) ... ok testXReadLines (test.test_bz2.BZ2FileTest) ... ok testCompress (test.test_bz2.BZ2CompressorTest) ... ok testCompressChunks10 (test.test_bz2.BZ2CompressorTest) ... ok testDecompress (test.test_bz2.BZ2DecompressorTest) ... ok testDecompressChunks10 (test.test_bz2.BZ2DecompressorTest) ... ok testDecompressUnusedData (test.test_bz2.BZ2DecompressorTest) ... ok testEOFError (test.test_bz2.BZ2DecompressorTest) ... ok test_Constructor (test.test_bz2.BZ2DecompressorTest) ... ok testCompress (test.test_bz2.FuncTest) ... ok testDecompress (test.test_bz2.FuncTest) ... ok testDecompressEmpty (test.test_bz2.FuncTest) ... ok testDecompressIncomplete (test.test_bz2.FuncTest) ... ok ---------------------------------------------------------------------- Ran 33 tests in 4.730s OK #----------------------------Python 2.4.1 from CVS ----------------# # In intrepreted session mode #-----------------------------------------------------------------------------# $ python -i Python 2.4.1 (#65, Aug 26 2005, 14:38:48) [GCC 3.4.4 (mingw special)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>>from test import test_bz2 as t >>>t.test_main() testBug1191043 (test.test_bz2.BZ2FileTest) ... ok testIterator (test.test_bz2.BZ2FileTest) ... ok testModeU (test.test_bz2.BZ2FileTest) ... ok testOpenDel (test.test_bz2.BZ2FileTest) ... ok testOpenNonexistent (test.test_bz2.BZ2FileTest) ... ok testRead (test.test_bz2.BZ2FileTest) ... ok testRead100 (test.test_bz2.BZ2FileTest) ... ok testReadChunk10 (test.test_bz2.BZ2FileTest) ... ok testReadLine (test.test_bz2.BZ2FileTest) ... ok testReadLines (test.test_bz2.BZ2FileTest) ... ok testSeekBackwards (test.test_bz2.BZ2FileTest) ... ok testSeekBackwardsFromEnd (test.test_bz2.BZ2FileTest) ... ok testSeekForward (test.test_bz2.BZ2FileTest) ... ok testSeekPostEnd (test.test_bz2.BZ2FileTest) ... ok testSeekPostEndTwice (test.test_bz2.BZ2FileTest) ... ok testSeekPreStart (test.test_bz2.BZ2FileTest) ... ok testUniversalNewlinesCRLF (test.test_bz2.BZ2FileTest) ... ok testUniversalNewlinesLF (test.test_bz2.BZ2FileTest) ... ok testWrite (test.test_bz2.BZ2FileTest) ... ok testWriteChunks10 (test.test_bz2.BZ2FileTest) ... ok testWriteLines (test.test_bz2.BZ2FileTest) ... ok testXReadLines (test.test_bz2.BZ2FileTest) ... ok testCompress (test.test_bz2.BZ2CompressorTest) ... ok testCompressChunks10 (test.test_bz2.BZ2CompressorTest) ... ok testDecompress (test.test_bz2.BZ2DecompressorTest) ... ok testDecompressChunks10 (test.test_bz2.BZ2DecompressorTest) ... ok testDecompressUnusedData (test.test_bz2.BZ2DecompressorTest) ... ok testEOFError (test.test_bz2.BZ2DecompressorTest) ... ok test_Constructor (test.test_bz2.BZ2DecompressorTest) ... ok testCompress (test.test_bz2.FuncTest) ... ok testDecompress (test.test_bz2.FuncTest) ... ok testDecompressEmpty (test.test_bz2.FuncTest) ... ok testDecompressIncomplete (test.test_bz2.FuncTest) ... ok ---------------------------------------------------------------------- Ran 33 tests in 5.060s OK So here we have a passing test_bz2 test when invoked from inside a running Python. #-------------------------- Python 2.4.1 from CVS -----------------# # Not in intrepreted session mode #-----------------------------------------------------------------------------# However, and in Python 2.4.1 the following happens when the test is not invoked from an interpreted session: $ python ../Lib/test/test_bz2.py testBug1191043 (__main__.BZ2FileTest) ... ERROR ERROR testIterator (__main__.BZ2FileTest) ... ok testModeU (__main__.BZ2FileTest) ... ok testOpenDel (__main__.BZ2FileTest) ... ok testOpenNonexistent (__main__.BZ2FileTest) ... ok testRead (__main__.BZ2FileTest) ... ok testRead100 (__main__.BZ2FileTest) ... ok testReadChunk10 (__main__.BZ2FileTest) ... ok testReadLine (__main__.BZ2FileTest) ... ok testReadLines (__main__.BZ2FileTest) ... ok testSeekBackwards (__main__.BZ2FileTest) ... ok testSeekBackwardsFromEnd (__main__.BZ2FileTest) ... ok testSeekForward (__main__.BZ2FileTest) ... ok testSeekPostEnd (__main__.BZ2FileTest) ... ok testSeekPostEndTwice (__main__.BZ2FileTest) ... ok testSeekPreStart (__main__.BZ2FileTest) ... ok testUniversalNewlinesCRLF (__main__.BZ2FileTest) ... ok testUniversalNewlinesLF (__main__.BZ2FileTest) ... ok testWrite (__main__.BZ2FileTest) ... ok testWriteChunks10 (__main__.BZ2FileTest) ... ok testWriteLines (__main__.BZ2FileTest) ... ok testXReadLines (__main__.BZ2FileTest) ... ok testCompress (__main__.BZ2CompressorTest) ... ok testCompressChunks10 (__main__.BZ2CompressorTest) ... ok testDecompress (__main__.BZ2DecompressorTest) ... ok testDecompressChunks10 (__main__.BZ2DecompressorTest) ... ok testDecompressUnusedData (__main__.BZ2DecompressorTest) ... ok testEOFError (__main__.BZ2DecompressorTest) ... ok test_Constructor (__main__.BZ2DecompressorTest) ... ok testCompress (__main__.FuncTest) ... ok testDecompress (__main__.FuncTest) ... ok testDecompressEmpty (__main__.FuncTest) ... ok testDecompressIncomplete (__main__.FuncTest) ... ok ====================================================================== ERROR: testBug1191043 (__main__.BZ2FileTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "../Lib/test/test_bz2.py", line 255, in testBug1191043 lines = bz2f.readlines() RuntimeError: wrong sequence of bz2 library commands used ====================================================================== ERROR: testBug1191043 (__main__.BZ2FileTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "../Lib/test/test_bz2.py", line 47, in tearDown os.unlink(self.filename) OSError: [Errno 13] Permission denied: '@test' ---------------------------------------------------------------------- Ran 33 tests in 6.210s FAILED (errors=2) Traceback (most recent call last): File "../Lib/test/test_bz2.py", line 357, in ? test_main() File "../Lib/test/test_bz2.py", line 353, in test_main FuncTest File "G:\PROJS\PY24\PYTHON\DIST\SRC\lib\test\test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "G:\PROJS\PY24\PYTHON\DIST\SRC\lib\test\test_support.py", line 274, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred; run in verbose mode for details #-------------------------- Python 2.5a0 from CVS -----------------# # Not in intrepreted session mode #-----------------------------------------------------------------------------# That problem disappears in Python 2.5a0: $ python ../Lib/test/test_bz2.py testBug1191043 (__main__.BZ2FileTest) ... ok testIterator (__main__.BZ2FileTest) ... ok testModeU (__main__.BZ2FileTest) ... ok testOpenDel (__main__.BZ2FileTest) ... ok testOpenNonexistent (__main__.BZ2FileTest) ... ok testRead (__main__.BZ2FileTest) ... ok testRead100 (__main__.BZ2FileTest) ... ok testReadChunk10 (__main__.BZ2FileTest) ... ok testReadLine (__main__.BZ2FileTest) ... ok testReadLines (__main__.BZ2FileTest) ... ok testSeekBackwards (__main__.BZ2FileTest) ... ok testSeekBackwardsFromEnd (__main__.BZ2FileTest) ... ok testSeekForward (__main__.BZ2FileTest) ... ok testSeekPostEnd (__main__.BZ2FileTest) ... ok testSeekPostEndTwice (__main__.BZ2FileTest) ... ok testSeekPreStart (__main__.BZ2FileTest) ... ok testUniversalNewlinesCRLF (__main__.BZ2FileTest) ... ok testUniversalNewlinesLF (__main__.BZ2FileTest) ... ok testWrite (__main__.BZ2FileTest) ... ok testWriteChunks10 (__main__.BZ2FileTest) ... ok testWriteLines (__main__.BZ2FileTest) ... ok testXReadLines (__main__.BZ2FileTest) ... ok testCompress (__main__.BZ2CompressorTest) ... ok testCompressChunks10 (__main__.BZ2CompressorTest) ... ok testDecompress (__main__.BZ2DecompressorTest) ... ok testDecompressChunks10 (__main__.BZ2DecompressorTest) ... ok testDecompressUnusedData (__main__.BZ2DecompressorTest) ... ok testEOFError (__main__.BZ2DecompressorTest) ... ok test_Constructor (__main__.BZ2DecompressorTest) ... ok testCompress (__main__.FuncTest) ... ok testDecompress (__main__.FuncTest) ... ok testDecompressEmpty (__main__.FuncTest) ... ok testDecompressIncomplete (__main__.FuncTest) ... ok ---------------------------------------------------------------------- Ran 33 tests in 5.880s OK Regards Khalid _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

Re: [Python-Dev] Bare except clauses in PEP 348
by Michael Chermside 26 Aug '05

26 Aug '05

Raymond writes: > Efforts to improve Py3.0 have spilled > over into breaking Py2.x code with no compensating benefits. [...] > We don't have to wreck 2.x in order to make 3.0 better. I think you're overstating things a bit here. > Remember, the ONLY benefit from the whole PEP is that in 3.0, it will no > longer be necessary to write "except (KeyError, SystemExit): raise". > [...] IOW, there's nothing worth inflicting destruction on tons of > 2.x code. And now I *KNOW* you're overstating things. There are LOTS of benefits to the PEP in 3.0. My own personal favorite is that users can be guaranteed that all exceptions thrown will share a particular common ancestor and type. And no one is proposing "destruction" of 2.x code. On the other hand, I thought these were very good points: > Bare > except clauses appear in almost every Python book that has ever been > written and occur at least once in most major Python applications. [...] > I had thought the plan was to introduce Py3.0 capabilities into 2.x as > they become possible but not to break anything. [...] > I propose that the transition plan be as simple as introducing > BaseException. This allows people to write code that will work on both > 2.x and 3.0. I think the situation is both better than and worse than you describe. The PEP is now proposing that bare "except:" be removed in Python 3.0. If I understand Guido correctly, he is proposing that in 2.5 the use of bare "except:" generate a PendingDeprecationWarning so that conscientious developers who want to write code now that will continue to work in Python 3.0 can avoid using bare "except:". Perhaps I'm misreading him here, but I presume this was intended as a PENDINGDeprecationWarning so that it's easy to ignore. But it's a bit worse than it might seem, because conscientious users aren't ABLE to write safe 2.5 code that will run in 3.0. The problem arises when you need to write code that calls someone else's library but then unconditionally recovers from errors in it. Correct 2.4 syntax for this reads as follows: try: my_result = call_some_library(my_data) except (KeyboardInterrupt, MemoryError, SystemError): raise except: report_error() Correct 3.0 syntax will read like this: try: my_result = call_some_library(my_data) except (KeyboardInterrupt, MemoryError, SystemError): raise except BaseException: report_error() But no syntax will work in BOTH 2.5 and 3.0. The 2.4 syntax is illegal in 3.0, and the 3.0 syntax fails to catch exceptions that do not inherit from BaseException. Such exceptions are deprecated (by documentation, if not by code) so our conscientious programmer will never raise them and the standard library avoids doing so. But "call_some_library()" was written by some less careful developer, and may well contain these atavisims. The only complete solution that comes to mind immediately is for the raising of anything not extending BaseException to raise a PendingDeprecationWarning as well. Then the conscientious developer can feel confident again so long as her unit tests are reasonably exhaustive. If we cannot produce a warning for these, then I'd rather not produce the warning for the use of bare "except:". After all, as it's been pointed out, if the use of bare "except:" is all you are interested in it is quite easy to grep the code to find all uses. -- Michael Chermside

10 13

Re: [Python-Dev] Bare except clauses in PEP 348
by Michael Chermside 26 Aug '05

26 Aug '05

Raymond Hettinger writes: > The latest version of PEP 348 still proposes that a bare except clause > will default to Exception instead of BaseException. Initially, I had > thought that might be a good idea but now think it is doomed and needs > to be removed from the PEP. Guido writes: > If we syntactically enforce that the bare except, if present, must be > last, would that remove your objection? I agree that a bare except in > the middle is an anomaly, but that doesn't mean we can't keep bare > except: as a shorthand for except Exception:. Explicit is better than Implicit. I think that in newly written code "except Exception:" is better (more explicit and easier to understand) than "except:" Legacy code that uses "except:" can remain unchanged *IF* the meaning of "except:" is unchanged... but I think we all agree that this is unwise because the existing meaning is a tempting trap for the unwary. So I don't see any advantage to keeping bare "except:" in the long run. What we do to ease the transition is a different question, but one more easily resolved. -- Michael Chermside

9 18

Re: [Python-Dev] Bare except clauses in PEP 348
by Michael Chermside 25 Aug '05

25 Aug '05

[PLEASE IGNORE PREVIOUS EMAIL... I HIT [Send] BY MISTAKE] Guido: > But how about the following compromise: make it a silent deprecation > in 2.5, and a full deprecation in 2.6. Reinhold Birkenfeld: > That said, I think that unless it is a new feature (like with statements) > transitions to Python 3.0 shouldn't be enforced in the 2.x series. With 3.0, > everyone expects a clear cut and a compatibility breach. Raymond: > I'd love to compromise but it's your language. If you're going to > deprecate, just do it. Pulling the band-aid off slowly doesn't lessen > the total pain. There are actually THREE possible levels of deprecation available. In order of severity, they are: 1. Modifying the documentation to advise people to avoid this feature. No one gets alerted. 2. Using a PendingDeprecationWarning so people who explicitly request it can have the compiler alert them when they use it. 3. Using a DeprecationWarning so people using it are alerted unless they explicitly request NOT to be alerted. I think 3 is unwarrented in this case. For reasons I explained in a previous posting, I would be in favor of 2 if we can *also* have a PendingDeprecationWarning for use of string exceptions and arbitrary-object exceptions (those not derived from BaseException). I am in favor of 3 in any case. Of course, that's just one person's opinion... Raymond also raised this excellent point: > There is a reason that over 120 bare except clauses remain in the > standard library despite a number of attempts to get rid of them. [...] > If the proponents don't have time to fix the standard library, how can > they in good conscience mandate change for the rest of the world. That seems like a fair criticism to me. As we've already noted, it is impossible to replace ALL uses of bare "except:" in 2.5 (particularly the use in code.py that Guido referred to). But we ought to make an extra effort to remove unnecessary uses of bare "except:" from the standard library if we intend to deprecate it. -- Michael Chermisde

1 0

Re: [Python-Dev] Bare except clauses in PEP 348
by Michael Chermside 25 Aug '05

25 Aug '05

Guido: > But how about the following compromise: make it a silent deprecation > in 2.5, and a full deprecation in 2.6. Reinhold Birkenfeld: > That said, I think that unless it is a new feature (like with statements) > transitions to Python 3.0 shouldn't be enforced in the 2.x series. With 3.0, > everyone expects a clear cut and a compatibility breach. Raymond: > I'd love to compromise but it's your language. If you're going to > deprecate, just do it. Pulling the band-aid off slowly doesn't lessen > the total pain. There are actually THREE possible levels of deprecation available. In order of severity, they are: 1. Modifying the documentation to advise people to avoid this feature. No one gets alerted. 2. Using a PendingDeprecationWarning so people who explicitly request it can have the compiler alert them when they use it. 3. Using a DeprecationWarning so people using it are alerted unless they explicitly request NOT to be alerted. I think 3 is unwarrented in this case. For reasons I explained in a previous posting, I would be in favor of 2 if we can *also* have a PendingDeprecationWarning for use of string exceptions and arbitrary-object exceptions (those not derived from BaseException). I am in favor of 3 in any case. Of course, that's just one person's opinion... Raymond also raised this excellent point: > There is a reason that over 120 bare except clauses remain in the > standard library despite a number of attempts to get rid of them. [...] > If the proponents don't have time to fix the standard library, how can > they in good conscience mandate change for the rest of the world. That seems like a fair criticism to me. As we've already noted, it is impossible to replace ALL uses of bare "except:" in 2.5 (particularly the

1 0