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 to try
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
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 using
[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 non
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' isn't in the string you
should
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]
Really it's x[-1]'s behavior
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://phr.cx@NOSPAM.invalid 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] wrote:
Op 2005-08-30, Terry Reedy schreef [EMAIL
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] wrote:
Op 2005-08-30, Terry
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.
Really
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 it is convenient to have
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's
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
all uses
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 even
if
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 example
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 be so
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
useful, especially
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 order
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, so
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 the
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 report their
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 be used to
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 than find.
Sometimes it is
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[start ; stop ;
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 '$' symbol stands
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 complete disagree, x[-1]
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 those
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 clutter for *every*
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() returns you
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 FORTRAN
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
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.
Otherwise,
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
index.
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
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,
brought on by
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 there?
Of course
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 cases. So I
don't
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 programs with
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
a sentinel value, is
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
--
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 gets
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 number of good
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 values. In
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
functionality.
There
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 searches return
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 really broken part is that
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, which
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 having
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 to clutter your
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 removed in Py3.
I like
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 must
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 exception on invalid
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-raising
str.index and I think it should be
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 really broken part is that
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 all
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.maxint
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
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
that
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 equivalent.
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).
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 range
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
68 matches
Mail list logo
