kay schluehr

Ups. Yes of course.


You can ask questions ;-)


I'm not shure too. Probably Inf as a keyword is a much better choice.
The only std-library module I found that used Inf was Decimal where Inf
has the same meaning. Inf is quick to write ( just one more character
than !0 ) and easy to parse for human readers. Rewriting the above statements/expressions leads to:

True

True

IMO it's still consice.

Kay

fredrik lundh

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 the right of the given gap (this is
what gives you the perceived assymmetry), slices return all items between the given gaps.
</F>

terry reedy

Well said. In some languages, straight indexing returns the item to the
left instead. The different between items and gaps in seen in old
terminals and older screens versus modern gui screens. Then, a cursur sat
on top of or under a character space. Now, a cursur sits between chars.

Terry J. Reedy

ron adam

So how do I express a -0? Which should point to the gap after the last item.

If this were symmetrical, then positive index's would return the value
to the right and negative index's would return the value to the left.

Have you looked at negative steps? They also are not symmetrical.

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] # d
print a[3:2:-1] # d These are symetric?!
print a[-4:-5:-1] # d
print a[3:-5:-1] # d
print a[-4:2:-1] # d

This is why it confuses so many people. It's a shame too, because slice
objects could be so much more useful for indirectly accessing list
ranges. But I think this needs to be fixed first.

Cheers,
Ron

terry reedy

You just did ;-) but I probably do not know what you mean.


The slice index of the gap after the last item is len(seq).

As I posted before (but perhaps it arrived after you sent this), one number
indexing rounds down, introducing a slight asymmetry.

It is 3 and 4 gaps *from* the left and right end to the left side of the
'd'. You can also see the asymmetry as coming from rounding 3.5 and -3.5
down to 3 and down to -4.

These are is symmetric, as we claimed.


Here you count down past and up past the d.


Here you count up to and down to the d. The count is one more when you
cross the d than when you do not. You do different actions, you get
different counts. I would not recommend mixing up and down counting to a
beginner, and not down and up counting to anyone who did not absolutely have to.

The pattern seems to be: left-gap-index : farther-to-left-index : -1 is
somehow equivalent to left:right, but I never paid much attention to
strides and don't know the full rule.

Stride slices are really a different subject from two-gap slicing. They
were introduced in the early years of Python specificly and only for
Numerical Python. The rules were those needed specificly for Numerical
Python arrays. They was made valid for general sequence use only a few
years ago. I would say that they are only for careful mid-level to expert
use by those who actually need them for their code.

Terry J. Reedy

paul rubin

Ron Adam <rrr@ronadam.com> writes:


+1 QOTW

fredrik lundh

that item doesn't exist when you're doing plain indexing, so being able
to express -0 would be pointless.

when you're doing slicing, you express it by leaving the value out, or by
using len(seq) or (in recent versions) None.

the gap addressing is symmetrical, but indexing always picks the item to the right.

the gap addressing works as before, but to understand exactly what characters
you'll get, you have to realize that the slice is really a gap index generator. when
you use step=1, you can view slice as a "cut here and cut there, and return what's
in between". for other step sizes, you have to think in gap indexes (for which the
plain indexing rules apply).

and if you know range(), you already know how the indexes are generated for
various step sizes.

from the range do***entation:

... returns a list of plain integers [start, start + step, start + 2 * step, ...].
If step is positive, the last element is the largest start + i * step less than
stop; if step is negative, the last element is the largest start + i * step
greater than stop.

