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 same
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 the thread, I
[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
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 partition().
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, 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 =
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:
head, sep,
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())
snip
(Just think of it as rpartition() stopping at the last occurrence,
rather
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 and
.rfind are
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 all in
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(/) returns (a, /,
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 == .join(s.rpartition())
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,
[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 removing things,
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.
Obviously, I
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 str.find or lack of
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 call:
[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 is
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 be
[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:
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 in that you
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
[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 separate
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
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
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
[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
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
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*
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:
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
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,
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
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 =
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
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
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
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
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
[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
[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
. .
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
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
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.
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 -
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
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
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
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
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
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:
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
52 matches
Mail list logo
