I wrote:
[Andrew Durdin:]
> > IOW, I expected "www.python.org".partition("python") to return exactly
> > the same as "www.python.org".rpartition("python")
>
> Yow. Me too, and indeed I've been skimming this thread without
> it ever occurring to me that it would be otherwise.
And, on re-skimming
> Just to put my spoke in the wheel, I find the difference in the
> ordering of return values for partition() and rpartition() confusing:
>
> head, sep, remainder = partition(s)
> remainder, sep, head = rpartition(s)
>
> My first expectation for rpartition() was that it would return exactly
> the
Steve Holden <[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum wrote:
> > On 8/30/05, Andrew Durdin <[EMAIL PROTECTED]> wrote:
> [confusion]
> >
> >
> > Hm. The example is poorly chosen because it's an end case. The
> > invariant for both is (I'd hope!)
> >
> > "".join(s.partition()) == s == "
Guido van Rossum wrote:
> On 8/30/05, Andrew Durdin <[EMAIL PROTECTED]> wrote:
[confusion]
>
>
> Hm. The example is poorly chosen because it's an end case. The
> invariant for both is (I'd hope!)
>
> "".join(s.partition()) == s == "".join(s.rpartition())
>
> Thus,
>
> "a/b/c".partition("/"
"Delaney, Timothy (Tim)" <[EMAIL PROTECTED]> wrote in message
> before, sep, after = s.partition('?')
> ('http://www.python.org', '', '')
>
> before, sep, after = s.rpartition('?')
> ('', '', 'http://www.python.org')
I can also see this as left, sep, right, with the sep not found case
putting al
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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
On 8/31/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Hm. The example is poorly chosen because it's an end case. The
> invariant for both is (I'd hope!)
>
> "".join(s.partition()) == s == "".join(s.rpartition())
> (Just think of it as rpartition() stopping at the last occurrence,
> ra
On 8/30/05, Andrew Durdin <[EMAIL PROTECTED]> wrote:
> On 8/31/05, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> > Andrew Durdin wrote:
> >
> > > Just to put my spoke in the wheel, I find the difference in the
> > > ordering of return values for partition() and rpartition() confusing:
> > >
>
On 8/31/05, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> Andrew Durdin wrote:
>
> > Just to put my spoke in the wheel, I find the difference in the
> > ordering of return values for partition() and rpartition() confusing:
> >
> > head, sep, remainder = partition(s)
> > remainder, sep, head
Andrew Durdin wrote:
> Just to put my spoke in the wheel, I find the difference in the
> ordering of return values for partition() and rpartition() confusing:
>
> head, sep, remainder = partition(s)
> remainder, sep, head = rpartition(s)
This is the confusion - you've got the terminology wrong.
On 8/31/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Hye-Shik Chang]
> > What would be a result for rpartition(s, '?') ?
> > ('', '', 'http://www.python.org')
> > or
> > ('http://www.python.org', '', '')
>
> The former. The invariants for rpartition() are a mirror image of those
> for part
[Hye-Shik Chang]
> What would be a result for rpartition(s, '?') ?
> ('', '', 'http://www.python.org')
> or
> ('http://www.python.org', '', '')
The former. The invariants for rpartition() are a mirror image of those
for partition().
> BTW, I wrote a somewhat preliminary patch for this functi
On 8/28/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >>> s = 'http://www.python.org'
> >>> partition(s, '://')
> ('http', '://', 'www.python.org')
> >>> partition(s, '?')
> ('http://www.python.org', '', '')
> >>> partition(s, 'http://')
> ('', 'http://', 'www.pytho
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [M.-A. Lemburg]
>> Also, as I understand Terry's request, .find() should be removed
>> in favor of just leaving .index() (which is the identical method
>> without the funny -1 return code logic).
My proposal is to
[Kay Schluehr]
>> 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.
[Guido]
> There is much focus on removi
Raymond writes:
> That suggests that we need a variant of split() that has been customized
> for typical find/index use cases. Perhaps introduce a new pair of
> methods, partition() and rpartition()
+1
My only suggestion is that when you're about to make a truly
inspired suggestion like this one
[M.-A. Lemburg]
> Also, as I understand Terry's request, .find() should be removed
> in favor of just leaving .index() (which is the identical method
> without the funny -1 return code logic).
>
> So your proposal really doesn't have all that much to do
> with Terry's request, but is a new and sep
Raymond Hettinger wrote:
> Looking at sample code transformations shows that the high-power
> mxTextTools and re approaches do not simplify code that currently uses
> s.find(). In contrast, the proposed partition() method is a joy to use
> and has no surprises. The following code transformation
Raymond Hettinger wrote:
> [Marc-Andre Lemburg]
>
>>I may be missing something, but why invent yet another parsing
>>method - we already have the re module. I'd suggest to
>>use it :-)
>>
>>If re is not fast enough or you want more control over the
>>parsing process, you could also have a look at
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> [Guido]
> > 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
[Marc-Andre Lemburg]
> I may be missing something, but why invent yet another parsing
> method - we already have the re module. I'd suggest to
> use it :-)
>
> If re is not fast enough or you want more control over the
> parsing process, you could also have a look at mxTextTools:
>
> http://w
Raymond Hettinger wrote:
> [Guido]
>
>>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 b
[Guido]
> 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
On 2005-08-26, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Can str.find be listed in PEP 3000 (under builtins) for removal?
> Would anyone really object?
>
With all the discussion, I think you guys should realize that the
find/index method are actually convenient function which do 2 things in
one cal
Steve Holden <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > Donovan Baarda <[EMAIL PROTECTED]> wrote:
> [...]
> >
> > 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 "
Josiah Carlson wrote:
> Donovan Baarda <[EMAIL PROTECTED]> wrote:
[...]
>
> 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".
> Obviou
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 th
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 e
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 ob
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
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' tha
[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/mai
[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:
>
[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
___
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 biz
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 functio
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
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 unders
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.
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 = op
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 sen
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, rever
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 b
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_
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 shrunk
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
> excepti
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 a
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
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* wro
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
[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
introduci
> > 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 artificiall
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
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
"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
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
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
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 s
> 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
"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 ba
"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
"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
"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 offere
> 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 cons
> 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_B
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.inde
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 anomalousl
67 matches
Mail list logo
