The first element in a list is element zero, the second is one, the third it two, and so on. This some times confuses newbies to the language or programming in general. This system was invited when single bits where precious. It's time to update. Keep in mind this is something for version 4, since its not reverse compatible. I say we make the first element 1, second 2, third 3, and so on. Other languages would follow. We are python, made for easiness and readability, and we are in the age where you can't even get something as small as a kilobyte USB. We must make first one, second 2, and third 3, like it is supposed to be. I give this: *+1*
On Fri, Sep 9, 2011 at 2:12 PM, Christopher King <g.nius.ck@gmail.com> wrote:
The first element in a list is element zero, the second is one, the third it two, and so on.
Those are not element numbers, but offsets. What is confusing is calling them element numbers. Back in the days of dinosaurs, you would write the access to containers yourself, so you if you wanted to access the first element, the memory offset is zero from the beginning. If you want the second element the memory offset is 1 X length of element from the beginning, etc. This has carried forward as languages have moved forward. A dictionary would be the choice for indexing by 1, 2, 3, etc. -- Unless your heart is open and serene, with nothing touching your feelings, how can you respond completely without error,,,,,Yuanwu
Recommended reading: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html On Sat, Sep 10, 2011 at 7:12 AM, Christopher King <g.nius.ck@gmail.com> wrote:
On Fri, Sep 9, 2011 at 6:32 PM, Matt Joiner <anacrolix@gmail.com> wrote:
Recommended reading: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html
Nice one! Reminds me of these two lines from the zen of Python: There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. -- --Guido van Rossum (python.org/~guido)
On Sep 9, 2011, at 3:32 PM, Matt Joiner wrote:
Recommended reading: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html
The reasoning in this letter is so terrible. Why do people quote this whenever this comes up? "We should start lists at 0 because when writing for-loops the <= look goofy otherwise." Why on earth should Pythonistas care what the for-loops are like when we only have for-each loops! It's crazy. Look, EWD was a good computer scientist (=MATHEMATICIAN), but he was terrible when it comes to the ART of programming language design. There's no reason to think that being a good mathematician would make one also good at designing a user interface, and that's what a programming language is--a user interface for highly advanced users. Other than "Go To Considered Harmful" everything I've read of his about programming has been wrong. (Correctness proofs, really?) And much of that wrongness stems from EWD's false belief that programming should be the same as math. Now, as it happens, I don't think we should change to using 1 (although I do note that Lua gets along fine with it). But the reason not to change is because 0 is a well entrenched standard so most programmers are more used to it than to 1. In other words, it's the standard because in UI design you stick with what your users will expect. It has nothing to do with some arcane mathematician's gobbledygook writings about greater than and less than signs. Programming language design is the art of making something that helps humans work more efficiently, not some pure mathematics descended from Platonic heaven. Sorry to rant, but that article always comes up and so I have grudge against EWD.
Well it makes complete sense to me. Furthermore, Python even properly supports the style of conditional he uses. a <= b < c IS a great way to do things. 0 based indexing IS right for computing. Not sure if you're trolling or I'm not counter-trolling... -.- EWD is the man. Dutch programmers in decades to come have a lot to live up to. On Sat, Sep 10, 2011 at 2:10 PM, Carl Matthew Johnson <cmjohnson.mailinglist@gmail.com> wrote:
On Sat, Sep 10, 2011 at 3:08 AM, Matt Joiner <anacrolix@gmail.com> wrote:
I think I'm doing okay. :-) (And to those taking the thread seriously: this is all in jest. We won't change the indexing base. The idea is so preposterous that the only kind of response possible is to laugh with it.) --Guido
-- --Guido van Rossum (python.org/~guido)
Carl Matthew Johnson wrote:
Um... have you actually read that article? He doesn't mention "for loops" at all, or any other kind of loop, for that matter. Neither does he say anything about the appearance of the comparison operators. He does talk about the values of the range endpoints, and mentions notations for ranges and array lower bounds in various languages. Python has equivalents of those -- sequence indexes, range() parameters, slice indexes, etc. Most of what he says applies perfectly well to Python. -- Greg
On Sat, Sep 10, 2011 at 6:26 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
EWD points out the power of half-open intervals, which I independently discovered when I considered the issue of indexing and slicing in Python. If you consider that arcane mathematics I'm not sure I really want to use any code you wrote... -- --Guido van Rossum (python.org/~guido)
Christopher King writes:
We must make first one, second 2, and third 3, like it is supposed to be.
There's a better way: def first (sequence): return sequence['one'] # <wink/> def second (sequence): return sequence[1] def third (sequence): return sequence[2] def fourth (sequence): return sequence[3] def fifth (sequence): return sequence[4] def sixth (sequence): return sequence[5] def seventh (sequence): return sequence[6] def eighth (sequence): return sequence[7] There's probably an Ordinal module that would allow you to generate such functions to your heart's content. I'll have to wait for Guido's pronouncement about whether it's "more Pythonic" as well as "just plain better" though.
On Fri, Sep 9, 2011 at 2:12 PM, Christopher King <g.nius.ck@gmail.com>wrote:
Well, given Guido's endorsement, I think we need to change how these +1/-1 votes work. Clearly, +1 means what +0 used to mean. So you have to say +2 to vote in favor of something and -0 to vote against. I know it will be confusing during the transition period but it will be so much easier to use when we are done. On Fri, Sep 9, 2011 at 7:08 PM, Guido van Rossum <guido@python.org> wrote:
Given this change, I think you mean: There should be two -- and preferably only two -- obvious ways to do it. --- Bruce Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
On Sat, Sep 10, 2011 at 3:11 PM, Christopher King <g.nius.ck@gmail.com> wrote:
I understood that. -- I think others did too but found the proposal so preposterous that they started posting nonsensical "solutions" based on an intentionally literalistic misreading of your original post. (If you think this is odd, realize that Python was named after Monty Python's Flying Circus -- we occasionally like to show off our warped sense of humor. :-) Anyway, the reason your proposal is not going to fly, quite apart of whether it would be a good idea for a brand new language design(*), is that there is over 20 years of existing Python code that would have to be changed, not to mention the brains of millions of users, and hundreds of books about Python. Plus pretty much every other language in widespread use today (C, C++, Java, C#, JavaScript, Ruby, to name a few; presumably also Objective C given its C inheritance) agrees that indexes start at zero. It is a cultural battle that has been fought and won long ago (all the old languages used 1-based indexing: Fortran, Algol, Pascal) and it's really not that important in the grand scheme of things, so the status quo wins. (*) I personally think 0-based indexing is better, and the referenced EWD expresses why better than I could. But I'm sure that if we lived in a world where 1-based indexing was the norm I'd get by just fine. -- --Guido van Rossum (python.org/~guido)
Guido van Rossum wrote:
Lua appears to be a conspicuous counter-example of a relatively recent popular language with 1-based indexing. See the (extremely incomplete!) list here: http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_fun...) 0-based indexes are useful for some tasks, and less useful for other tasks. In my experience, I find that 0-based indexing is more useful most of the time: it leads to fewer off-by-one errors. 1-based indexes are particularly well-suited for programming languages using a natural language metaphor, usually aimed at non-programmers. Examples include Xion, Applescript, and Inform-7. The Ubiquity desktop appears to be aiming for a natural language scripting language, like Applescript only more so: http://mitcho.com/blog/projects/how-natural-should-a-natural-interface-be/ -- Steven
On Sun, Sep 11, 2011 at 10:37 AM, Steven D'Aprano <steve@pearwood.info> wrote:
Indeed, the concepts of half-open ranges and 0-based indexing go hand in hand (as described in the EWD article), and it ties directly in to the notion of *index arithmetic*. A case that illustrates this nicely is that of partitioning a sequence. Suppose we want the first 5 items in one subsequence and the rest in another. This is easy to write, and requires no adjustments to the numbers: head = seq[:5] assert len(head) == 5 tail = seq[5:] assert len(tail) == len(seq) - 5 Zero based indexing (in conjunction with half-open ranges) makes the arithmetic work out nicely, and, in practice, that turns out to be important when it comes to writing correct programs. However, it comes at the cost of breaking the intuitive mapping to the counting numbers: the first item is at offset 0, the second is at offset 1, etc. This is a definite downside, but the collective judgment of many language designers is that the reduction in off-by-one errors when manipulating indices is worth the additional difficulty in learning the language for programming novices. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I was about to propose this: class List(list): def __getitem__(self,i): """ a = List() a.append(4) a.appned(5) print a[0.5] 4.5 """ if isinstance(i,(int,long)): return list.__getitem__(self,i) else: j = int(i) x = i - j return self[j]*(1.0-x)+self[j+1]*x On Sep 10, 2011, at 8:51 PM, Nick Coghlan wrote:
On Sat, Sep 10, 2011 at 7:51 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
This discussion has reminded me of a post from Tim Peters I stumbled on a few weeks ago: http://mail.python.org/pipermail/python-list/2000-October/637704.html "The trick is that indices in Python point *between* array elements"... Terry Reedy also explained this pretty well, I thought: http://mail.python.org/pipermail/python-list/2005-September/927859.html -eric * Tim also had an earlier, but similar post that I found when looking for the remembered one: http://mail.python.org/pipermail/python-list/1999-August/622024.html
On Sun, 2011-09-11 at 11:51 +1000, Nick Coghlan wrote:
Python slicing was designed with indexing in mind. If we had used counts instead, we could have just added a bit of syntax to make things work in a nice way. The biggest difference isn't the math, but having a way to specify weather a count, is inclusive or exclusive. Given that, the math will work just as nice. (note: using '...' instead of ':' to make it clear it's different.) head = seq[...n] # the first n items tail = seq[n>...] # items after first n items assert len(head) = n assert len(head) + len(tail) = len(seq) And the reverse works too. tail = seq[-n...] # the last n items head = seq[...<-n] # items before the last n items assert len(tail) == n assert len(head) + len(tail) == len(seq) And then you also have. before = seq[...<n] item = seq[n] after = seq[n>...] And while we're at it. inner = seq[n1...n2] # items from n1 to n2, including n2 inner = seq[n1>...<n2] # items after n1, and before n2 outer = seq[...<n>...] # everything but item n thewholething = seq[...] Adding items to the front and back. seq[...<1] = seq # prepend items seq[-1>...] = seq # append items etc... So it can be done either way. It's just not good to try and mix index's with counts. (Not suggesting we do this, but if we were starting from scratch, I don't see any problems with it.) Cheers, Ron
On Sun, 2011-09-11 at 09:32 -0700, Guido van Rossum wrote:
I meant that I didn't see a problem with using counts instead of indexes, if we were starting from scratch, and if that was the only way to do it. Here's a good guideline that isn't in The Zen of Python... Just because "it can be done", isn't a reason to do it! ;-) Cheers, Ron (Fixed my email name, so maybe this will get posted faster instead of taking a whole day to show up.)
Ok, how about enhancing the list type to allow specifying an offset, defaulting to 0? The offset should be positive, and that many elements simple aren't there. Asking for an element that isn't there, or a slice including such an element, raises value error exception. The iterators & etc for this list would all start at offset instead of zero. -- Sent from my Android tablet with K-9 Mail. Please excuse my brevity.
mike.w.meyer@gmail.com wrote:
I believe that Ada allows that. Any Ada users want to comment on how useful or annoying this is? Another alternative would be to specify the indexing scheme at call time, rather than when you create the list. Something like: item = mylist[7 starting from 5] will set item to mylist[2] (using zero-based indexing). Best of all, with a slight change of syntax, that is available right now: item = mylist[7-5] and so we can simulate variable-offset indexing with no new syntax and only a very small run-time cost. Guido's time machine strikes again! <wink> -- Steven
Steven D'Aprano wrote:
I believe that Ada allows that. Any Ada users want to comment on how useful or annoying this is?
I think that sort of thing works better in a statically-typed language, because anything you pass to a library needs to be of a data type defined by that library, or at least known to the library, so both the library and the caller are aware of the indexing scheme being used. With duck-typing, on the other hand, it just seems like a recipe for confusion. -- Greg
On 9/12/2011 2:05 AM, mike.w.meyer@gmail.com wrote:
Ok, how about enhancing the list type to allow specifying an offset,
Because then every list index/slice access would require more time to subtract the offset.
Slicing never raises a ValueError. In particular, seq[0:1] always returns a sequence with 1 or 0 items. This is an important feature.
The iterators& etc for this list would all start at offset instead of zero.
Write a list subclass. Decide how you would handle indexing from the right (currently all negative indexes) and implement that. -- Terry Jan Reedy
On 10/09/2011 23:34, Guido van Rossum wrote:
I'm really not seriously suggesting this... but it might be possible to do something similar for Python. You could add an optional initial_index argument (with a default of zero) to the constructor for sequence types and then modify any operations that involve indexing. Andrew
On Sat, Sep 10, 2011 at 17:11, Christopher King <g.nius.ck@gmail.com> wrote:
I think everyone knows what your suggestion was - list indexes starting at 1 instead of 0. Simply put, it won't happen. Think of this: by the time Python 4 even rolls around, it might be 10+ years down the road, putting Python at 30+ years old. We can't change something so fundamental to not only Python, but almost all other languages, after 30+ years of existence in Python and even more elsewhere.
On 9 September 2011 22:12, Christopher King <g.nius.ck@gmail.com> wrote:
How about this (works with current and future pythons):
Michael Foord
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On Fri, Sep 9, 2011 at 2:12 PM, Christopher King <g.nius.ck@gmail.com> wrote:
The first element in a list is element zero, the second is one, the third it two, and so on.
Those are not element numbers, but offsets. What is confusing is calling them element numbers. Back in the days of dinosaurs, you would write the access to containers yourself, so you if you wanted to access the first element, the memory offset is zero from the beginning. If you want the second element the memory offset is 1 X length of element from the beginning, etc. This has carried forward as languages have moved forward. A dictionary would be the choice for indexing by 1, 2, 3, etc. -- Unless your heart is open and serene, with nothing touching your feelings, how can you respond completely without error,,,,,Yuanwu
Recommended reading: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html On Sat, Sep 10, 2011 at 7:12 AM, Christopher King <g.nius.ck@gmail.com> wrote:
On Fri, Sep 9, 2011 at 6:32 PM, Matt Joiner <anacrolix@gmail.com> wrote:
Recommended reading: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html
Nice one! Reminds me of these two lines from the zen of Python: There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. -- --Guido van Rossum (python.org/~guido)
On Sep 9, 2011, at 3:32 PM, Matt Joiner wrote:
Recommended reading: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html
The reasoning in this letter is so terrible. Why do people quote this whenever this comes up? "We should start lists at 0 because when writing for-loops the <= look goofy otherwise." Why on earth should Pythonistas care what the for-loops are like when we only have for-each loops! It's crazy. Look, EWD was a good computer scientist (=MATHEMATICIAN), but he was terrible when it comes to the ART of programming language design. There's no reason to think that being a good mathematician would make one also good at designing a user interface, and that's what a programming language is--a user interface for highly advanced users. Other than "Go To Considered Harmful" everything I've read of his about programming has been wrong. (Correctness proofs, really?) And much of that wrongness stems from EWD's false belief that programming should be the same as math. Now, as it happens, I don't think we should change to using 1 (although I do note that Lua gets along fine with it). But the reason not to change is because 0 is a well entrenched standard so most programmers are more used to it than to 1. In other words, it's the standard because in UI design you stick with what your users will expect. It has nothing to do with some arcane mathematician's gobbledygook writings about greater than and less than signs. Programming language design is the art of making something that helps humans work more efficiently, not some pure mathematics descended from Platonic heaven. Sorry to rant, but that article always comes up and so I have grudge against EWD.
Well it makes complete sense to me. Furthermore, Python even properly supports the style of conditional he uses. a <= b < c IS a great way to do things. 0 based indexing IS right for computing. Not sure if you're trolling or I'm not counter-trolling... -.- EWD is the man. Dutch programmers in decades to come have a lot to live up to. On Sat, Sep 10, 2011 at 2:10 PM, Carl Matthew Johnson <cmjohnson.mailinglist@gmail.com> wrote:
On Sat, Sep 10, 2011 at 3:08 AM, Matt Joiner <anacrolix@gmail.com> wrote:
I think I'm doing okay. :-) (And to those taking the thread seriously: this is all in jest. We won't change the indexing base. The idea is so preposterous that the only kind of response possible is to laugh with it.) --Guido
-- --Guido van Rossum (python.org/~guido)
Carl Matthew Johnson wrote:
Um... have you actually read that article? He doesn't mention "for loops" at all, or any other kind of loop, for that matter. Neither does he say anything about the appearance of the comparison operators. He does talk about the values of the range endpoints, and mentions notations for ranges and array lower bounds in various languages. Python has equivalents of those -- sequence indexes, range() parameters, slice indexes, etc. Most of what he says applies perfectly well to Python. -- Greg
On Sat, Sep 10, 2011 at 6:26 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
EWD points out the power of half-open intervals, which I independently discovered when I considered the issue of indexing and slicing in Python. If you consider that arcane mathematics I'm not sure I really want to use any code you wrote... -- --Guido van Rossum (python.org/~guido)
Christopher King writes:
We must make first one, second 2, and third 3, like it is supposed to be.
There's a better way: def first (sequence): return sequence['one'] # <wink/> def second (sequence): return sequence[1] def third (sequence): return sequence[2] def fourth (sequence): return sequence[3] def fifth (sequence): return sequence[4] def sixth (sequence): return sequence[5] def seventh (sequence): return sequence[6] def eighth (sequence): return sequence[7] There's probably an Ordinal module that would allow you to generate such functions to your heart's content. I'll have to wait for Guido's pronouncement about whether it's "more Pythonic" as well as "just plain better" though.
On Fri, Sep 9, 2011 at 2:12 PM, Christopher King <g.nius.ck@gmail.com>wrote:
Well, given Guido's endorsement, I think we need to change how these +1/-1 votes work. Clearly, +1 means what +0 used to mean. So you have to say +2 to vote in favor of something and -0 to vote against. I know it will be confusing during the transition period but it will be so much easier to use when we are done. On Fri, Sep 9, 2011 at 7:08 PM, Guido van Rossum <guido@python.org> wrote:
Given this change, I think you mean: There should be two -- and preferably only two -- obvious ways to do it. --- Bruce Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
On Sat, Sep 10, 2011 at 3:11 PM, Christopher King <g.nius.ck@gmail.com> wrote:
I understood that. -- I think others did too but found the proposal so preposterous that they started posting nonsensical "solutions" based on an intentionally literalistic misreading of your original post. (If you think this is odd, realize that Python was named after Monty Python's Flying Circus -- we occasionally like to show off our warped sense of humor. :-) Anyway, the reason your proposal is not going to fly, quite apart of whether it would be a good idea for a brand new language design(*), is that there is over 20 years of existing Python code that would have to be changed, not to mention the brains of millions of users, and hundreds of books about Python. Plus pretty much every other language in widespread use today (C, C++, Java, C#, JavaScript, Ruby, to name a few; presumably also Objective C given its C inheritance) agrees that indexes start at zero. It is a cultural battle that has been fought and won long ago (all the old languages used 1-based indexing: Fortran, Algol, Pascal) and it's really not that important in the grand scheme of things, so the status quo wins. (*) I personally think 0-based indexing is better, and the referenced EWD expresses why better than I could. But I'm sure that if we lived in a world where 1-based indexing was the norm I'd get by just fine. -- --Guido van Rossum (python.org/~guido)
Guido van Rossum wrote:
Lua appears to be a conspicuous counter-example of a relatively recent popular language with 1-based indexing. See the (extremely incomplete!) list here: http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_fun...) 0-based indexes are useful for some tasks, and less useful for other tasks. In my experience, I find that 0-based indexing is more useful most of the time: it leads to fewer off-by-one errors. 1-based indexes are particularly well-suited for programming languages using a natural language metaphor, usually aimed at non-programmers. Examples include Xion, Applescript, and Inform-7. The Ubiquity desktop appears to be aiming for a natural language scripting language, like Applescript only more so: http://mitcho.com/blog/projects/how-natural-should-a-natural-interface-be/ -- Steven
On Sun, Sep 11, 2011 at 10:37 AM, Steven D'Aprano <steve@pearwood.info> wrote:
Indeed, the concepts of half-open ranges and 0-based indexing go hand in hand (as described in the EWD article), and it ties directly in to the notion of *index arithmetic*. A case that illustrates this nicely is that of partitioning a sequence. Suppose we want the first 5 items in one subsequence and the rest in another. This is easy to write, and requires no adjustments to the numbers: head = seq[:5] assert len(head) == 5 tail = seq[5:] assert len(tail) == len(seq) - 5 Zero based indexing (in conjunction with half-open ranges) makes the arithmetic work out nicely, and, in practice, that turns out to be important when it comes to writing correct programs. However, it comes at the cost of breaking the intuitive mapping to the counting numbers: the first item is at offset 0, the second is at offset 1, etc. This is a definite downside, but the collective judgment of many language designers is that the reduction in off-by-one errors when manipulating indices is worth the additional difficulty in learning the language for programming novices. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I was about to propose this: class List(list): def __getitem__(self,i): """ a = List() a.append(4) a.appned(5) print a[0.5] 4.5 """ if isinstance(i,(int,long)): return list.__getitem__(self,i) else: j = int(i) x = i - j return self[j]*(1.0-x)+self[j+1]*x On Sep 10, 2011, at 8:51 PM, Nick Coghlan wrote:
On Sat, Sep 10, 2011 at 7:51 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
This discussion has reminded me of a post from Tim Peters I stumbled on a few weeks ago: http://mail.python.org/pipermail/python-list/2000-October/637704.html "The trick is that indices in Python point *between* array elements"... Terry Reedy also explained this pretty well, I thought: http://mail.python.org/pipermail/python-list/2005-September/927859.html -eric * Tim also had an earlier, but similar post that I found when looking for the remembered one: http://mail.python.org/pipermail/python-list/1999-August/622024.html
On Sun, 2011-09-11 at 11:51 +1000, Nick Coghlan wrote:
Python slicing was designed with indexing in mind. If we had used counts instead, we could have just added a bit of syntax to make things work in a nice way. The biggest difference isn't the math, but having a way to specify weather a count, is inclusive or exclusive. Given that, the math will work just as nice. (note: using '...' instead of ':' to make it clear it's different.) head = seq[...n] # the first n items tail = seq[n>...] # items after first n items assert len(head) = n assert len(head) + len(tail) = len(seq) And the reverse works too. tail = seq[-n...] # the last n items head = seq[...<-n] # items before the last n items assert len(tail) == n assert len(head) + len(tail) == len(seq) And then you also have. before = seq[...<n] item = seq[n] after = seq[n>...] And while we're at it. inner = seq[n1...n2] # items from n1 to n2, including n2 inner = seq[n1>...<n2] # items after n1, and before n2 outer = seq[...<n>...] # everything but item n thewholething = seq[...] Adding items to the front and back. seq[...<1] = seq # prepend items seq[-1>...] = seq # append items etc... So it can be done either way. It's just not good to try and mix index's with counts. (Not suggesting we do this, but if we were starting from scratch, I don't see any problems with it.) Cheers, Ron
On Sun, 2011-09-11 at 09:32 -0700, Guido van Rossum wrote:
I meant that I didn't see a problem with using counts instead of indexes, if we were starting from scratch, and if that was the only way to do it. Here's a good guideline that isn't in The Zen of Python... Just because "it can be done", isn't a reason to do it! ;-) Cheers, Ron (Fixed my email name, so maybe this will get posted faster instead of taking a whole day to show up.)
Ok, how about enhancing the list type to allow specifying an offset, defaulting to 0? The offset should be positive, and that many elements simple aren't there. Asking for an element that isn't there, or a slice including such an element, raises value error exception. The iterators & etc for this list would all start at offset instead of zero. -- Sent from my Android tablet with K-9 Mail. Please excuse my brevity.
mike.w.meyer@gmail.com wrote:
I believe that Ada allows that. Any Ada users want to comment on how useful or annoying this is? Another alternative would be to specify the indexing scheme at call time, rather than when you create the list. Something like: item = mylist[7 starting from 5] will set item to mylist[2] (using zero-based indexing). Best of all, with a slight change of syntax, that is available right now: item = mylist[7-5] and so we can simulate variable-offset indexing with no new syntax and only a very small run-time cost. Guido's time machine strikes again! <wink> -- Steven
Steven D'Aprano wrote:
I believe that Ada allows that. Any Ada users want to comment on how useful or annoying this is?
I think that sort of thing works better in a statically-typed language, because anything you pass to a library needs to be of a data type defined by that library, or at least known to the library, so both the library and the caller are aware of the indexing scheme being used. With duck-typing, on the other hand, it just seems like a recipe for confusion. -- Greg
On 9/12/2011 2:05 AM, mike.w.meyer@gmail.com wrote:
Ok, how about enhancing the list type to allow specifying an offset,
Because then every list index/slice access would require more time to subtract the offset.
Slicing never raises a ValueError. In particular, seq[0:1] always returns a sequence with 1 or 0 items. This is an important feature.
The iterators& etc for this list would all start at offset instead of zero.
Write a list subclass. Decide how you would handle indexing from the right (currently all negative indexes) and implement that. -- Terry Jan Reedy
On 10/09/2011 23:34, Guido van Rossum wrote:
I'm really not seriously suggesting this... but it might be possible to do something similar for Python. You could add an optional initial_index argument (with a default of zero) to the constructor for sequence types and then modify any operations that involve indexing. Andrew
On Sat, Sep 10, 2011 at 17:11, Christopher King <g.nius.ck@gmail.com> wrote:
I think everyone knows what your suggestion was - list indexes starting at 1 instead of 0. Simply put, it won't happen. Think of this: by the time Python 4 even rolls around, it might be 10+ years down the road, putting Python at 30+ years old. We can't change something so fundamental to not only Python, but almost all other languages, after 30+ years of existence in Python and even more elsewhere.
On 9 September 2011 22:12, Christopher King <g.nius.ck@gmail.com> wrote:
How about this (works with current and future pythons):
Michael Foord
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
participants (24)
-
Adam Jorgensen -
Andrew McLean -
Brian Curtin -
Bruce Leban -
Carl Matthew Johnson -
Christopher King -
David Blaschke -
Eric Snow -
Greg Ewing -
Guido van Rossum -
Jakob Bowyer -
John O'Connor -
Massimo DiPierro -
Matt Joiner -
Michael Foord -
mike.w.meyer＠gmail.com -
MRAB -
Nick Coghlan -
Ron Adam -
ron3200
-
Stephen J. Turnbull -
Steven D'Aprano -
Steven Klass -
Terry Reedy