"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
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
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
"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
> [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
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
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
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
Bryan Olson wrote:
> The conclusion is inescapable: Python's handling of negative
> subscripts is a wart. Indexing from the high end is too useful
> to give up, but it should be specified by the slicing/indexing
> operation, not by the value of the index expression.
>
>
> PPEP (Proposed Python Enha
"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
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
Robert Kern wrote:
> By "+1" he means, "I like it." He's not correcting you.
Ah, O.K. Thanks.
--
--Bryan
--
http://mail.python.org/mailman/listinfo/python-list
Bryan Olson wrote:
> Paul Rubin wrote:
> > Bryan Olson writes:
> >
> >> seq[3 : -4]
> >>
> >>we write:
> >>
> >> seq[3 ; $ - 4]
> >
> > +1
>
> I think you're wrong about the "+1". I defined '$' to stand for
> the length of the sequence (not the address of the last
> element).
By
Steven Bethard wrote:
> Bryan Olson wrote:
>
>> Steven Bethard wrote:
>> > Well, I couldn't find where the general semantics of a negative
stride
>> > index are defined, but for sequences at least[1]:
>> >
>> > "The slice of s from i to j with step k is defined as the sequence of
>> >
Kay Schluehr wrote:
> Steven Bethard wrote:
>>"The slice of s from i to j with step k is defined as the sequence of
>>items with index x = i + n*k such that 0 <= n < (j-i)/k."
>>
>>This seems to contradict list behavior though.
>> range(10)[9:-1:-2] == []
>
>
> No, both is correct. But
Kay Schluehr wrote:
> Bryan Olson wrote:
>
>>Steven Bethard wrote:
>> > Well, I couldn't find where the general semantics of a negative stride
>> > index are defined, but for sequences at least[1]:
>> >
>> > "The slice of s from i to j with step k is defined as the sequence of
>> > items wi
Paul Rubin wrote:
> Bryan Olson writes:
>
>> seq[3 : -4]
>>
>>we write:
>>
>> seq[3 ; $ - 4]
>
>
> +1
I think you're wrong about the "+1". I defined '$' to stand for
the length of the sequence (not the address of the last
element).
>>When square-brackets appear within other sq
Bryan Olson <[EMAIL PROTECTED]> writes:
> seq[3 : -4]
>
> we write:
>
> seq[3 ; $ - 4]
+1
> When square-brackets appear within other square-brackets, the
> inner-most bracket-pair determines which sequence '$' describes.
> (Perhaps '$$' should be the length of the next containing
> br
Bryan Olson wrote:
> Steven Bethard wrote:
> > Well, I couldn't find where the general semantics of a negative stride
> > index are defined, but for sequences at least[1]:
> >
> > "The slice of s from i to j with step k is defined as the sequence of
> > items with index x = i + n*k such that 0
Steven Bethard wrote:
> "The slice of s from i to j with step k is defined as the sequence of
> items with index x = i + n*k such that 0 <= n < (j-i)/k."
>
> This seems to contradict list behavior though.
> range(10)[9:-1:-2] == []
No, both is correct. But we don't have to interpret the seco
Bryan Olson wrote:
> Steven Bethard wrote:
> > Well, I couldn't find where the general semantics of a negative stride
> > index are defined, but for sequences at least[1]:
> >
> > "The slice of s from i to j with step k is defined as the sequence of
> > items with index x = i + n*k such that 0
Steven Bethard wrote:
> Well, I couldn't find where the general semantics of a negative stride
> index are defined, but for sequences at least[1]:
>
> "The slice of s from i to j with step k is defined as the sequence of
> items with index x = i + n*k such that 0 <= n < (j-i)/k."
>
> This se
I wrote:
> I wanted to say something about what happens with a negative stride, to
> indicate that it produces (9, -1, -2) instead of (-1, -11, -2), but I
> wasn't able to navigate the Python documentation well enough.
>
> Looking at the Language Reference section on the slice type[1] (section
Michael Hudson wrote:
> [EMAIL PROTECTED] writes:
>> I'm fine with your favored behavior. What do we do next to get
>> the doc fixed?
>
> I guess one of us comes up with some less misleading words. It's not
> totally obvious to me what to do, seeing as the returned values *are*
> indices is a sen
[EMAIL PROTECTED] writes:
> Michael Hudson wrote:
>> Bryan Olson writes:
>> In some sense; it certainly does what I intended it to do.
>
> [...]
>> I'm not going to change the behaviour. The docs probably aren't
>> especially clear, though.
>
> The docs and the behavior contradict:
>
> [...]
Michael Hudson wrote:
> Bryan Olson writes:
> In some sense; it certainly does what I intended it to do.
[...]
> I'm not going to change the behaviour. The docs probably aren't
> especially clear, though.
The docs and the behavior contradict:
[...] these are the /start/ and /stop/ indices
Bryan Olson <[EMAIL PROTECTED]> writes:
> The Python slice type has one method 'indices', and reportedly:
>
> This method takes a single integer argument /length/ and
> computes information about the extended slice that the slice
> object would describe if applied to a sequence of l
John Machin wrote:
> Steven Bethard wrote:
[...]
>> BTW, a simpler example of the same phenomenon is:
>>
>> py> range(10)[slice(None, None, -2)]
>> [9, 7, 5, 3, 1]
>> py> slice(None, None, -2).indices(10)
>> (9, -1, -2)
>> py> range(10)[9:-1:-2]
>> []
>>
>
> >>> rt = range(10)
> >>>
Steven Bethard wrote:
> Bryan Olson wrote:
>
>>
>> class BuggerAll:
>>
>> def __init__(self, somelist):
>> self.sequence = somelist[:]
>>
>> def __getitem__(self, key):
>> if isinstance(key, slice):
>> start, stop, step = key.indices(len(
Steven Bethard wrote:
> I suspect there's a reason that it's done this way, but I agree with you
> that this seems strange. Have you filed a bug report on Sourceforge?
I gather that the slice class is young, so my guess is bug. I
filed the report -- my first Sourceforge bug report.
> BTW, a s
Bryan Olson wrote:
>
> class BuggerAll:
>
> def __init__(self, somelist):
> self.sequence = somelist[:]
>
> def __getitem__(self, key):
> if isinstance(key, slice):
> start, stop, step = key.indices(len(self.sequence))
>
The Python slice type has one method 'indices', and reportedly:
This method takes a single integer argument /length/ and
computes information about the extended slice that the slice
object would describe if applied to a sequence of length
items. It returns a tuple of three int
93 matches
Mail list logo
