The doc for the find() method of string objects, which is
essentially the same as the string.find() function, states:
find(sub[, start[, end]])
Return the lowest index in the string where substring sub
is found, such that sub is contained in the range [start,
end). Optio
Bryan Olson wrote:
> The doc for the find() method of string objects, which is
> essentially the same as the string.find() function, states:
>
> find(sub[, start[, end]])
>Return the lowest index in the string where substring sub
>is found, such that sub is contained in the ra
>contained in the range [start, end)
Does range(start, end) generate negative integers in Python if start
>= 0 and end >= start?
--
Regards,
Casey
--
http://mail.python.org/mailman/listinfo/python-list
On Thu, 25 Aug 2005 00:05:18 -0400
Steve Holden wrote:
> What on earth makes you call this a bug? And what are you proposing that
> find() should return if the substring isn't found at all? please don't
> suggest it should raise an exception, as index() exists to provide that
> functionality.
Steve Holden <[EMAIL PROTECTED]> writes:
> As far as position reporting goes, it seems pretty clear that find()
> will always report positive index values. In a five-character string
> then -1 and 4 are effectively equivalent.
>
> What on earth makes you call this a bug? And what are you proposing
Steve Holden asked:
> Do you just go round looking for trouble?
In the course of programming, yes, absolutly.
> As far as position reporting goes, it seems pretty clear that find()
> will always report positive index values. In a five-character string
> then -1 and 4 are effectively equivalen
Op 2005-08-25, Bryan Olson schreef <[EMAIL PROTECTED]>:
> Steve Holden asked:
> > Do you just go round looking for trouble?
>
> In the course of programming, yes, absolutly.
>
> > As far as position reporting goes, it seems pretty clear that find()
> > will always report positive index values. In a
Antoon Pardon wrote:
> Bryan Olson schreef:
>
>>Steve Holden asked:
>>>And what are you proposing that
>>>find() should return if the substring isn't found at all? please don't
>>>suggest it should raise an exception, as index() exists to provide that
>>>functionality.
>>
>>There are a num
Bryan Olson <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> Steve Holden asked:
> > Do you just go round looking for trouble?
>
> In the course of programming, yes, absolutly.
>
> > As far as position reporting goes, it seems pretty clear that
> > find() will always report positive index
Bryan Olson wrote:
> Antoon Pardon wrote:
> > Bryan Olson schreef:
> >
> >>Steve Holden asked:
> >>>And what are you proposing that
> >>>find() should return if the substring isn't found at all? please don't
> >>>suggest it should raise an exception, as index() exists to provide that
> >>>fu
Steve Holden wrote:
> Bryan Olson wrote:
>> Antoon Pardon wrote:
>> > It probably is too late now, but I always felt, find should
>> > have returned None when the substring isn't found.
>>
>> None is certainly a reasonable candidate.
[...]
>> The really broken part is that unsuccessful se
Bryan Olson wrote:
> Steve Holden wrote:
> > Bryan Olson wrote:
> >> Antoon Pardon wrote:
>
> >> > It probably is too late now, but I always felt, find should
> >> > have returned None when the substring isn't found.
> >>
> >> None is certainly a reasonable candidate.
> [...]
> >> The rea
"Bryan Olson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The double-meaning of -1, as both an exclusive stopping bound
> and an alias for the highest valid index, is just plain whacked.
I agree in this sense: the use of any int as an error return is an
unPythonic *nix-Cism, w
"Terry Reedy" <[EMAIL PROTECTED]> writes:
> I agree in this sense: the use of any int as an error return is an
> unPythonic *nix-Cism, which I believe was copied therefrom. Str.find is
> redundant with the Pythonic exception-raising str.index and I think it
> should be removed in Py3.
I like h
"Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message
news:[EMAIL PROTECTED]
> "Terry Reedy" <[EMAIL PROTECTED]> writes:
>>Str.find is
>> redundant with the Pythonic exception-raising str.index
>> and I think it should be removed in Py3.
>
> I like having it available so you don't have t
Hallöchen!
"Terry Reedy" <[EMAIL PROTECTED]> writes:
> "Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message
> news:[EMAIL PROTECTED]
>
>> "Terry Reedy" <[EMAIL PROTECTED]> writes:
>>
>>> Str.find is redundant with the Pythonic exception-raising
>>> str.index and I think it should be re
"Terry Reedy" <[EMAIL PROTECTED]> writes:
> The try/except pattern is a pretty basic part of Python's design. One
> could say the same about clutter for *every* function or method that raises
> an exception on invalid input. Should more or even all be duplicated? Why
> just this one?
Someone
"Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message
news:[EMAIL PROTECTED]
> "Terry Reedy" <[EMAIL PROTECTED]> writes:
>> The try/except pattern is a pretty basic part of Python's design. One
>> could say the same about clutter for *every* function or method that
>> raises
>> an exce
Torsten Bronger wrote:
> Hallöchen!
>
> "Terry Reedy" <[EMAIL PROTECTED]> writes:
>
>
>>"Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message
>>news:[EMAIL PROTECTED]
>>
>>
>>>"Terry Reedy" <[EMAIL PROTECTED]> writes:
>>>
>>>
Str.find is redundant with the Pythonic exception-raisin
Bryan Olson wrote:
> Steve Holden wrote:
> > Bryan Olson wrote:
> >> Antoon Pardon wrote:
>
> >> > It probably is too late now, but I always felt, find should
> >> > have returned None when the substring isn't found.
> >>
> >> None is certainly a reasonable candidate.
> [...]
> >> The rea
Steve Holden wrote:
> Of course. But onc you (sensibly) decide to use an "if" then there
> really isn't much difference between -1, None, () and sys.maxint as
> a sentinel value, is there?
Sure there is. -1 is a valid index; None is not. -1 as a sentinel is
specific to str.find(); None is used a
Steve Holden <[EMAIL PROTECTED]> writes:
> Of course. But onc you (sensibly) decide to use an "if" then there
> really isn't much difference between -1, None, () and sys.maxint as
> a sentinel value, is there?
Of course there is. -1 is (under Python's perverse semantics) a valid
subscript. sys.m
Steve Holden <[EMAIL PROTECTED]> writes:
> If you want an exception from your code when 'w' isn't in the string
> you should consider using index() rather than find.
The idea is you expect w to be in the string. If w isn't in the
string, your code has a bug, and programs with bugs should fail as
"Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message
news:[EMAIL PROTECTED]
> Steve Holden <[EMAIL PROTECTED]> writes:
>> Of course. But onc you (sensibly) decide to use an "if" then there
>> really isn't much difference between -1, None, () and sys.maxint as
>> a sentinel value, is the
Steve Holden wrote:
> Bryan Olson wrote:
>> [...] I see no good reason for the following
>> to happily print 'y'.
>>
>> s = 'buggy'
>> print s[s.find('w')]
>>
>> > Before using the result you always have to perform
>> > a test to discriminate between the found and not found cas
Paul Rubin wrote:
> Steve Holden <[EMAIL PROTECTED]> writes:
>
>>If you want an exception from your code when 'w' isn't in the string
>>you should consider using index() rather than find.
>
>
> The idea is you expect w to be in the string. If w isn't in the
> string, your code has a bug, and pr
Terry Reedy wrote:
> "Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message
> news:[EMAIL PROTECTED]
>
>>Steve Holden <[EMAIL PROTECTED]> writes:
>>
>>>Of course. But onc you (sensibly) decide to use an "if" then there
>>>really isn't much difference between -1, None, () and sys.maxint as
Steve Holden <[EMAIL PROTECTED]> writes:
> A corrected find() that returns None on failure is a five-liner.
If I wanted to write five lines instead of one everywhere in a Python
program, I'd use Java.
--
http://mail.python.org/mailman/listinfo/python-list
Paul> Steve Holden <[EMAIL PROTECTED]> writes:
>> A corrected find() that returns None on failure is a five-liner.
Paul> If I wanted to write five lines instead of one everywhere in a
Paul> Python program, I'd use Java.
+1 for QOTW.
Skip
--
http://mail.python.org/mailman/listi
Paul Rubin wrote:
> Steve Holden <[EMAIL PROTECTED]> writes:
>
>>A corrected find() that returns None on failure is a five-liner.
>
>
> If I wanted to write five lines instead of one everywhere in a Python
> program, I'd use Java.
We are arguing about trivialities here. Let's stop before it get
Steve Holden wrote:
> Paul Rubin wrote:
> We are arguing about trivialities here. Let's stop before it gets
> interesting :-)
Some of us are looking beyond the trivia of what string.find()
should return, at an unfortunate interaction of Python features,
brought on by the special-casing of negat
Bryan Olson wrote:
> Steve Holden wrote:
> > Paul Rubin wrote:
> > We are arguing about trivialities here. Let's stop before it gets
> > interesting :-)
>
> Some of us are looking beyond the trivia of what string.find()
> should return, at an unfortunate interaction of Python features,
> brough
Robert Kern wrote:
> If I may digress for a bit, my advisor is currently working on a project
> that is processing seafloor depth datasets starting from a few decades
> ago. A lot of this data was orginally to be processed using FORTRAN
> software, so in the idiom of much FORTRAN software from thos
Op 2005-08-27, Terry Reedy schreef <[EMAIL PROTECTED]>:
>
> "Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message
> news:[EMAIL PROTECTED]
>> "Terry Reedy" <[EMAIL PROTECTED]> writes:
>>> The try/except pattern is a pretty basic part of Python's design. One
>>> could say the same about c
Op 2005-08-27, Steve Holden schreef <[EMAIL PROTECTED]>:
>>
>>
> If you want an exception from your code when 'w' isn't in the string you
> should consider using index() rather than find.
Sometimes it is convenient to have the exception thrown at a later
time.
> Otherwise, whatever find() retu
Magnus Lycka wrote:
> Robert Kern wrote:
>
>>If I may digress for a bit, my advisor is currently working on a project
>>that is processing seafloor depth datasets starting from a few decades
>>ago. A lot of this data was orginally to be processed using FORTRAN
>>software, so in the idiom of much F
Antoon Pardon wrote:
> I think a properly implented find is better than an index.
See the current thread in python-dev[1], which proposes a new method,
str.partition(). I believe that Raymond Hettinger has shown that almost
all uses of str.find() can be more clearly be represented with his
pro
Antoon Pardon wrote:
> Op 2005-08-27, Steve Holden schreef <[EMAIL PROTECTED]>:
>
>>>
>>If you want an exception from your code when 'w' isn't in the string you
>>should consider using index() rather than find.
>
>
> Sometimes it is convenient to have the exception thrown at a later
> time.
>
"Steve Holden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Antoon Pardon wrote:
>> So what happens if you have a module that is collecting string-index
>> pair, colleted from various other parts. In one part you
>> want to select the last letter, so you pythonically choose -1 as
"Terry Reedy" <[EMAIL PROTECTED]> writes:
> The fact that the -1 return *has* lead to bugs in actual code is the
> primary reason Guido has currently decided that find and rfind should go.
> A careful review of current usages in the standard library revealed at
> least a couple bugs even there.
Op 2005-08-29, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-08-27, Steve Holden schreef <[EMAIL PROTECTED]>:
>>
>>>If you want an exception from your code when 'w' isn't in the string you
>>>should consider using index() rather than find.
>>
>>
>> Sometimes i
Steve Holden wrote:
> I'm all in favor of discussions to make 3.0 a better
> language.
This one should definitely be two-phase. First, the non-code-
breaking change that replaces-and-deprecates the warty handling
of negative indexes, and later the removal of the old style. For
the former, there'
Op 2005-08-29, Steven Bethard schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> I think a properly implented find is better than an index.
>
> See the current thread in python-dev[1], which proposes a new method,
> str.partition(). I believe that Raymond Hettinger has shown that almost
> al
"Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message
news:[EMAIL PROTECTED]
> Really it's x[-1]'s behavior that should go, not find/rfind.
I complete disagree, x[-1] as an abbreviation of x[len(x)-1] is extremely
useful, especially when 'x' is an expression instead of a name. But ev
"Terry Reedy" <[EMAIL PROTECTED]> writes:
> > Really it's x[-1]'s behavior that should go, not find/rfind.
>
> I complete disagree, x[-1] as an abbreviation of x[len(x)-1] is extremely
> useful, especially when 'x' is an expression instead of a name.
There are other abbreviations possible, for e
Terry Reedy wrote:
> "Paul Rubin" wrote:
>
>>Really it's x[-1]'s behavior that should go, not find/rfind.
>
> I complete disagree, x[-1] as an abbreviation of x[len(x)-1] is
extremely
> useful, especially when 'x' is an expression instead of a name.
Hear us out; your disagreement might not
Bryan Olson <[EMAIL PROTECTED]> writes:
> Specifically, to support new-style slicing, a class that
> accepts index or slice arguments to any of:
>
> __getitem__
> __setitem__
> __delitem__
> __getslice__
> __setslice__
> __delslice__
Op 2005-08-30, Terry Reedy schreef <[EMAIL PROTECTED]>:
>
> "Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message
> news:[EMAIL PROTECTED]
>
>> Really it's x[-1]'s behavior that should go, not find/rfind.
>
> I complete disagree, x[-1] as an abbreviation of x[len(x)-1] is extremely
> use
Bryan Olson wrote:
> Currently, user-defined classes can implement Python
> subscripting and slicing without implementing Python's len()
> function. In our proposal, the '$' symbol stands for the
> sequence's length, so classes must be able to report their
> length in orde
Op 2005-08-30, Robert Kern schreef <[EMAIL PROTECTED]>:
> Bryan Olson wrote:
>
>> Currently, user-defined classes can implement Python
>> subscripting and slicing without implementing Python's len()
>> function. In our proposal, the '$' symbol stands for the
>> sequence's length
Antoon Pardon wrote:
> Op 2005-08-30, Robert Kern schreef <[EMAIL PROTECTED]>:
>
>>Bryan Olson wrote:
>>
>>> Currently, user-defined classes can implement Python
>>> subscripting and slicing without implementing Python's len()
>>> function. In our proposal, the '$' symbol stands for th
Robert Kern wrote:
> Bryan Olson wrote:
>
>
>> Currently, user-defined classes can implement Python
>> subscripting and slicing without implementing Python's len()
>> function. In our proposal, the '$' symbol stands for the
>> sequence's length, so classes must be able to rep
Bryan Olson wrote:
> Robert Kern wrote:
> > from Numeric import *
> > A = array([[0, 1], [2, 3], [4, 5]])
> > A[$-1, $-1]
> >
> > The result of len(A) has nothing to do with the second $.
>
> I think you have a good observation there, but I'll stand by my
> correctness.
len() cannot b
On Tue, 30 Aug 2005 08:53:27 GMT, Bryan Olson <[EMAIL PROTECTED]> wrote:
> Specifically, to support new-style slicing, a class that
> accepts index or slice arguments to any of:
>
> __getitem__
> __setitem__
> __delitem__
> __getslice__
> __setslice__
Antoon Pardon wrote:
> Op 2005-08-29, Steve Holden schreef <[EMAIL PROTECTED]>:
>
>>Antoon Pardon wrote:
>>
>>>Op 2005-08-27, Steve Holden schreef <[EMAIL PROTECTED]>:
>>>
>>>
If you want an exception from your code when 'w' isn't in the string you
should consider using index() rather tha
On Tue, 30 Aug 2005 08:53:27 GMT, Bryan Olson <[EMAIL PROTECTED]> wrote:
[...]
>Specification
>
> We propose a new style of slicing and indexing for Python
> sequences. Instead of:
>
> sequence[start : stop : step]
>
> new-style slicing uses the syntax:
>
> sequence[star
[EMAIL PROTECTED] (Bengt Richter) writes:
> What about if when brackets trail as if attributes, it means
> your-style slicing written with colons instead of semicolons?
>
> sequence.[start : stop : step]
This is nice. It gets rid of the whole $1,$2,etc syntax as well.
--
http://mail.p
On Tue, 30 Aug 2005 11:56:24 GMT, Bryan Olson <[EMAIL PROTECTED]> wrote:
>Robert Kern wrote:
> > Bryan Olson wrote:
> >
> >
> >> Currently, user-defined classes can implement Python
> >> subscripting and slicing without implementing Python's len()
> >> function. In our proposal, the '$
On 30 Aug 2005 10:07:06 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>Op 2005-08-30, Terry Reedy schreef <[EMAIL PROTECTED]>:
>>
>> "Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message
>> news:[EMAIL PROTECTED]
>>
>>> Really it's x[-1]'s behavior that should go, not find/rfind.
>>
>> I
Op 2005-08-30, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-08-29, Steve Holden schreef <[EMAIL PROTECTED]>:
>>
>>>Antoon Pardon wrote:
>>>
Op 2005-08-27, Steve Holden schreef <[EMAIL PROTECTED]>:
>If you want an exception from your code when 'w' is
Op 2005-08-30, Bengt Richter schreef <[EMAIL PROTECTED]>:
> On 30 Aug 2005 10:07:06 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>>Op 2005-08-30, Terry Reedy schreef <[EMAIL PROTECTED]>:
>>>
>>> "Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message
>>> news:[EMAIL PROTECTED]
>>>
R
On 31 Aug 2005 07:26:48 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>Op 2005-08-30, Bengt Richter schreef <[EMAIL PROTECTED]>:
>> On 30 Aug 2005 10:07:06 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>>
>>>Op 2005-08-30, Terry Reedy schreef <[EMAIL PROTECTED]>:
"Paul Rubin" <"http://ph
Op 2005-08-31, Bengt Richter schreef <[EMAIL PROTECTED]>:
> On 31 Aug 2005 07:26:48 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>>Op 2005-08-30, Bengt Richter schreef <[EMAIL PROTECTED]>:
>>> On 30 Aug 2005 10:07:06 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>>>
Op 2005-08-30, Terry Reed
Paul Rubin wrote:
> Not every sequence needs __len__; for example, infinite sequences, or
> sequences that implement slicing and subscripts by doing lazy
> evaluation of iterators:
>
> digits_of_pi = memoize(generate_pi_digits()) # 3,1,4,1,5,9,2,...
> print digits_of_pi[5] # computes 6
Antoon Pardon wrote:
> Op 2005-08-31, Bengt Richter schreef <[EMAIL PROTECTED]>:
>
>>On 31 Aug 2005 07:26:48 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>>
>>
>>>Op 2005-08-30, Bengt Richter schreef <[EMAIL PROTECTED]>:
>>>
On 30 Aug 2005 10:07:06 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrot
> [snipped alot from others about indexing, slicing problems,
> and the inadequacy of -1 as Not Found indicator]
on 31.08.2005 16:16 Ron Adam said the following:
> The problem with negative index's are that positive index's are zero
> based, but negative index's are 1 based. Which leads to a no
On Wed, 31 Aug 2005 14:16:28 GMT, Ron Adam <[EMAIL PROTECTED]> wrote:
[...]
>
>The problem with negative index's are that positive index's are zero
>based, but negative index's are 1 based. Which leads to a non
>symmetrical situations.
>
>Note that you can insert an item before the first item us
Bengt Richter wrote:
> On Wed, 31 Aug 2005 14:16:28 GMT, Ron Adam <[EMAIL PROTECTED]> wrote:
> [...]
>
>>The problem with negative index's are that positive index's are zero
>>based, but negative index's are 1 based. Which leads to a non
>>symmetrical situations.
Although it is _way_ too late t
Bengt Richter wrote:
> IMO the problem is that the index sign is doing two jobs, which for zero-based
> reverse indexing have to be separate: i.e., to show direction _and_ a _signed_
> offset which needs to be realtive to the direction and base position.
Yes, that's definitely part of it.
> A l
69 matches
Mail list logo
