Re: [Python-Dev] Any detail list of change between version2.1-2.2-2.3-2.4 of Python?
"FAN" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > You know Jython (Java version of Python) has only a stable version of > 2.1, and two alpha version was release after 3 years. > So if it wants to evolve to 2.2 , 2.3 or 2.4 as Python, some detail > change list was need, and it's great if there are some test case > script to test the new implemention version. > So does Python has this kinds of things? Where can I find them or > something like this? I believe this question is off-topic here, which is for dicussion of future changes. If you ask the same question on comp.lang.python or the mail or gmane.org equivalent, or perhaps in the search box at python.org, I am sure you will get an answer. Terry J. Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
Donovan Baarda <[EMAIL PROTECTED]> wrote: > > On Sat, 2005-08-27 at 10:16 -0700, Josiah Carlson wrote: > > Guido van Rossum <[EMAIL PROTECTED]> wrote: > [...] > > Oh, there's a good thing to bring up; regular expressions! re.search > > returns a match object on success, None on failure. With this "failure > > -> Exception" idea, shouldn't they raise exceptions instead? And > > goodness, defining a good regular expression can be quite hard, possibly > > leading to not insignificant "my regular expression doesn't do what I > > want it to do" bugs. Just look at all of those escape sequences and the > > syntax! It's enough to make a new user of Python gasp. > > I think re.match() returning None is an example of 1b (as categorised by > Terry Reedy). In this particular case a 1b style response is OK. Why; My tongue was firmly planted in my cheek during my discussion of regular expressions. I was using it as an example of when one starts applying some arbitrary rule to one example, and not noticing other examples that do very similar, if not the same thing. [snip discussion of re.match, re.search, str.find] If you are really going to compare re.match, re.search and str.find, you need to point out that neither re.match nor re.search raise an exception when something isn't found (only when you try to work with None). This puts str.index as the odd-man-out in this discussion of searching a string - so the proposal of tossing str.find as the 'weird one' is a little strange. One thing that has gotten my underwear in a twist is that no one has really offered up a transition mechanism from "str.find working like now" and some future "str.find or lack of" other than "use str.index". Obviously, I personally find the removal of str.find to be a nonstarter (don't make me catch exceptions or use regular expressions when both are unnecessary, please), but a proper transition of str.find from -1 to None on failure would be beneficial (can which one be chosen at runtime via __future__ import?). During a transition which uses __future__, it would encourage the /proper/ use of str.find in all modules and extensions in which use it... x = y.find(z) if x >= 0: #... Forcing people to use the proper semantic in their modules so as to be compatible with other modules which may or may not use str.find returns None, would (I believe) result in an overall reduction (if not elimination) of bugs stemming from str.find, and would prevent former str.find users from stumbling down the try/except/else misuse that Tim Peters highlighted. Heck, if you can get the __future__ import working for choosing which str.find to use (on a global, not per-module basis), I say toss it into 2.6, or even 2.5 if there is really a push for this prior to 3.0 . - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Any detail list of change between version 2.1-2.2-2.3-2.4 of Python?
hi, all You know Jython (Java version of Python) has only a stable version of 2.1, and two alpha version was release after 3 years. So if it wants to evolve to 2.2 , 2.3 or 2.4 as Python, some detail change list was need, and it's great if there are some test case script to test the new implemention version. So does Python has this kinds of things? Where can I find them or something like this? Regards FAN ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
On Sat, 2005-08-27 at 10:16 -0700, Josiah Carlson wrote: > Guido van Rossum <[EMAIL PROTECTED]> wrote: [...] > Oh, there's a good thing to bring up; regular expressions! re.search > returns a match object on success, None on failure. With this "failure > -> Exception" idea, shouldn't they raise exceptions instead? And > goodness, defining a good regular expression can be quite hard, possibly > leading to not insignificant "my regular expression doesn't do what I > want it to do" bugs. Just look at all of those escape sequences and the > syntax! It's enough to make a new user of Python gasp. I think re.match() returning None is an example of 1b (as categorised by Terry Reedy). In this particular case a 1b style response is OK. Why; 1) any successful match evaluates to "True", and None evaluates to "False". This allows simple code like; if myreg.match(s): do something. Note you can't do this for find, as 0 is a successful "find" and evaluates to False, whereas other results including -1 evaluate to True. Even worse, -1 is a valid index. 2) exceptions are for unexpected events, where unexpected means "much less likely than other possibilities". The re.match() operation asks "does this match this", which implies you have an about even chance of not matching... ie a failure to match is not unexpected. The result None makes sense... "what match did we get? None, OK". For str.index() you are asking "give me the index of this inside this", which implies you expect it to be in there... ie not finding it _is_ unexpected, and should raise an exception. Note that re.match() returning None will raise exceptions if the rest of your code doesn't expect it; index = myreg.match(s).start() tail = s[index:] This will raise an exception if there was no match. Unlike str.find(); index = s.find(r) tail = s[index:] Which will happily return the last character if there was no match. This is why find() should return None instead of -1. > With the existance of literally thousands of uses of .find and .rfind in > the wild, any removal consideration should be weighed heavily - which > honestly doesn't seem to be the case here with the ~15 minute reply time > yesterday (just my observation and opinion). If you had been ruminating > over this previously, great, but that did not seem clear to me in your > original reply to Terry Reedy. bare in mind they are talking about Python 3.0... I think :-) -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
On 8/27/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > With the existance of literally thousands of uses of .find and .rfind in > the wild, any removal consideration should be weighed heavily - which > honestly doesn't seem to be the case here with the ~15 minute reply time > yesterday (just my observation and opinion). If you had been ruminating > over this previously, great, but that did not seem clear to me in your > original reply to Terry Reedy. I hadn't been ruminating about deleting it previously, but I was well aware of the likelihood of writing buggy tests for find()'s return value. I believe that str.find() is not just something that can be used to write buggy code, but something that *causes* bugs over and over again. (However, see below.) The argument that there are thousands of usages in the wild doesn't carry much weight when we're talking about Python 3.0. There are at least a similar number of modules that expect dict.keys(), zip() and range() to return lists, or that depend on the distinction between Unicode strings and 8-bit strings, or on bare except:, on any other feature that is slated for deletion in Python 3.0 for which the replacement requires careful rethinking of the code rather than a mechanical translation. The *premise* of Python 3.0 is that it drops backwards compatibility in order to make the language better in the long term. Surely you believe that the majority of all Python programs have yet to be written? The only argument in this thread in favor of find() that made sense to me was Tim Peters' observation that the requirement to use a try/except clause leads to another kind of sloppy code. It's hard to judge which is worse -- the buggy find() calls or the buggy/cumbersome try/except code. Note that all code (unless it needs to be backwards compatible to Python 2.2 and before) which is using find() to merely detect whether a given substring is present should be using 's1 in s2' instead. Another observation: despite the derogatory remarks about regular expressions, they have one thing going for them: they provide a higher level of abstraction for string parsing, which this is all about. (They are higher level in that you don't have to be counting characters, which is about the lowest-level activity in programming -- only counting bytes is lower!) Maybe if we had a *good* way of specifying string parsing we wouldn't be needing to call find() or index() so much at all! (A good example is the code that Raymond lifted from ConfigParser: a semicolon preceded by whitespace starts a comment, other semicolons don't. Surely there ought to be a better way to write that.) All in all, I'm still happy to see find() go in Python 3.0, but I'm leaving the door ajar: if you read this post carefully, you'll know what arguments can be used to persuade me. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0 blocks?
On 8/27/05, Aahz <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 27, 2005, Guido van Rossum wrote:
> >
> > if vi in ('=',':'):
> > try: pos = optval.index(';')
> > except ValueError: pass
> > else:
> > if pos > 0 and optval[pos-1].isspace():
> > optval = optval[:pos]
>
> IIRC, one of your proposals for Python 3.0 was that single-line blocks
> would be banned. Is my memory wrong?
It's a proposal. I'm on the fence about it. I was just trying to get
the posting out quick before my family came knowcking on my door. :)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] empty string api for files
On 8/27/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > For reading bytes, I *know* that a lot of code would become uglier if > > the API changed to raise EOFError exceptions > > I had StopIteration in mind. Instead of writing: > > while 1: > block = f.read(20) > if line == '': > break > . . . > > We would use: > > for block in f.readblocks(20): > . . . > > More beauty, a little faster, more concise, and less error-prone. Of > course, there are likely better choices for the method name, but you get > the gist of it. I'm not convinced. Where would you ever care about reading a file in N-bytes chucks? I really think you've got a solution in search of a problem by the horns here. While this would be useful for a copying loop, it falls down for most practical uses of reading bytes (e.g. reading GIF or WAVE file). I've thought a lot about redesigning the file/stream API, but the problems thi API change would solve just aren't high on my list. Much more important are transparency of the buffering (for better integration with select()), and various translations like universal newlines or character set encodings. Some of my work on this is nondist/sandbox/sio/. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] empty string api for files
Raymond Hettinger wrote: > We would use: > for block in f.readblocks(20): > . . . What would be nice is a reader that allows a range of bytes. Often when you read a chunk, you don't care about the exact size you get, example uses include the re-blocking that makes reading from compressed data sources unnecessarily inefficient. --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 3.0 blocks?
On Sat, Aug 27, 2005, Guido van Rossum wrote:
>
> if vi in ('=',':'):
> try: pos = optval.index(';')
> except ValueError: pass
> else:
> if pos > 0 and optval[pos-1].isspace():
> optval = optval[:pos]
IIRC, one of your proposals for Python 3.0 was that single-line blocks
would be banned. Is my memory wrong?
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/
The way to build large Python applications is to componentize and
loosely-couple the hell out of everything.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
On 8/26/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > 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.) > Done. Added an "Atomic Types" section to the PEP as well. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 8/26/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > 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. > > There's nothing functional about it. I remember adding it after > finding it cumbersome to write code using index/rindex. However, that > was long before we added startswith(), endswith(), and 's in t' for > multichar s. Clearly all sorts of varieties of substring matching are > important, or we wouldn't have so many methods devoted to it! (Not to > mention the 're' module.) > > However, after 12 years, I believe that the small benefit of having > find() is outweighed by the frequent occurrence of bugs in its use. Oh, there's a good thing to bring up; regular expressions! re.search returns a match object on success, None on failure. With this "failure -> Exception" idea, shouldn't they raise exceptions instead? And goodness, defining a good regular expression can be quite hard, possibly leading to not insignificant "my regular expression doesn't do what I want it to do" bugs. Just look at all of those escape sequences and the syntax! It's enough to make a new user of Python gasp. Most of us are consenting adults here. If someone writes buggy code with str.find, that is unfortunate, maybe they should have used regular expressions and tested for None, maybe they should have used str.startswith (which is sometimes slower than m == n[:len(m)], but I digress), maybe they should have used str.index. But just because buggy code can be written with it, doesn't mean that it should be removed. Buggy code can, will, and has been written with every Python mechanism that has ever existed or will ever exist. With the existance of literally thousands of uses of .find and .rfind in the wild, any removal consideration should be weighed heavily - which honestly doesn't seem to be the case here with the ~15 minute reply time yesterday (just my observation and opinion). If you had been ruminating over this previously, great, but that did not seem clear to me in your original reply to Terry Reedy. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_bz2 on Python 2.4.1
[Reinhold Birkenfeld] > Could anyone else on Windows please try the test_bz2, too? test_bz2 works fine here, on WinXP Pro SP2, under release and debug builds, on current CVS HEAD and on current CVS release24-maint branch. I built those 4 Pythons with the MS compiler, not MinGW. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
[Tim] > You probably want "except ValueError:" in all these, not "except > ValueError():". Right. I was misremembering the new edict to write: raise ValueError() Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
[Raymond Hettinger, rewrites some code]
> ...
> --- StringIO.py ---
>
> i = self.buf.find('\n', self.pos)
> if i < 0:
>newpos = self.len
> else:
>newpos = i+1
> . . .
>
>
> try:
>i = self.buf.find('\n', self.pos)
> except ValueError():
>newpos = self.len
> else:
>newpos = i+1
> . . .
You probably want "except ValueError:" in all these, not "except ValueError():".
Leaving that alone, the last example particularly shows one thing I
dislike about try/except here: in a language with properties, how is
the code reader supposed to guess that it's specifically and only the
.find() call that _can_ raise ValueError in
i = self.buf.find('\n', self.pos)
? I agree it's clear enough here from context, but there's no
confusion possible on this point in the original spelling: it's
immediately obvious that the result of find() is the only thing being
tested. There's also strong temptation to slam everything into the
'try' block, and reduce nesting:
newpos = self.len
try:
newpos = self.buf.find('\n', self.pos) + 1
except ValueError:
pass
I've often seen code in the wild with, say, two-three dozen lines in a
``try`` block, with an "except AttributeError:" that was _intended_ to
catch an expected AttributeError only in the second of those lines.
Of course that hides legitimate bugs too. Like ``object.attr``, the
result of ``string.find()`` is normally used in further computation,
so the temptation is to slam the computation inside the ``try`` block
too.
.find() is a little delicate to use, but IME sloppy try/except
practice (putting much more in the ``try`` block than the specific
little operation where an exception is expected) is common, and harder
to get people to change because it requires thought instead of just
reading the manual to see that -1 means "not there" <0.5 wink>.
Another consideration is code that needs to use .find() a _lot_. In
my programs of that sort, try/except is a lot more expensive than
letting -1 signal "not there".
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Remove str.find in 3.0?
[Guido] > However, after 12 years, I believe that the small benefit of having > find() is outweighed by the frequent occurrence of bugs in its use. My little code transformation exercise is bearing that out. Two of the first four cases in the standard library were buggy :-( Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test_bz2 fails on Python 2.4.1 from CVS, passes on same from source archieve
Okay here is the output of test_bz2 on Python 2.4.1 updated and compiled fresh from CVS, and on Python 2.4.1 from the source archieve from python.org (http://www.python.org/ftp/python/2.4.1/Python-2.4.1.tar.bz2). #- # Python 2.4.1 compiled from source archieve: # Result: passes #- $ cd /g/projs/py241-src-arc/mingw $ python ../Lib/test/test_bz2.py testIterator (__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 31 tests in 6.430s OK #- # Python 2.4.1 compiled from CVS updated even today: # Result: fails #- $ cd /g/projs/py24/python/dist/src/MinGW $ 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 5.980s 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
Re: [Python-Dev] Remove str.find in 3.0?
On Sat, 27 Aug 2005 16:46:07 +0200, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> On 8/27/05, Wolfgang Lipp <[EMAIL PROTECTED]> wrote:
>> i never expected .get()
>> to work that way (return an unsolicited None) -- i do consider this
>> behavior harmful and suggest it be removed.
>
> That's a bizarre attitude. You don't read the docs and hence you want
> a feature you weren't aware of to be removed?
i do read the docs, and i believe i do keep a lot of detail in my
head. every now and then, tho, you piece sth together using a logic
that is not 100% the way it was intended, or the way it came about.
let me say that for someone who did developement for python for
a while it is natural to know that ~.get() is there for avoidance
of exceptions, and default values are an afterthought, but for someone
who did developement *with* python (and lacks experience of the other
side) this ain't necessarily so. that said, i believe it to be
more expressive and safer to demand ~.get('x',None) to be written
to achieve the present behavior, and let ~.get('x') raise an
exception. personally, i can live with either way, and am happier
the second. just my thoughts.
> I'm glad you're not on *my* team. (Emphasis mine. :-)
i wonder what that would be like.
_wolf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] empty string api for files
> For reading bytes, I *know* that a lot of code would become uglier if > the API changed to raise EOFError exceptions I had StopIteration in mind. Instead of writing: while 1: block = f.read(20) if line == '': break . . . We would use: for block in f.readblocks(20): . . . More beauty, a little faster, more concise, and less error-prone. Of course, there are likely better choices for the method name, but you get the gist of it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
On 8/26/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > 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. There's nothing functional about it. I remember adding it after finding it cumbersome to write code using index/rindex. However, that was long before we added startswith(), endswith(), and 's in t' for multichar s. Clearly all sorts of varieties of substring matching are important, or we wouldn't have so many methods devoted to it! (Not to mention the 're' module.) However, after 12 years, I believe that the small benefit of having find() is outweighed by the frequent occurrence of bugs in its use. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_bz2 on Python 2.4.1
A.B., Khalid wrote: >>>#--- Python 2.4.1 from CVS -# [test_bz2] >>>RuntimeError: wrong sequence of bz2 library commands used >> >>I don't understand this. The sources for the bz2 modules are exactly equal >>in both branches. > > I know. Even the tests are equal. I didn't say that these files are to > blame, I just said that the test is failing in Python 2.4.1 on Windows. > cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/python login > cvs -z7 -d :pserver:[EMAIL PROTECTED]:/cvsroot/python update -dP > -r release24-maint python > > And it is, more or less, the same way I check out other branches. No problem here, just eliminating possibilities. Could anyone else on Windows please try the test_bz2, too? Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
On 8/27/05, Wolfgang Lipp <[EMAIL PROTECTED]> wrote: > i never expected .get() > to work that way (return an unsolicited None) -- i do consider this > behavior harmful and suggest it be removed. That's a bizarre attitude. You don't read the docs and hence you want a feature you weren't aware of to be removed? I'm glad you're not on *my* team. (Emphasis mine. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
On 8/27/05, Kay Schluehr <[EMAIL PROTECTED]> wrote: > The discourse about Python3000 has shrunken from the expectation of the > "next big thing" into a depressive rhetorics of feature elimination. > The language doesn't seem to become deeper, smaller and more powerfull > but just smaller. I understand how your perception reading python-dev would make you think that, but it's not true. There is much focus on removing things, because we want to be able to add new stuff but we don't want the language to grow. Python-dev is (correctly) very focused on the status quo and the near future, so discussions on what can be removed without hurting are valuable here. Discussions on what to add should probably happen elsewhere, since the proposals tend to range from genius to insane (sometimes within one proposal :-) and the discussion tends to become even more rampant than the discussions about changes in 2.5. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
Raymond Hettinger wrote: > [Martin] >> For another example, file.read() returns an empty string at EOF. > > When my turn comes for making 3.0 proposals, I'm going to recommend > nixing the "empty string at EOF" API. That is a carry-over from C that > made some sense before there were iterators. Now, we have the option of > introducing much cleaner iterator versions of these methods that use > compact, fast, and readable for-loops instead of multi-statement > while-loop boilerplate. I think for char in iter(lambda: f.read(1), ''): pass is not bad, too. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
On 8/27/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> --- From ConfigParser.py ---
>
> optname, vi, optval = mo.group('option', 'vi', 'value')
> if vi in ('=', ':') and ';' in optval:
> # ';' is a comment delimiter only if it follows
> # a spacing character
> pos = optval.find(';')
> if pos != -1 and optval[pos-1].isspace():
> optval = optval[:pos]
> optval = optval.strip()
> . . .
>
>
> optname, vi, optval = mo.group('option', 'vi', 'value')
> if vi in ('=', ':') and ';' in optval:
> # ';' is a comment delimiter only if it follows
> # a spacing character
> try:
> pos = optval.index(';')
> except ValueError():
I'm sure you meant "except ValueError:"
> pass
> else:
> if optval[pos-1].isspace():
> optval = optval[:pos]
> optval = optval.strip()
> . . .
That code is buggy before and after the transformation -- consider
what happens if optval *starts* with a semicolon. Also, the code is
searching optval for ';' twice. Suggestion:
if vi in ('=',':'):
try: pos = optval.index(';')
except ValueError: pass
else:
if pos > 0 and optval[pos-1].isspace():
optval = optval[:pos]
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
On 8/27/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Martin] > > For another example, file.read() returns an empty string at EOF. > > When my turn comes for making 3.0 proposals, I'm going to recommend > nixing the "empty string at EOF" API. That is a carry-over from C that > made some sense before there were iterators. Now, we have the option of > introducing much cleaner iterator versions of these methods that use > compact, fast, and readable for-loops instead of multi-statement > while-loop boilerplate. -1. For reading lines we already have that in the status quo. For reading bytes, I *know* that a lot of code would become uglier if the API changed to raise EOFError exceptions. It's not a coincidence that raw_input() raises EOFError but readline() doesn't -- the readline API was designed after externsive experience with raw_input(). The situation is different than for find(): - there aren't two APIs that only differ in their handling of the exceptional case - the error return value tests false and all non-error return values tests true - in many cases processing the error return value the same as non-error return values works just fine (as long as you have another way to test for termination) Also, even if read() raised EOFError instead of returning '', code that expects certain data wouldn't be simplified -- after attempting to read e.g. 4 bytes, you'd still have to check that you got exactly 4, so there'd be three cases to handle (EOFError, short, good) instead of two (short, good). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test_bz2 on Python 2.4.1
Reinhold Birkenfeld wrote: #--- 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 I don't understand this. The sources for the bz2 modules are exactly equal in both branches. I know. Even the tests are equal. I didn't say that these files are to blame, I just said that the test is failing in Python 2.4.1 on Windows. How do you check out the 2.4.1 from CVS? Well, I've been updating Python from CVS from more than a year now and I doubt that this is the problem. After all, Python 2.3.5 is passing the regrtests, and last time I checked, so is Python 2.5a0. Python 2.4.1 was also passing all the regtests until recently (not sure exatcly when, but it could be about a month ago). But anyway, here is how I update my copy of Python 2.4 from CVS. Roughly, cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/python login [Enter] cvs -z7 -d :pserver:[EMAIL PROTECTED]:/cvsroot/python update -dP -r release24-maint python And it is, more or less, the same way I check out other branches. I will download the Python 2.4.1 source archieve and to build it to see what happens. I'll report back when I am done. Regards, Khalid _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
kay,
your suggestion makes perfect sense for me, i haven't actually tried
the examples tho. guess there could be a find() or index() or
indices() or iterIndices() ??? function 'f' roughly with these arguments:
def f( x, element, start = 0, stop = None, default = _Misfit, maxcount =
None, reverse = False )
that iterates over the indices of x where element (a substring, key, or
value in a sequence or iterator) is found, raising sth. like IndexError
when nothing at all is found except when default is not '_Misfit'
(mata-None),
and starts looking from the right end when reverse is True (this *may*
imply that reversed(x) is done on x where no better implementation is
available). not quite sure whether it makes sense to me to always return
default as the last value of the iteration -- i tend to say rather not.
ah yes, only up to maxcount indices are yielded.
bet it said that passing an iterator for x would mean that the iterator is
gone
up to where the last index was yielded; passing an iterator is not
acceptable for reverse = True.
MHO,
_wolf
On Sat, 27 Aug 2005 14:57:08 +0200, Kay Schluehr <[EMAIL PROTECTED]>
wrote:
>
> def keep(iter, default=None):
> try:
> return iter.next()
> except StopIteration:
> return default
>
> Together with an index iterator the user can mimic the behaviour he
> wants. Instead of a ValueError a StopIteration exception can hold as
> an "external" information ( other than a default value ):
>
> >>> keep( "abcdabc".index("bc"), default=-1) # current behaviour of the
># find() function
> >>> (idx for idx in "abcdabc".rindex("bc")) # generator expression
>
>
> Since the find() method acts on a string literal it is not easy to
> replace it syntactically. But why not add functions that can be hooked
> into classes whose objects are represented by literals?
>
> def find( string, substring):
> return keep( string.index( substring), default=-1)
>
> str.register(find)
>
> >>> "abcdabc".find("bc")
> 1
>
> Now find() can be stored in a pure Python module without maintaining it
> on interpreter level ( same as with reduce, map and filter ).
>
> Kay
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
Wolfgang Lipp wrote: > > Just because you don't read the documentation and guessed wrong > > d.get() needs to be removed?!? > > no, not removed... never said that. Fair enough, you proposed to remove the behavior. Not sure how that's all that much less bad, though... > implied). the reason of being for d.get() -- to me -- is simply so you > get a chance to pass a default value, which is syntactically well-nigh > impossible with d['x']. Close, but the main reason to add d.get() was to avoid the exception. The need to specify a default value followed from that. Just ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
FWIW, here are three more comparative code fragments. They are
presented without judgment as an evaluation tool to let everyone form
their own opinion about the merits of each:
--- From CGIHTTPServer.py ---
def run_cgi(self):
"""Execute a CGI script."""
dir, rest = self.cgi_info
i = rest.rfind('?')
if i >= 0:
rest, query = rest[:i], rest[i+1:]
else:
query = ''
i = rest.find('/')
if i >= 0:
script, rest = rest[:i], rest[i:]
else:
script, rest = rest, ''
. . .
def run_cgi(self):
"""Execute a CGI script."""
dir, rest = self.cgi_info
try:
i = rest.rindex('?')
except ValueError():
query = ''
else:
rest, query = rest[:i], rest[i+1:]
try:
i = rest.index('/')
except ValueError():
script, rest = rest, ''
else:
script, rest = rest[:i], rest[i:]
. . .
--- From ConfigParser.py ---
optname, vi, optval = mo.group('option', 'vi', 'value')
if vi in ('=', ':') and ';' in optval:
# ';' is a comment delimiter only if it follows
# a spacing character
pos = optval.find(';')
if pos != -1 and optval[pos-1].isspace():
optval = optval[:pos]
optval = optval.strip()
. . .
optname, vi, optval = mo.group('option', 'vi', 'value')
if vi in ('=', ':') and ';' in optval:
# ';' is a comment delimiter only if it follows
# a spacing character
try:
pos = optval.index(';')
except ValueError():
pass
else:
if optval[pos-1].isspace():
optval = optval[:pos]
optval = optval.strip()
. . .
--- StringIO.py ---
i = self.buf.find('\n', self.pos)
if i < 0:
newpos = self.len
else:
newpos = i+1
. . .
try:
i = self.buf.find('\n', self.pos)
except ValueError():
newpos = self.len
else:
newpos = i+1
. . .
My notes so far weren't meant to judge the proposal. I'm just
suggesting that examining fragments like the ones above will help inform
the design process.
Peace,
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
Terry Reedy wrote:
>>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.
I actually don't see much benefits from the user perspective. The
discourse about Python3000 has shrunken from the expectation of the
"next big thing" into a depressive rhetorics of feature elimination.
The language doesn't seem to become deeper, smaller and more powerfull
but just smaller.
> 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.
Why not turning index() into an iterator that yields indices
sucessively? From this generalized perspective we can try to reconstruct
behaviour of Python 2.X.
Sometimes I use a custom keep() function if I want to prevent defining a
block for catching StopIteration. The keep() function takes an iterator
and returns a default value in case of StopIteration:
def keep(iter, default=None):
try:
return iter.next()
except StopIteration:
return default
Together with an index iterator the user can mimic the behaviour he
wants. Instead of a ValueError a StopIteration exception can hold as
an "external" information ( other than a default value ):
>>> keep( "abcdabc".index("bc"), default=-1) # current behaviour of the
# find() function
>>> (idx for idx in "abcdabc".rindex("bc")) # generator expression
Since the find() method acts on a string literal it is not easy to
replace it syntactically. But why not add functions that can be hooked
into classes whose objects are represented by literals?
def find( string, substring):
return keep( string.index( substring), default=-1)
str.register(find)
>>> "abcdabc".find("bc")
1
Now find() can be stored in a pure Python module without maintaining it
on interpreter level ( same as with reduce, map and filter ).
Kay
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Style for raising exceptions (python-dev Summary for 2005-08-01 through 2005-08-15 [draft])
MAL> I don't see a need for two or more syntaxes either, but most code MAL> nowadays uses the second variant (I don't know of any code that MAL> uses the traceback argument), which puts up a high barrier for MAL> changes. Earlier this week I managed to fix all the instances in the projects I'm involved with at my day job in a couple rounds of grep/emacs macro sessions. It took all of about 20 minutes, so I don't think the conversion will be onerous. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
On Sat, 27 Aug 2005 13:01:02 +0200, Just van Rossum <[EMAIL PROTECTED]>
wrote:
> Just because you don't read the documentation and guessed wrong d.get()
> needs to be removed?!?
no, not removed... never said that.
> It's a *feature* of d.get(k) to never raise KeyError. If you need an
> exception, why not just use d[k]?
i agree i misread the specs, but then, i read the specs a lot, and
i guess everyone here agrees that if it's in the specs doesn't mean
it's automatically what we want or expect -- else there's nothing to
discuss. i say
d.get('x') == None
<==
{ ( 'x' not in d ) OR ( d['x'] == None ) }
is not what i expect (even tho the specs say so) especially since
d.pop('x') *does* throw a KeyError when 'x' is not a key in mydict.
ok, pop is not get and so on but still i perceive this a problematic
behavior (to the point i call it a 'bug' in a jocular way, no offense
implied). the reason of being for d.get() -- to me -- is simply so you
get a chance to pass a default value, which is syntactically well-nigh
impossible with d['x'].
_wolf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
Wolfgang Lipp wrote: > On Sat, 27 Aug 2005 12:35:30 +0200, Martin v. Löwis <[EMAIL PROTECTED]> > wrote: > > P.S. Emphasis mine :-) > > no, emphasis all **mine** :-) just to reflect i never expected .get() > to work that way (return an unsolicited None) -- i do consider this > behavior harmful and suggest it be removed. Just because you don't read the documentation and guessed wrong d.get() needs to be removed?!? It's a *feature* of d.get(k) to never raise KeyError. If you need an exception, why not just use d[k]? Just ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
On Sat, 27 Aug 2005 12:35:30 +0200, Martin v. Löwis <[EMAIL PROTECTED]> wrote: > P.S. Emphasis mine :-) no, emphasis all **mine** :-) just to reflect i never expected .get() to work that way (return an unsolicited None) -- i do consider this behavior harmful and suggest it be removed. _wolf ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
Wolfgang Lipp wrote: > that's a bug! i had to *test* it to find out it's true! i've been writing > code for *years* all in the understanding that dict.get(x) acts precisely > like dict['x'] *except* you get a chance to define a default value. Clearly, your understanding *all* these years *was* wrong. If you don't specify *a* default value, *it* defaults to None. Regards, Martin P.S. Emphasis mine :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
On Sat, 27 Aug 2005 08:54:12 +0200, Martin v. Löwis <[EMAIL PROTECTED]>
wrote:
> with choice 1a): dict.get returns None if the key is not found, even
> though None could also be the value for the key.
that's a bug! i had to *test* it to find out it's true! i've been writing
code for *years* all in the understanding that dict.get(x) acts precisely
like dict['x'] *except* you get a chance to define a default value. which,
for me, has become sort of a standard solution to the problem the last ten
or so postings were all about: when i write a function and realize that's
one of the cases where python philosophy strongly favors raising an
exception
because something e.g. could not be found where expected, i make it so that
a reasonable exception is raised *and* where meaningful i give consumers
a chance to pass in a default value to eschew exceptions. i believe
this is the way to go to resolve this .index/.find conflict. and, no,
returning -1 when a substring is not found and None when a key is not
found is *highly* problematic. i'd sure like to see cases like that to go.
i'm not sure why .rindex() should go (correct?), and how to do what it does
(reverse the string before doing .index()? is that what is done
internally?)
and of course, like always, there is the question why these are methods
at all and why there is a function len(str) but a method str.index(); one
could just as well have *either* str.length and str.index() *or*
length(str) and, say, a builtin
locate( x, element, start = 0 , stop = None, reversed = False, default =
Misfit )
(where Misfit indicates a 'meta-None', so None is still a valid default
value;
i also like to indicate 'up to the end' with stop=None) that does on
iterables
(or only on sequences) what the methods do now, but with this strange
pattern:
--
.index() .find() .get() .pop()
list + ?(3) +
tuple ?(3) ??(1)
str++ ?(3) ??(1)
dict x(2) x(2) + +
(1) one could argue this should return a copy of a tuple or str,
but doubtful. (2) index/find meaningless for dicts. (3) there
is no .get() for list, tuple, str, although it would make sense:
return the indexed element, or raise IndexError where not found
if no default return value given.
--
what bites me here is expecially that we have both index and find
for str *but a gaping hole* for tuples. assuming tuples are not slated
for removal, i suggest to move in a direction that makes things look
more like this:
--
.index() .get() .pop()
list + + +
tuple + +
str+ +
dict + +
--
where .index() looks like locate, above:
--
{list,tuple,str}.index(
element,# element in the collection
start = 0, # where to start searching; default is zero
stop = None,# where to end; the default, None, indicates
# 'to the end'
reversed = False, # should we search from the back? *may* cause
# reversion of sequence, depending on impl.
default = _Misfit, # default value, when given, prevents
# IndexError from being raised
)
--
hope i didn't miss out crucial points here.
_wolf
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_bz2 on Python 2.4.1
A.B., Khalid wrote: > #--- 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 I don't understand this. The sources for the bz2 modules are exactly equal in both branches. How do you check out the 2.4.1 from CVS? Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
[Martin] > For another example, file.read() returns an empty string at EOF. When my turn comes for making 3.0 proposals, I'm going to recommend nixing the "empty string at EOF" API. That is a carry-over from C that made some sense before there were iterators. Now, we have the option of introducing much cleaner iterator versions of these methods that use compact, fast, and readable for-loops instead of multi-statement while-loop boilerplate. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
> > 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. Not really. I'm mostly for the proposal (+0), but am certain the conversation about the proposal would be substantially more informed if we had a side-by-side comparison of what real-world code looks like before and after the change. There are not too many instances of str.find() in the library and it is an easy patch to make. I'm just asking for a basic, objective investigative tool. Unlike more complex proposals, this one doesn't rely on any new functionality. It just says don't use X anymore. That makes it particularly easy to investigate in an objective way. BTW, this isn't unprecedented. We're already done it once when backticks got slated for removal in 3.0. All instances of it got changed in the standard library. As a result of the patch, we were able to 1) get an idea of how much work it took, 2) determine every category of use case, 3) learn that the resulting code was more beautiful, readable, and only microscopically slower, 4) learn about a handful of cases that were unexpectedly difficult to convert, and 5) update the library to be an example of what we think modern code looks like. That patch painlessly informed the decision making and validated that we were doing the right thing. The premise of Terry's proposal is that Python code is better when str.find() is not used. This is a testable proposition. Why not use the wealth of data at our fingertips to augment a priori reasoning and anecdotes. I'm not at all arguing against the proposal; I'm just asking for a thoughtful design process. Raymond P.S. Josiah was not alone. The comp.lang.python discussion had other posts expressing distaste for raising exceptions instead of using return codes. While I don't feel the same way, I don't think the respondants should be ignored. "Those people who love sausage and respect the law should not watch either one being made." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
Bill Janssen wrote: >> 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. Heh. You know what the Perl6 folks would suggest in this case? return 0 but true; # literally! > Might add a boolean "str.contains()" to cover this test case. There's already __contains__. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
