Re: [Python-Dev] Style for raising exceptions (python-dev Summary for 2005-08-01 through 2005-08-15 [draft])
Guido van Rossum wrote:
> On 8/25/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>
>>I must have missed this one:
>>
>>
>>>
>>>Style for raising exceptions
>>>
>>>
>>>Guido explained that these days exceptions should always be raised as::
>>>
>>>raise SomeException("some argument")
>>>
>>>instead of::
>>>
>>>raise SomeException, "some argument"
>>>
>>>The second will go away in Python 3.0, and is only present now for backwards
>>>compatibility. (It was necessary when strings could be exceptions, in
>>>order to pass both the exception "type" and message.) PEPs 8_ and 3000_
>>>were accordingly updated.
>>
>>AFAIR, the second form was also meant to be able to defer
>>the instantiation of the exception class until really
>>needed in order to reduce the overhead related to raising
>>exceptions in Python.
>>
>>However, that optimization never made it into the implementation,
>>I guess.
>
>
> Something equivalent is used internally in the C code, but that
> doesn't mean we'll need it in Python code. The optimization only works
> if the exception is also *caught* in C code, BTW (it is instantiated
> as soon as it is handled by a Python except clause).
Ah, I knew it was in there somewhere (just couldn't find yesterday
when I was looking for the optimization :-).
> Originally, the second syntax was the only available syntax, because
> all we had were string exceptions. Now that string exceptions are dead
> (although not yet buried :) I really don't see why we need to keep
> both versions of the syntax; Python 3.0 will only have one version.
Actually, we do only have one version: the first syntax is just
a special case of the second (with the value argument set
to None).
I don't see a need for two or more syntaxes either, but most code
nowadays uses the second variant (I don't know of any code that
uses the traceback argument), which puts up a high barrier
for changes.
This is from a comment in ceval.c:
/* We support the following forms of raise:
raise ,
raise ,
raise , None
raise ,
raise , None
raise ,
raise , None
An omitted second argument is the same as None.
In addition, raise , 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 ".
I guess the reason for most code using the variante "raise
, " is that it simply looks a lot
like the corresponding "except , errorobj" clause.
> (We're still debating what to do with the traceback argument; wanna
> revive PEP 344?)
>
> If you need to raise exceptions fast, pre-instantiate an instance.
Ideally, I'd like Python to take care of such optimizations
rather than having to explicitly code for them:
If I write "raise ValueError, 'bad format'" and then
catch the error with just "except ValueError", there would
be no need for Python to actually instantiate the
exception object.
OTOH, lazy instantiation may have unwanted side-effects
(just like any lazy evaluation), e.g. the instantiation
could result in another exception to get raised.
Can't have 'em all, I guess.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
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] operator.c for release24-maint and test_bz2 on Python 2.4.1
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 - 2.29
+++ operator.c 26 Aug 2005 06:43:16 - 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
Re: [Python-Dev] operator.c for release24-maint and test_bz2 on Python 2.4.1
A.B., Khalid wrote:
> 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 - 2.29
> +++ operator.c 26 Aug 2005 06:43:16 - 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;
Thank you, that is corrected now.
> 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
[...]
> ==
> 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
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:
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')
Reinhold
--
Mail address is perfectly valid!
___
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] test_bz2 on Python 2.4.1
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 "", 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/
___
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] Style for raising exceptions (python-dev Summary for 2005-08-01 through 2005-08-15 [draft])
Marc-Andre Lemburg writes: > This is from a comment in ceval.c: > > /* We support the following forms of raise: > raise , > raise , > raise , None > raise , > raise , None > raise , > raise , None > > An omitted second argument is the same as None. > > In addition, raise , 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 ". 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 ___ 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] Style for raising exceptions (pytho n-dev Summary for 2005-08-01 through 2005-08-15 [draft])
On Friday 26 August 2005 09:15, Michael Chermside wrote: > 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. No kidding. The stuff about the tuples is particularly painful, but is specifically there to deal with string exceptions and the idiom that an exception could be defined as a tuple of exceptions. In fact, anydbm is particularly eggregious: it defines an error class derived from Exception, and then adds that to a tuple with the string exceptions from the specific modules it fronts for. The tuple handling in raise allows anydbm.error to be raised and then caught again abstractly, in addition to allow anydbm.error to act as a "base" exception that catches the specific errors raised by the backend databases. -Fred -- Fred L. Drake, Jr. ___ 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] [Python-checkins] python/dist/src/Lib/test test_bz2.py, 1.18, 1.19
[EMAIL PROTECTED] > 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 - 1.18 > +++ test_bz2.py 26 Aug 2005 13:23:54 - 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. ___ 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] [Python-checkins] python/dist/src/Lib/test test_bz2.py, 1.18, 1.19
Tim Peters wrote: > [EMAIL PROTECTED] >> 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 - 1.18 >> +++ test_bz2.py 26 Aug 2005 13:23:54 - 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. Thank you for correcting. The parenthesis must have been accidentally slipped in while I was reviewing the change for correctness. Reinhold -- Mail address is perfectly valid! ___ 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] PEP 342: simple example, closure alternative
On 8/25/05, Ian Bicking <[EMAIL PROTECTED]> wrote: > More generally, I've been doing some language comparisons, and I don't > like literal but non-idiomatic translations of programming patterns. True. (But that doesn't mean I think using generators for this example is great either.) > So I'm considering better ways to translate some of the same use cases. Remember that this particuar example was invented to show the superiority of Lisp; it has no practical value when taken literally. If you substitute a method call for the "acc += incr" operation, the Python translation using nested functions is very natural. For larger examples, I'd recommend defining a class as always. -- --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] PEP 342: simple example, closure alternative
Le Vendredi 26 Août 2005 16:57, Guido van Rossum a écrit : > On 8/25/05, Ian Bicking <[EMAIL PROTECTED]> wrote: > > More generally, I've been doing some language comparisons, and I don't > > like literal but non-idiomatic translations of programming patterns. > > True. (But that doesn't mean I think using generators for this example > is great either.) > > > So I'm considering better ways to translate some of the same use cases. > > Remember that this particuar example was invented to show the > superiority of Lisp; it has no practical value when taken literally. > If you substitute a method call for the "acc += incr" operation, the > Python translation using nested functions is very natural. For larger > examples, I'd recommend defining a class as always. For example, I often use this class to help me in functional programming : _marker = () class var: def __init__(self, v=None): self.v = v def __call__(self, v=_marker): if v is not _marker: self.v = v return self.v and so the nested functions become very functional : def accum(n): acc = var(n) return lambda incr: acc(acc()+incr) ___ 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] PEP 342: simple example, closure alternative
On Fri, Aug 26, 2005 at 06:21:58PM +0200, Alain Poirier wrote: > For example, I often use this class to help me in functional programming : > > _marker = () [...] You should not use an immutable object here (e.g. the empty tuple is shared). My preferred idiom is: _marker = object() Cheers, Neil ___ 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] Remove str.find in 3.0?
Can str.find be listed in PEP 3000 (under builtins) for removal? Would anyone really object? Reasons: 1. Str.find is essentially redundant with str.index. The only difference is that str.index Pythonically indicates 'not found' by raising an exception while str.find does the same by anomalously returning -1. As best as I can remember, this is common for Unix system calls but unique among Python builtin functions. Learning and remembering both is a nuisance. 2. As is being discussed in a current c.l.p thread, -1 is a legal indexing subscript. If one uses the return value as a subscript without checking, the bug is not caught. None would be a better return value should find not be deleted. 3. Anyone who prefers to test return values instead of catch exceptions can write (simplified, without start,end params): def sfind(string, target): try: return string.index(target) except ValueError: return None # or -1 for back compatibility, but None better This can of course be done for any function/method that indicates input errors with exceptions instead of a special return value. I see no reason other than history that this particular method should be doubled. If .find is scheduled for the dustbin of history, I would be willing to suggest doc and docstring changes. (str.index.__doc__ currently refers to str.find.__doc__. This should be reversed.) Terry J. Reedy ___ 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] Remove str.find in 3.0?
On 8/26/05, Terry Reedy <[EMAIL PROTECTED]> wrote: > Can str.find be listed in PEP 3000 (under builtins) for removal? Yes please. (Except it's not technically a builtin but a string method.) > Would anyone really object? Not me. > Reasons: > > 1. Str.find is essentially redundant with str.index. The only difference > is that str.index Pythonically indicates 'not found' by raising an > exception while str.find does the same by anomalously returning -1. As > best as I can remember, this is common for Unix system calls but unique > among Python builtin functions. Learning and remembering both is a > nuisance. > > 2. As is being discussed in a current c.l.p thread, -1 is a legal indexing > subscript. If one uses the return value as a subscript without checking, > the bug is not caught. None would be a better return value should find not > be deleted. > > 3. Anyone who prefers to test return values instead of catch exceptions can > write (simplified, without start,end params): > > def sfind(string, target): > try: > return string.index(target) > except ValueError: > return None # or -1 for back compatibility, but None better > > This can of course be done for any function/method that indicates input > errors with exceptions instead of a special return value. I see no reason > other than history that this particular method should be doubled. I'd like to add: 4. The no. 1 use case for str.find() used to be testing whether a substring was present or not; "if s.find(sub) >= 0" can now be written as "if sub in s". This avoids the nasty bug in "if s.find(sub)". > If .find is scheduled for the dustbin of history, I would be willing to > suggest doc and docstring changes. (str.index.__doc__ currently refers to > str.find.__doc__. This should be reversed.) -- --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] Remove str.find in 3.0?
> Can str.find be listed in PEP 3000 (under builtins) for removal? FWIW, here is a sample code transformation (extracted from zipfile.py). Judge for yourself whether the index version is better: Existing code: -- END_BLOCK = min(filesize, 1024 * 4) fpin.seek(filesize - END_BLOCK, 0) data = fpin.read() start = data.rfind(stringEndArchive) if start >= 0: # Correct signature string was found endrec = struct.unpack(structEndArchive, data[start:start+22]) endrec = list(endrec) comment = data[start+22:] if endrec[7] == len(comment): # Comment length checks out # Append the archive comment and start offset endrec.append(comment) endrec.append(filesize - END_BLOCK + start) return endrec return # Error, return None Revised code: - END_BLOCK = min(filesize, 1024 * 4) fpin.seek(filesize - END_BLOCK, 0) data = fpin.read() try: start = data.rindex(stringEndArchive) except ValueError: pass else: # Correct signature string was found endrec = struct.unpack(structEndArchive, data[start:start+22]) endrec = list(endrec) comment = data[start+22:] if endrec[7] == len(comment): # Comment length checks out # Append the archive comment and start offset endrec.append(comment) endrec.append(filesize - END_BLOCK + start) return endrec return # Error, return None ___ 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] Remove str.find in 3.0?
> Can str.find be listed in PEP 3000 (under builtins) for removal? > Would anyone really object? > > Reasons: . . . I had one further thought. In addition to your excellent list of reasons, it would be great if these kind of requests were accompanied by a patch that removed the offending construct from the standard library. The most important reason for the patch is that looking at the context diff will provide an objective look at how real code will look before and after the change. This would make subsequent discussions substantially more informed and less anecdotal. The second reason is that the revised library code becomes more likely to survive the transition to 3.0. Further, it can continue to serve as example code which highlights current best practices. This patch wouldn't take long. I've tried about a half dozen cases since you first posted. Each provided a new insight (zipfile was not improved, webbrowser was improved, and urlparse was about the same). 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
Re: [Python-Dev] Remove str.find in 3.0?
"Terry Reedy" <[EMAIL PROTECTED]> wrote: > > Can str.find be listed in PEP 3000 (under builtins) for removal? > Would anyone really object? I would object to the removal of str.find() . In fact, older versions of Python which only allowed for single-character 'x in str' containment tests offered 'str.find(...) != -1' as a suitable replacement option, which is found in the standard library more than a few times... Further, forcing users to use try/except when they are looking for the offset of a substring seems at least a little strange (if not a lot braindead, no offense to those who prefer their code to spew exceptions at every turn). I've been thinking for years that .find should be part of the set of operations offered to most, if not all sequences (lists, buffers, tuples, ...). Considering the apparent dislike/hatred for str.find, it seems I was wise in not requesting it in the past. > > Reasons: > > 1. Str.find is essentially redundant with str.index. The only difference > is that str.index Pythonically indicates 'not found' by raising an > exception while str.find does the same by anomalously returning -1. As > best as I can remember, this is common for Unix system calls but unique > among Python builtin functions. Learning and remembering both is a > nuisance. So pick one and forget the other. I think of .index as a list method (because it doesn't offer .find), not a string method, even though it is. > 2. As is being discussed in a current c.l.p thread, -1 is a legal indexing > subscript. If one uses the return value as a subscript without checking, > the bug is not caught. None would be a better return value should find not > be deleted. And would break potentially thousands of lines of code in the wild which expect -1 right now. Look in the standard library for starting examples, and google around for others. > 3. Anyone who prefers to test return values instead of catch exceptions can > write (simplified, without start,end params): > > def sfind(string, target): > try: > return string.index(target) > except ValueError: > return None # or -1 for back compatibility, but None better > > This can of course be done for any function/method that indicates input > errors with exceptions instead of a special return value. I see no reason > other than history that this particular method should be doubled. I prefer my methods to stay on my instances, and I could have sworn that the string module's functions were generally deprecated in favor of string methods. Now you are (implicitly) advocating the reversal of such for one method which doesn't return an exception under a very normal circumstance. Would you further request that .rfind be removed from strings? The inclusion of .rindex? - 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] Remove str.find in 3.0?
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On 8/26/05, Terry Reedy <[EMAIL PROTECTED]> wrote: >> Can str.find be listed in PEP 3000 (under builtins) for removal? > > Yes please. (Except it's not technically a builtin but a string method.) To avoid suggesting a new header, I interpreted Built-ins broadly to include builtin types. The header could be expanded to Built-in Constants, Functions, and Types or Built-ins and Built-in Types but I leave such details to the PEP authors. Terry J. Reedy ___ 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] Remove str.find in 3.0?
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >> Can str.find be listed in PEP 3000 (under builtins) for removal? > > FWIW, here is a sample code transformation (extracted from zipfile.py). > Judge for yourself whether the index version is better: I am sure that we both could write similar code that would be smoother if the math module also had a 'powhalf' function that was the same as sqrt except for returning -1 instead of raising an error on negative or non-numerical input. I'll continue in response to Josiah... Terry J. Reedy ___ 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] Remove str.find in 3.0?
"Josiah Carlson" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > "Terry Reedy" <[EMAIL PROTECTED]> wrote: >> >> Can str.find be listed in PEP 3000 (under builtins) for removal? Guido has already approved, but I will try to explain my reasoning a bit better for you. There are basically two ways for a system, such as a Python function, to indicate 'I cannot give a normal response." One (1a) is to give an inband signal that is like a normal response except that it is not (str.find returing -1). A variation (1b) is to give an inband response that is more obviously not a real response (many None returns). The other (2) is to not respond (never return normally) but to give an out-of-band signal of some sort (str.index raising ValueError). Python as distributed usually chooses 1b or 2. I believe str.find and .rfind are unique in the choice of 1a. I am pretty sure that the choice of -1 as error return, instead of, for instance, None, goes back the the need in static languages such as C to return something of the declared return type. But Python is not C, etcetera. I believe that this pair is also unique in having exact counterparts of type 2. (But maybe I forgot something.) >> Would anyone really object? > I would object to the removal of str.find(). So, I wonder, what is your favored alternative? A. Status quo: ignore the opportunity to streamline the language. B. Change the return type of .find to None. C. Remove .(r)index instead. D. Add more redundancy for those who do not like exceptions. > Further, forcing users to use try/except when they are looking for the > offset of a substring seems at least a little strange (if not a lot > braindead, no offense to those who prefer their code to spew exceptions > at every turn). So are you advocating D above or claiming that substring indexing is uniquely deserving of having two versions? If the latter, why so special? If we only has str.index, would you actually suggest adding this particular duplication? > Considering the apparent dislike/hatred for str.find. I don't hate str.find. I simply (a) recognize that a function designed for static typing constraints is out of place in Python, which does not have those constraints and (b) believe that there is no reason other than history for the duplication and (c) believe that dropping .find is definitely better than dropping .index and changing .find. > Would you further request that .rfind be removed from strings? Of course. Thanks for reminding me. > The inclusion of .rindex? Yes, the continued inclusion of .rindex, which we already have. Terry J. Reedy ___ 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] Remove str.find in 3.0?
> There are basically two ways for a system, such as a
> Python function, to indicate 'I cannot give a normal response." One (1a)
> is to give an inband signal that is like a normal response except that it
> is not (str.find returing -1). A variation (1b) is to give an inband
> response that is more obviously not a real response (many None returns).
> The other (2) is to not respond (never return normally) but to give an
> out-of-band signal of some sort (str.index raising ValueError).
>
> Python as distributed usually chooses 1b or 2. I believe str.find and
> .rfind are unique in the choice of 1a.
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
Might add a boolean "str.contains()" to cover this test case.
Bill
___
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] Remove str.find in 3.0?
On 8/26/05, Bill Janssen <[EMAIL PROTECTED]> 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/)
___
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] Remove str.find in 3.0?
On 8/26/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > I had one further thought. In addition to your excellent list of > reasons, it would be great if these kind of requests were accompanied by > a patch that removed the offending construct from the standard library. Um? Are we now requiring patches for PYTHON THREE DOT OH proposals? Raymond, we all know and agree that Python 3.0 will be incompatible in many ways. range() and keys() becoming iterators, int/int returning float, and so on; we can safely say that it will break nearly every module under the sun, and no amount of defensive coding in Python 2.x will save us. > The most important reason for the patch is that looking at the context > diff will provide an objective look at how real code will look before > and after the change. This would make subsequent discussions > substantially more informed and less anecdotal. No, you're just artificially trying to raise the bar for Python 3.0 proposals to an unreasonable height. > The second reason is that the revised library code becomes more likely > to survive the transition to 3.0. Further, it can continue to serve as > example code which highlights current best practices. But we don't *want* all of the library code to survive. Much of it is 10-15 years old and in dear need of a total rewrite. See Anthony Baxter's lightning talk at OSCON (I'm sure Google can find it for you). > This patch wouldn't take long. I've tried about a half dozen cases > since you first posted. Each provided a new insight (zipfile was not > improved, webbrowser was improved, and urlparse was about the same). So it's neutral in terms of code readability. Great. Given all the other advantages for the proposal (an eminent member of this group just posted a buggy example :-) I'm now doubly convinced that we should do it. Also remember, the standard library is rather atypical -- while some of it makes great example code, other parts of it are highly contorted in order to either maintain backwards compatibility or provide an unusually high level of defensiveness. -- --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] [Python-checkins] python/dist/src/Lib/test test_bz2.py, 1.18, 1.19
On Saturday 27 August 2005 00:46, Reinhold Birkenfeld wrote: > > 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. > > Thank you for correcting. The parenthesis must have been accidentally > slipped in while I was reviewing the change for correctness. Please ensure that you run the test suite before checking code in! Thanks, Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] Remove str.find in 3.0?
Don't know *what* I wasn't thinking :-).
Bill
> On 8/26/05, Bill Janssen <[EMAIL PROTECTED]> 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.
___
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] Remove str.find in 3.0?
"Terry Reedy" <[EMAIL PROTECTED]> wrote:
>
> "Josiah Carlson" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >
> > "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> >>
> >> Can str.find be listed in PEP 3000 (under builtins) for removal?
>
> Guido has already approved,
I noticed, but he approved before anyone could say anything. I
understand it is a dictatorship, but he seems to take advisment and
reverse (or not) his decisions on occasion based on additional
information. Whether this will lead to such, I don't know.
> but I will try to explain my reasoning a bit
> better for you. There are basically two ways for a system, such as a
> Python function, to indicate 'I cannot give a normal response." One (1a)
> is to give an inband signal that is like a normal response except that it
> is not (str.find returing -1). A variation (1b) is to give an inband
> response that is more obviously not a real response (many None returns).
> The other (2) is to not respond (never return normally) but to give an
> out-of-band signal of some sort (str.index raising ValueError).
>
> Python as distributed usually chooses 1b or 2. I believe str.find and
> .rfind are unique in the choice of 1a. I am pretty sure that the choice
> of -1 as error return, instead of, for instance, None, goes back the the
> need in static languages such as C to return something of the declared
> return type. But Python is not C, etcetera. I believe that this pair is
> also unique in having exact counterparts of type 2. (But maybe I forgot
> something.)
Taking a look at the commits that Guido did way back in 1993, he doesn't
mention why he added .find, only that he did. Maybe it was another of
the 'functional language additions' that he now regrets, I don't know.
> >> Would anyone really object?
>
> > I would object to the removal of str.find().
>
> So, I wonder, what is your favored alternative?
>
> A. Status quo: ignore the opportunity to streamline the language.
str.find is not a language construct. It is a method on a built-in type
that many people use. This is my vote.
> B. Change the return type of .find to None.
Again, this would break potentially thousands of lines of user code that
is in the wild. Are we talking about changes for 2.5 here, or 3.0?
> C. Remove .(r)index instead.
see below *
> D. Add more redundancy for those who do not like exceptions.
In 99% of the cases, such implementations would be minimal. While I
understand that "There should be one-- and preferably only one --obvious
way to do it.", please see below *.
> > Further, forcing users to use try/except when they are looking for the
> > offset of a substring seems at least a little strange (if not a lot
> > braindead, no offense to those who prefer their code to spew exceptions
> > at every turn).
>
> So are you advocating D above or claiming that substring indexing is
> uniquely deserving of having two versions? If the latter, why so special?
> If we only has str.index, would you actually suggest adding this particular
> duplication?
Apparently everyone has forgotten the dozens of threads on similar
topics over the years. I'll attempt to summarize.
Adding functionality that isn't used is harmful, but not nearly as
harmful as removing functionality that people use.
If you take just two seconds and do a search on '.find(' vs '.index(' in
the standard library, you will notice that '.find(' is used more often
than '.index(' regardless of type (I don't have the time this evening to
pick out which ones are string only, but I doubt the standard library
uses mmap.find, DocTestFinder.find, or gettext.find). This example
seems to show that people find str.find to be more intuitive and/or
useful than str.index, even though you spent two large paragraphs
explaining that Python 'doesn't do it that way very often so it isn't
Pythonic'. Apparently the majority of people who have been working on
the standard library for the last decade disagree.
> > Considering the apparent dislike/hatred for str.find.
>
> I don't hate str.find. I simply (a) recognize that a function designed for
> static typing constraints is out of place in Python, which does not have
> those constraints and (b) believe that there is no reason other than
> history for the duplication and (c) believe that dropping .find is
> definitely better than dropping .index and changing .find.
* I don't see why it is necessary to drop or change either one. We've
got list() and [] for construcing a list. Heck, we've even got
list(iterable) and [i for i in iterable] for making a list copy of any
arbitrary iterable. This goes against TSBOOWTDI, so why don't we toss
list comprehensions now that we have list(generator expression)? Or did
I miss something and this was already going to happen?
> > Would you further request that .rfind be removed from strings?
>
> Of course. Thanks for reminding me.
No problem, but again, do a search in the standard libr
Re: [Python-Dev] Remove str.find in 3.0?
Terry Reedy wrote: > One (1a) > is to give an inband signal that is like a normal response except that it > is not (str.find returing -1). > > Python as distributed usually chooses 1b or 2. I believe str.find and > .rfind are unique in the choice of 1a. That is not true. str.find's choice is not 1a, and there are other functions which chose 1a): -1 does *not* look like a normal response, since a normal response is non-negative. It is *not* the only method with choice 1a): dict.get returns None if the key is not found, even though None could also be the value for the key. For another example, file.read() returns an empty string at EOF. > I am pretty sure that the choice > of -1 as error return, instead of, for instance, None, goes back the the > need in static languages such as C to return something of the declared > return type. But Python is not C, etcetera. I believe that this pair is > also unique in having exact counterparts of type 2. dict.__getitem__ is a counterpart of type 2 of dict.get. > So, I wonder, what is your favored alternative? > > A. Status quo: ignore the opportunity to streamline the language. My favourite choice is the status quo. I probably don't fully understand the word "to streamline", but I don't see this as rationalizing. Instead, some applications will be more tedious to write. > So are you advocating D above or claiming that substring indexing is > uniquely deserving of having two versions? If the latter, why so special? Because it is no exception that a string is not part of another string, and because the question I'm asking "is the string in the other string, and if so, where?". This is similar to the question "does the dictionary have a value for that key, and if so, which?" > If we only has str.index, would you actually suggest adding this particular > duplication? That is what happened to dict.get: it was not originally there (I believe), but added later. 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
