"Ron Adam" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> (I was wondering why list's couldn't have len,min, and max attribute
> that are updated when ever the list is modified in place of using
> len,min, and max functions?
Python's list and, I believe, other builtin roster objec
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
Terry Reedy wrote:
>>b[-1:] = ['Z']# replaces last item
>>b[-1:-0] = ['Z'] # this doesn't work
>>
>>If you are using negative index slices, you need to check for end
>>conditions because you can't address the end of the slice in a
>>sequential/numerical way.
>
> OK, now I understand
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
"Ron Adam" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>> "Ron Adam" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>>So how do I express a -0?
>>
>>
>> You just did ;-) but I probably do not know what you mean.
>
> b[-1:] = ['Z']# rep
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
Terry Reedy wrote:
> "Ron Adam" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>>Fredrik Lundh wrote:
>>
>>>Ron Adam 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
symmetri
Dennis Lee Bieber wrote:
> On Fri, 02 Sep 2005 00:23:14 GMT, Ron Adam <[EMAIL PROTECTED]> declaimed
> the following in comp.lang.python:
>
>
>>So how do I express a -0? Which should point to the gap after the last
>>item.
>>
>
> Step one: Obtain a processor that uses ones-complement arit
Ron Adam wrote:
>> indices point to the "gap" between items, not to the items themselves.
>
> So how do I express a -0? Which should point to the gap after the last
> item.
that item doesn't exist when you're doing plain indexing, so being able
to express -0 would be pointless.
when you're doin
Ron Adam <[EMAIL PROTECTED]> writes:
> All of the following get the center 'd' from the string.
>
> a = 'abcdefg'
> print a[3] # d 4 gaps from beginning
> print a[-4]# d 5 gaps from end
> print a[3:4] # d
> print a[-4:-3] # d
> print a[-4:4] # d
> print a[3:-3]
"Ron Adam" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Fredrik Lundh wrote:
>> Ron Adam 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.
>>
>> indices point
Fredrik Lundh wrote:
> Ron Adam 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.
>
>
> indices point to the "gap" between items, not to the items themselves.
So how do I
"Stefan Rank" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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 non
>> symmetrical situations.
>
> Hea
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [slice] indices point to the "gap" between items, not to the items
> themselves.
>
> positive indices start from the left end, negative indices from the
> righept end.
>
> straight indexing returns the item just to th
Ron Adam 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.
indices point to the "gap" between items, not to the items themselves.
positive indices start from the left end, negat
> [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
Bengt Richter wrote:
> range(9)[4:-!0:-1] == range(5)
> >True
> Interesting, but wouldn't that last line be
> >>> range(9)[4:-!0:-1] == range(5)[::-1]
Ups. Yes of course.
> >Life can be simpler with unbound limits.
> Hm, is "!0" a di-graph symbol for infinity?
> What if we get full unicode
On 31 Aug 2005 07:13:26 -0700, "Kay Schluehr" <[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote:
>
>> How about interpreting seq[i] as an abbreviation of seq[i%len(seq)] ?
>> That would give a consitent interpretation of seq[-1] and no errors
>> for any value ;-)
>
>Cool, indexing becomes cyclic by
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
Bengt Richter wrote:
> How about interpreting seq[i] as an abbreviation of seq[i%len(seq)] ?
> That would give a consitent interpretation of seq[-1] and no errors
> for any value ;-)
Cool, indexing becomes cyclic by default ;)
But maybe it's better to define it explicitely:
seq[!i] = seq[i%
Bengt Richter wrote:
> How about interpreting seq[i] as an abbreviation of seq[i%len(seq)] ?
> That would give a consitent interpretation of seq[-1] and no errors
> for any value ;-)
Cool, indexing becomes cyclic by default ;)
But maybe it's better to define it explicitely:
seq[!i] = seq[i%
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
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
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-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
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
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
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 '$
[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 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
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:
> Specifically, to support new-style slicing, a class that
> accepts index or slice arguments to any of:
>
> __getitem__
> __setitem__
> __delitem__
> __getslice__
> __setslice__
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
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
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
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
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, 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 <[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__
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
"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
"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
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
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, 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
"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.
"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
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.
>
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
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
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
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
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
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
I agree with Bryan Olson.
I think it's a kind of bug, and it has to be fixed, like few other
things.
But I understand that this change can give little problems to the
already written code...
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
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
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
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
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
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
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
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" <"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 <[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
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 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
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
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
"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
"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
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
"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
"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
"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
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:
> 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:
> 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
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
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
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
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
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
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.
>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
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
85 matches
Mail list logo
