Antoon Pardon [EMAIL PROTECTED] writes:
The problem is that the fields in lst are associated
with a number that is off by one as they are normally
counted. If I go and ask my colleague which field
contains some specific data and he answers:
the 5th, I have to remind my self I want lst[4]
Op 2005-04-21, Dan Bishop schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-04-21, Steve Holden schreef [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote:
...
Along the same lines, I think the REQUIREMENT that x[0] rather
than
x[1] be the first element of list x is a mistake. At least the
Reinhold Birkenfeld wrote:
Other possibility, probably faster when almost all keys in the range are in
the dictionary:
class sdict(dict):
def __getitem__(self, index):
if isinstance(index, slice):
d = {}
for key in xrange(slice.start, slice.stop,
Rocco Moretti wrote:
Steve Holden wrote:
The principle of least surprise is all very well, but needless
surprise of newbies is a dangerous criterion to adopt for programming
language design and following it consistently would lead to a mess
like Visual Basic, which grew by accretion until
Op 2005-04-20, Bill Mill schreef [EMAIL PROTECTED]:
On 20 Apr 2005 13:39:42 GMT, Antoon Pardon [EMAIL PROTECTED] wrote:
Op 2005-04-20, Bill Mill schreef [EMAIL PROTECTED]:
You write this af if other solutions can't be consistent.
Propose one, and I won't write it off without thinking, but
Op 2005-04-20, Roy Smith schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] wrote:
Op 2005-04-20, Roy Smith schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] wrote:
Personnaly I would like to have the choice. Sometimes I prefer to
start at 0, sometimes at 1 and other times
[EMAIL PROTECTED] wrote:
What languages besides Python use the Python slicing convention?
Java uses it for the substring method of strings.
In C starting at
0 may be justified because of the connection between array
subscripting
and pointer arithmetic, but Python is a higher-level language
Op 2005-04-20, Peter Hansen schreef [EMAIL PROTECTED]:
Terry Hancock wrote:
However, I used to make off by one errors all the time in both C and
Fortran,
whereas I hardly ever make them in Python.
This should probably be the overriding concern in this
case.
I can't remember the last time
Op 2005-04-20, Terry Hancock schreef [EMAIL PROTECTED]:
On Wednesday 20 April 2005 07:52 am, Antoon Pardon wrote:
Personnaly I would like to have the choice. Sometimes I prefer to
start at 0, sometimes at 1 and other times at -13 or +7.
Although I would classify that as a rare use case. So,
[Antoon Pardon]
I don't see why the start index can't be accessible through
a method or function just like the length of a list is now.
My favourite would be a range method so we would have
the following idiom:
for i in lst.range():
do something with lst[i]
After going to all that
Op 2005-04-20, Terry Hancock schreef [EMAIL PROTECTED]:
On Wednesday 20 April 2005 12:28 pm, Roy Smith wrote:
Terry Hancock wrote:
I used to make off by one errors all the time in both C and Fortran,
whereas I hardly ever make them in Python.
Part of the reason may be that most loops
[EMAIL PROTECTED] wrote:
Many people I know ask why Python does slicing the way it does.
Can anyone /please/ give me a good defense/justification???
I'm referring to why mystring[:4] gives me
elements 0, 1, 2 and 3 but *NOT* mystring[4] (5th element).
Many people don't like idea that 5th
Antoon Pardon [EMAIL PROTECTED] writes:
I sometimes think python should have been more explicite here,
using a marker for the start-index and end-index, may '^' and
'$'. So if you wanted the last element you had to write:
lst[$]
And for the next to last element:
lst[$ - 1]
I like
Op 2005-04-21, Raymond Hettinger schreef [EMAIL PROTECTED]:
[Antoon Pardon]
I don't see why the start index can't be accessible through
a method or function just like the length of a list is now.
My favourite would be a range method so we would have
the following idiom:
for i in
[Antoon Pardon]
I don't see why the start index can't be accessible through
a method or function just like the length of a list is now.
My favourite would be a range method so we would have
the following idiom:
for i in lst.range():
do something with lst[i]
After going
Op 2005-04-21, Raymond Hettinger schreef [EMAIL PROTECTED]:
[Antoon Pardon]
I don't see why the start index can't be accessible through
a method or function just like the length of a list is now.
My favourite would be a range method so we would have
the following idiom:
for i in
[EMAIL PROTECTED] wrote:
Terry Hancock wrote:
snip
So I like Python's slicing because it bites *less* than intervals
in C or Fortran.
I disagree. Programming languages should not needlessly surprise
people, and a newbie to Python probably expects that x[1:3] =
[x[1],x[2],x[3]] . Array-oriented
Antoon Pardon wrote:
I sometimes think python should have been more explicite here,
using a marker for the start-index and end-index, may '^' and
'$'. So if you wanted the last element you had to write:
lst[$]
And for the next to last element:
lst[$ - 1]
This would make
Op 2005-04-21, Reinhold Birkenfeld schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
I sometimes think python should have been more explicite here,
using a marker for the start-index and end-index, may '^' and
'$'. So if you wanted the last element you had to write:
lst[$]
And for the
Op 2005-04-21, Steve Holden schreef [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote:
Terry Hancock wrote:
snip
So I like Python's slicing because it bites *less* than intervals
in C or Fortran.
I disagree. Programming languages should not needlessly surprise
people, and a newbie to Python
Antoon Pardon wrote:
Op 2005-04-21, Reinhold Birkenfeld schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
I sometimes think python should have been more explicite here,
using a marker for the start-index and end-index, may '^' and
'$'. So if you wanted the last element you had to write:
Op 2005-04-21, Reinhold Birkenfeld schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-04-21, Reinhold Birkenfeld schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
I sometimes think python should have been more explicite here,
using a marker for the start-index and end-index, may '^' and
Steve Holden wrote:
The principle of least surprise is all very well, but needless surprise
of newbies is a dangerous criterion to adopt for programming language
design and following it consistently would lead to a mess like Visual
Basic, which grew by accretion until Microsoft realized it was
Antoon Pardon wrote:
Op 2005-04-21, Steve Holden schreef [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote:
...
Along the same lines, I think the REQUIREMENT that x[0] rather
than
x[1] be the first element of list x is a mistake. At least the
programmer should have a choice, as in Fortran or
Dan Bishop [EMAIL PROTECTED] writes:
Name a problem space that inherently requires arrays to be 1-based
rather than 0-based.
inherently is too strong a word, since after all, we could do all
our computing with Turing machines.
Some algorithms are specified in terms of 1-based arrays. And most
Paul Rubin wrote:
Dan Bishop [EMAIL PROTECTED] writes:
Name a problem space that inherently requires arrays to be 1-based
rather than 0-based.
inherently is too strong a word, since after all, we could do all
our computing with Turing machines.
Some algorithms are specified in terms of 1-based
Ron wrote:
[EMAIL PROTECTED] wrote:
Many people I know ask why Python does slicing the way it does.
Can anyone /please/ give me a good defense/justification???
I'm referring to why mystring[:4] gives me
elements 0, 1, 2 and 3 but *NOT* mystring[4] (5th element).
There are actually 4 different
Antoon Pardon wrote:
This is nonsens. table[i] = j, just associates value j with key i.
That is the same independend from whether the keys can start from
0 or some other value.
Also, everyone, please keep in mind that you always have
the option of using a *dictionary*, in which case your
indices
Roy Smith wrote:
What would actually be cool is if Python were to support the normal math
notation for open or closed intervals.
foo = bar (1, 2)
foo = bar (1, 2]
foo = bar [1, 2)
foo = bar [1, 2]
That would certainly solve this particular problem, but the cost to the
rest of the language
[EMAIL PROTECTED] wrote:
I disagree. Programming languages should not needlessly surprise
people, and a newbie to Python probably expects that x[1:3] =
[x[1],x[2],x[3]].
But said newbie's expectations will differ considerably
depending on which other language he's coming from. So
he's almost
Dan Bishop wrote:
Antoon Pardon wrote:
snip
Like users have a choice in how long they make a list, they
should have a choice where the indexes start. (And that
shouldn't be limited to 0 and 1).
Suppose you could. Then what should
([3, 1, 4] indexbase 0) + ([1, 5, 9] indexbase 4)
[EMAIL PROTECTED] writes:
Suppose you could. Then what should
([3, 1, 4] indexbase 0) + ([1, 5, 9] indexbase 4)
equal?
If + means add, the result would be ([4,6,13] indexbase 0) .
That's counterintuitive. I'd expect c = a + b to result in c[i] =
a[i]+b[i] for all elements. So, for
Greg Ewing [EMAIL PROTECTED] wrote:
Also, everyone, please keep in mind that you always have
the option of using a *dictionary*, in which case your
indices can start wherever you want.
You can't slice them, true, but you can't have everything. :-)
Of course you can slice them, you just have
Roy Smith [EMAIL PROTECTED] writes:
Greg Ewing [EMAIL PROTECTED] wrote:
Also, everyone, please keep in mind that you always have
the option of using a *dictionary*, in which case your
indices can start wherever you want.
You can't slice them, true, but you can't have everything. :-)
Of
Many people I know ask why Python does slicing the way it does.
Can anyone /please/ give me a good defense/justification???
I'm referring to why mystring[:4] gives me
elements 0, 1, 2 and 3 but *NOT* mystring[4] (5th element).
Many people don't like idea that 5th element is not invited
[EMAIL PROTECTED]
Many people I know ask why Python does slicing the way it does.
Half open intervals are just one way of doing things. Each approach has its own
merits and issues.
Python's way has some useful properties:
* s == s[:i] + s[i:]
* len(s[i:j]) == j-i # if s is long
Raymond Hettinger wrote:
to seeing code like: for(i=0 ; in; i++) a[i]=f(i); In contrast, a
BASIC programmer may be used to FOR I = 1 to N: a[I]=f(I); NEXT.
Afaik, at least BBC BASIC uses zero based arrays :-) Maybe ZX Spectrum
Basic too (too long ago to remember).
--
John
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Many people I know ask why Python does slicing the way it does.
Can anyone /please/ give me a good defense/justification???
I'm referring to why mystring[:4] gives me
elements 0, 1, 2 and 3 but *NOT* mystring[4] (5th element).
mystring[:4] can
Hallchen!
[EMAIL PROTECTED] (Nick Efford) writes:
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Many people I know ask why Python does slicing the way it does.
Can anyone /please/ give me a good defense/justification???
I'm referring to why mystring[:4] gives me elements 0, 1, 2 and 3
On Wednesday 20 April 2005 01:36 am, Raymond Hettinger wrote:
[EMAIL PROTECTED]
Many people I know ask why Python does slicing the way it does.
[...]
Python's way has some useful properties:
[...]
OTOH, it has some aspects that bite:
[...]
I suspect that whether it feels natural
Op 2005-04-20, Torsten Bronger schreef [EMAIL PROTECTED]:
Hallöchen!
[EMAIL PROTECTED] (Nick Efford) writes:
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Many people I know ask why Python does slicing the way it does.
Can anyone /please/ give me a good defense/justification???
I'm
Raymond Hettinger [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED]
Many people I know ask why Python does slicing the way it does.
Python's way has some useful properties:
* s == s[:i] + s[i:]
* len(s[i:j]) == j-i # if s is long enough
The latter being particularly helpful when i = 0
On 20 Apr 2005 12:52:19 GMT, Antoon Pardon [EMAIL PROTECTED] wrote:
Op 2005-04-20, Torsten Bronger schreef [EMAIL PROTECTED]:
Hallöchen!
[EMAIL PROTECTED] (Nick Efford) writes:
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Many people I know ask why Python does slicing the way it does
Hallchen!
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2005-04-20, Torsten Bronger schreef [EMAIL PROTECTED]:
[...]
It's interesting to muse about a language that starts at 1 for
all arrays and strings, as some more or less obsolete languages
do. I think this is more intuitive, since most
Terry Hancock wrote:
snip
So I like Python's slicing because it bites *less* than intervals
in C or Fortran.
I disagree. Programming languages should not needlessly surprise
people, and a newbie to Python probably expects that x[1:3] =
[x[1],x[2],x[3]] . Array-oriented languages, such as
Antoon Pardon [EMAIL PROTECTED] wrote:
Personnaly I would like to have the choice. Sometimes I prefer to
start at 0, sometimes at 1 and other times at -13 or +7.
Argggh. Having two (or more!) ways to do it, would mean that every time I
read somebody else's code, I would have to figure out
I know ask why Python does slicing the way it does.
Can anyone /please/ give me a good defense/justification???
I'm referring to why mystring[:4] gives me elements 0, 1, 2 and 3
but *NOT* mystring[4] (5th element).
mystring[:4] can be read as the first four characters of
mystring
Op 2005-04-20, Roy Smith schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] wrote:
Personnaly I would like to have the choice. Sometimes I prefer to
start at 0, sometimes at 1 and other times at -13 or +7.
Argggh. Having two (or more!) ways to do it, would mean that every time I
Efford) writes:
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Many people I know ask why Python does slicing the way it does.
Can anyone /please/ give me a good defense/justification???
I'm referring to why mystring[:4] gives me elements 0, 1, 2 and 3
but *NOT* mystring[4] (5th
Personnaly I would like to have the choice. Sometimes I prefer to
start at 0, sometimes at 1 and other times at -13 or +7.
Subclass from builtin list - and make the necessary adjustmenst yourself in
an overloaded __getitem__.
--
Regards,
Diez B. Roggisch
--
Antoon Pardon [EMAIL PROTECTED] wrote:
Op 2005-04-20, Roy Smith schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] wrote:
Personnaly I would like to have the choice. Sometimes I prefer to
start at 0, sometimes at 1 and other times at -13 or +7.
Argggh. Having two (or more!) ways to
On Wednesday 20 April 2005 07:52 am, Antoon Pardon wrote:
Personnaly I would like to have the choice. Sometimes I prefer to
start at 0, sometimes at 1 and other times at -13 or +7.
Although I would classify that as a rare use case. So, it ought
to be possible to do it, but not necessarily
Torsten Bronger [EMAIL PROTECTED] writes:
It's interesting to muse about a language that starts at 1 for all
arrays and strings, as some more or less obsolete languages do. I
think this is more intuitive, since most people (including
mathematicians) start counting at 1. The reason for
Bernhard Herzog [EMAIL PROTECTED] writes:
There are very good reasons for half-open intervals and starting at 0
apart from memory organization. Dijkstra explained this quite well in
http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
Thanks for the excellent link!
--
Hallchen!
Bernhard Herzog [EMAIL PROTECTED] writes:
Torsten Bronger [EMAIL PROTECTED] writes:
It's interesting to muse about a language that starts at 1 for
all arrays and strings, as some more or less obsolete languages
do. I think this is more intuitive, since most people (including
Terry Hancock wrote:
However, I used to make off by one errors all the time in both C and Fortran,
whereas I hardly ever make them in Python.
This should probably be the overriding concern in this
case.
I can't remember the last time I made an off-by-one error
in Python (or, really, whether I ever
Torsten Bronger [EMAIL PROTECTED] writes:
http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
I see only one argument there: Inclusion of the upper bound would
then force the latter to be unnatural by the time the sequence has
shrunk to the empty one. While this surely is unaesthetical, I
Hallchen!
Bernhard Herzog [EMAIL PROTECTED] writes:
Torsten Bronger [EMAIL PROTECTED] writes:
http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
I see only one argument there: Inclusion of the upper bound
would then force the latter to be unnatural by the time the
sequence has shrunk
Terry Hancock wrote:
I used to make off by one errors all the time in both C and Fortran,
whereas I hardly ever make them in Python.
Part of the reason may be that most loops over lists involve
iterators, where the details of the index limits are hidden. In
Python, you write:
for item in
On Tuesday 19 April 2005 10:58 pm, [EMAIL PROTECTED] wrote:
Many people I know ask why Python does slicing the way it does.
Can anyone /please/ give me a good defense/justification???
Here you go, no remembering +1 or -1. Also, see the hundreds of other
times this topic has graced
. always.
-Jim
On 19 Apr 2005 22:58:49 -0700, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Many people I know ask why Python does slicing the way it does.
Can anyone /please/ give me a good defense/justification???
I'm referring to why mystring[:4] gives me
elements 0, 1, 2 and 3
I like this, it works for any integer.
str=asdfjkl;
i=-400
print str[:i]+str[i:]
asdfjkl;
i = 65534214
print str[:i]+str[i:]
asdfjkl;
Please forgive my reassigning str. I am one of those type first think later
programmers.
--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
[EMAIL PROTECTED] escribió en el mensaje
news:[EMAIL PROTECTED]
Many people I know ask why Python does slicing the way it does.
Can anyone /please/ give me a good defense/justification???
I'm referring to why mystring[:4] gives me
elements 0, 1, 2 and 3 but *NOT* mystring[4] (5th
James Stroud [EMAIL PROTECTED] escribió en el mensaje
news:[EMAIL PROTECTED]
I like this, it works for any integer.
str=asdfjkl;
i=-400
print str[:i]+str[i:]
asdfjkl;
i = 65534214
print str[:i]+str[i:]
asdfjkl;
Actually, this has no relation with the half-open
slices but with the
On Wednesday 20 April 2005 12:28 pm, Roy Smith wrote:
Terry Hancock wrote:
I used to make off by one errors all the time in both C and Fortran,
whereas I hardly ever make them in Python.
Part of the reason may be that most loops over lists involve
iterators,
both endpoints are
James Carroll wrote:
If you have five elements, numbered 0,1,2,3,4 and you ask for the
elements starting with the first one, and so on for the length you
would have [0:length]. So [0:5] gives you elemets 0,1,2,3,4. Think
of the weirdess if you had to ask for [0:length-1] to get length
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2005-04-20, Torsten Bronger schreef [EMAIL PROTECTED]:
Hallöchen!
[EMAIL PROTECTED] (Nick Efford) writes:
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Many people I know ask why Python does slicing the way it does.
Can anyone /please/ give me
67 matches
Mail list logo