or, in sequence terms (see http://docs.python.org/lib/typesseq.html )

(3) If i or j is negative, the index is relative to the end of the string: len(s) + i
or len(s) + j is substituted.

...

(5) The slice of s from i to j with step k is defined as the sequence of items
with index x = i + n*k for n in the range(0,(j-i)/k). In other words, the
indices are i, i+k, i+2*k, i+3*k and so on, stopping when j is reached
(but never including j).

so in this case, you get


2 # which is your stop condition

so a[3:2:-1] is the same as a[3].

same as a[-4]


now you're mixing addressing modes, which is a great way to confuse
yourself. if you normalize the gap indexes (rule 3 above), you'll get
a[3:2:-1] which is the same as your earlier example. you can use the
"indices" method to let Python do this for you:


same problem here; indices will tell you what that really means:


[3]

same example again, in other words. and same result.


as everything else in Python, if you use the wrong mental model, things
may look "assymmetrical" or "confusing" or "inconsistent". if you look at
how things really work, it's usually extremely simple and more often than
not internally consistent (since the designers have the "big picture", and
knows what they're tried to be consistent with; when slice steps were
added, existing slicing rules and range() were the obvious references).

it's of course pretty common that people who didn't read the do***entation
very carefully and therefore adopted the wrong model will insist that Python
uses a buggy implementation of their model, rather than a perfectly consistent
implementation of the actual model. slices with non-standard step sizes are
obviously one such thing, immutable/mutable objects and the exact behaviour
of for-else, while-else, and try-else are others. as usual, being able to reset
your brain is the only thing that helps.

</F>

dennis lee bieber

On Fri, 02 Sep 2005 00:23:14 GMT, Ron Adam <rrr@ronadam.com> declaimed
the following in comp.lang.python:

Step one: Obtain a processor that uses ones-complement arithmetic.

Step two: Port Python to said processor...

...

<G>
--

steve holden

Ah, the good old Univac 418 ... [drools into beard and mumbles]


Unfortunately the 418 would probably come in at about a micro-pystone,
so perhaps we should emulate it on something more modern?

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

ron adam

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.

b = list('abcdefg')
for x in range(-len(b),-1):
print b[x:x+2]

['a', 'b']
['b', 'c']
['c', 'd']
['d', 'e']
['e', 'f']
[]


b = list('abcdefg')
for x in range(-len(b),-1):
if x<-2:
print b[x:x+2]
else:
print b[x:]

['a', 'b']
['b', 'c']
['c', 'd']
['d', 'e']
['e', 'f'] ['f', 'g']

I didn't see that one, but I agree. Single index's are asymmetric,
positive slices with two index's are again symetric, negative slices
with negative strides or steps are again asymmetric.


print a[4:1:-1] # 6|g| 5|f| 4|e| 3|d| 2|c| 1|b| 0|a| ?
-> edc
print a[-3:-6:-1] # -1|g|-2|f|-3|e|-4|d|-5|c|-6|b|-7|a|-8|
-> edc

# special case '::'
print a[6::-1] # 6|g| 5|f| 4|e| 3|d| 2|c| 1|b| 0|a| ?
-> gfedcba
print a[-1:-8:-1] # -1|g|-2|f|-3|e|-4|d|-5|c|-6|b|-7|a|-8
-> gfedcba


Since single indexing only refers to existing items and aren't used to
insert between items, this still works even with the slight asymmetry.

Yes, no problem here except for addressing the -0th (end gap) position
without special casing to either a positive index or a[-n:].

a[start:stop:-1]
a[stop:start] # exchange index's
a.reverse() # reverse string

a[4:1:-1] # 6 |g| 5 |f| 4 |e| 3 |d| 2 |c| 1 |b| 0 |a| ?
a[1:4] # ? |a| 0 |b| 1 |c| 2 |d| 3 |e| 4 |f| 5 |g| 6
a.reverse() # -> edc

Notice the index's are 1 less than with positive strides.

I'd like to see those use case's. I have a feeling there are probably
better ways to do it now.

Doing a quick search in python24/lib, there are only two places that use
a negative step or stride value to reverse a sequence.

---------- PICKLE.PY
return binary[::-1]
ashex = _binascii.hexlify(data[::-1])

I don't think people would miss negative strides much if they were
removed. Replacing these case's with reverse() methods shouldn't be that
difficult.

Cheers,
Ron