The first item in a sequence is at index zero because it is that far away from
the beginning. The second item is one away from the beginning. That is the
reason for zero-based indexing.
--
http://mail.python.org/mailman/listinfo/python-list
On 03:56 am, tjre...@udel.edu wrote:
exar...@twistedmatrix.com wrote:
There's a lot of things in Python that I don't strictly *need*. That
doesn't mean that they wouldn't be welcome if I could have them.
Getting rid of the range/xrange dichotomy would improve things.
The developers agreed a
exar...@twistedmatrix.com wrote:
There's a lot of things in Python that I don't strictly *need*. That
doesn't mean that they wouldn't be welcome if I could have them. Getting
rid of the range/xrange dichotomy would improve things.
The developers agreed a couple of years ago. Starting using 3
On Aug 17, 12:59 pm, Carl Banks wrote:
> The cost doesn't even remotely justify it.
I mean, it doesn't even remotely justify the cost.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Aug 17, 12:41 pm, exar...@twistedmatrix.com wrote:
> There's a lot of things in Python that I don't strictly *need*. That
> doesn't mean that they wouldn't be welcome if I could have them.
> Getting rid of the range/xrange dichotomy would improve things. Yes, I
> can work around it until the r
On 06:32 pm, pavlovevide...@gmail.com wrote:
On Aug 17, 4:40�am, exar...@twistedmatrix.com wrote:
On 02:12 am, pavlovevide...@gmail.com wrote:
>On Aug 16, 3:35�pm, sturlamolden wrote:
>>On 16 Aug, 14:57, Dennis Lee Bieber wrote:
>> > � � � � Well, the alternative would be to ha
On Aug 17, 4:40 am, exar...@twistedmatrix.com wrote:
> On 02:12 am, pavlovevide...@gmail.com wrote:
>
>
>
> >On Aug 16, 3:35 pm, sturlamolden wrote:
> >>On 16 Aug, 14:57, Dennis Lee Bieber wrote:
>
> >> > Well, the alternative would be to have two keywords for
> >>looping: one
> >> > for
Emmanuel Surleau wrote:
Dr. Phillip M. Feldman wrote:
[snip]
def is_prime(n):
for j in range(2,n):
if (n % j) == 0: return False
return True
It seems as though Python is actually expanding range(2,n) into a list of
numbers, even though this is incredibly wasteful of memory. There
On Sun, Aug 16, 2009 at 11:10 PM, Nobody wrote:
> Java also has iterators; it's more a case of people coming from C and BASIC.
>
> Although, some of those may have come *through* Java without abandoning
> old habits. You see the same thing with people coming from BASIC to C and
> writing:
>
>
John Machin wrote:
> On Aug 17, 8:35 am, sturlamolden wrote:
>
>> A compiler could easily recognise a statement like
>>for i in range(n):
>> as a simple integer loop. In fact, Cython is able to do this.
>
> Extremely easy, once users relinquish the right to replace built-in
> "range" with th
On Sun, 16 Aug 2009 15:35:26 -0700, sturlamolden wrote:
> On 16 Aug, 14:57, Dennis Lee Bieber wrote:
>
>> Well, the alternative would be to have two keywords for
>> looping: one
>> for your "simple" incrementing integer loop, and another for a loop
>> that operates over the eleme
Carl Banks wrote:
> On Aug 16, 3:35 pm, sturlamolden wrote:
>> On 16 Aug, 14:57, Dennis Lee Bieber wrote:
>>
>>> Well, the alternative would be to have two keywords for looping: one
>>> for your "simple" incrementing integer loop, and another for a loop that
>>> operates over the elements
exar...@twistedmatrix.com wrote:
On 02:12 am, pavlovevide...@gmail.com wrote:
On Aug 16, 3:35�pm, sturlamolden wrote:
On 16 Aug, 14:57, Dennis Lee Bieber wrote:
> � � � � Well, the alternative would be to have two keywords for
looping: one
> for your "simple" incrementing integer loop, and
On 16 Aug, 19:12, Carl Banks wrote:
> If you don't care about the dynamic stuff why don't you just use
> Cython? Or quit complaining and just use xrange.
I think you are the only one complaining here.
--
http://mail.python.org/mailman/listinfo/python-list
On 01:44 am, http wrote:
exar...@twistedmatrix.com writes:
Although I think PyPy also recognizes this case and makes it as
efficient as using xrange, and does so without breaking any rules.
How can pypy possibly know that the user hasn't assigned some other
value to "range"?
It doesn't reall
On 01:53 am, pavlovevide...@gmail.com wrote:
On Aug 16, 6:28�pm, exar...@twistedmatrix.com wrote:
On 01:23 am, benjamin.kap...@case.edu wrote:
>On Sun, Aug 16, 2009 at 6:35 PM, sturlamolden
>wrote:
>>A compiler could easily recognise a statement like
>>� for i in range(n):
>>as a simple int
On 02:12 am, pavlovevide...@gmail.com wrote:
On Aug 16, 3:35�pm, sturlamolden wrote:
On 16 Aug, 14:57, Dennis Lee Bieber wrote:
> Well, the alternative would be to have two keywords for
looping: one
> for your "simple" incrementing integer loop, and another for a loop
that
> oper
On Sun, 16 Aug 2009 11:41:21 -0400, Benjamin Kaplan wrote:
> It's not that the code is bad, but too many people coming from Java
> and C keep thinking of for loops like they're using Java or C and
> therefore that "for i in range(a,b)" is identical to "for(int i = a; i
> < b; i++)". It's not and,
On Aug 16, 3:35 pm, sturlamolden wrote:
> On 16 Aug, 14:57, Dennis Lee Bieber wrote:
>
> > Well, the alternative would be to have two keywords for looping: one
> > for your "simple" incrementing integer loop, and another for a loop that
> > operates over the elements of some collection ty
On Aug 16, 6:28 pm, exar...@twistedmatrix.com wrote:
> On 01:23 am, benjamin.kap...@case.edu wrote:
>
> >On Sun, Aug 16, 2009 at 6:35 PM, sturlamolden
> >wrote:
>
> >>A compiler could easily recognise a statement like
>
> >> for i in range(n):
>
> >>as a simple integer loop. In fact, Cython is ab
exar...@twistedmatrix.com writes:
> Although I think PyPy also recognizes this case and makes it as
> efficient as using xrange, and does so without breaking any rules.
How can pypy possibly know that the user hasn't assigned some other
value to "range"?
--
http://mail.python.org/mailman/listinfo
On 01:23 am, benjamin.kap...@case.edu wrote:
On Sun, Aug 16, 2009 at 6:35 PM, sturlamolden
wrote:
A compiler could easily recognise a statement like
� for i in range(n):
as a simple integer loop. In fact, Cython is able to do this.
but special cases aren't special enough to break the rules
On Aug 17, 8:35 am, sturlamolden wrote:
> A compiler could easily recognise a statement like
> for i in range(n):
> as a simple integer loop. In fact, Cython is able to do this.
Extremely easy, once users relinquish the right to replace built-in
"range" with their own concoctions ...
--
htt
On Sun, Aug 16, 2009 at 6:35 PM, sturlamolden wrote:
>
> A compiler could easily recognise a statement like
>
> for i in range(n):
>
> as a simple integer loop. In fact, Cython is able to do this.
but special cases aren't special enough to break the rules.
--
http://mail.python.org/mailman/lis
On 16 Aug, 14:57, Dennis Lee Bieber wrote:
> Well, the alternative would be to have two keywords for looping: one
> for your "simple" incrementing integer loop, and another for a loop that
> operates over the elements of some collection type.
A compiler could easily recognise a statement
On 16 Aug, 11:45, "bartc" wrote:
> A for-loop, for iterating over a simple sequence, should be one of the
> fastest things in the language.
Anyone experienced with interpreted high-level languages knows this is
not true. Not because iterating a sequence is expensive, but because
the interpreter
bartc wrote:
"Steven D'Aprano" wrote in
message news:02969972$0$20647$c3e8...@news.astraweb.com...
On Fri, 14 Aug 2009 18:25:45 -0700, Dr. Phillip M. Feldman wrote:
It seems as though Python is actually expanding range(2,n) into a list
of numbers, even though this is incredibly wasteful of
"Steven D'Aprano" wrote in message
news:02969972$0$20647$c3e8...@news.astraweb.com...
On Fri, 14 Aug 2009 18:25:45 -0700, Dr. Phillip M. Feldman wrote:
It seems as though Python is actually expanding range(2,n) into a list
of numbers, even though this is incredibly wasteful of memory. There
On Sun, Aug 16, 2009 at 2:30 AM, Emmanuel Surleau
wrote:
>
> I don't see what's particularly un-Pythonic with this code. Not using xrange()
> is a mistake, certainly, but it remains clear, easily understandable code
> which correctly demonstrates the naive algorithm for detecting whether n is a
>
> It's a particular unfair criticism because the critic (Ethan Furman)
> appears to have made a knee-jerk reaction. The "some language in Python"
> behaviour he's reacting to is the common idiom:
>
> for i in range(len(seq)):
> do_something_with(seq[i])
>
>
> instead of the "Python in Python" i
On Sun, 16 Aug 2009 08:30:54 +0200, Emmanuel Surleau wrote:
[...]
>> I will also observe that if you were to stop programming whatever
>> language you are more familiar with in Python, and start programming
>> Python in Python, you'll have an easier time of it.
>
> I don't see what's particularly
> Dr. Phillip M. Feldman wrote:
[snip]
> > def is_prime(n):
> >for j in range(2,n):
> > if (n % j) == 0: return False
> >return True
> >
> > It seems as though Python is actually expanding range(2,n) into a list of
> > numbers, even though this is incredibly wasteful of memory. Ther
John Nagle wrote:
Hendrik van Rooyen wrote:
On Saturday 15 August 2009 03:25:45 Dr. Phillip M. Feldman wrote:
And while you are about it, you may as well teach them that it is much
better to do a multiplication than a division.
Actually, division speed hasn't been much of an issue in yea
Hendrik van Rooyen wrote:
On Saturday 15 August 2009 03:25:45 Dr. Phillip M. Feldman wrote:
And while you are about it, you may as well teach them that it is much better
to do a multiplication than a division.
Actually, division speed hasn't been much of an issue in years. Arithmetic
has
On Fri, 14 Aug 2009 18:25:45 -0700, Dr. Phillip M. Feldman wrote:
> It seems as though Python is actually expanding range(2,n) into a list
> of numbers, even though this is incredibly wasteful of memory. There
> should be a looping mechanism that generates the index variable values
> incrementally
On Aug 15, 11:38 am, Mark Lawrence wrote:
> Dr. Phillip M. Feldman wrote:> I wrote the following correct but inefficient
> test of primality for purposes
> > of demonstrating that the simplest algorithm is often not the most
> > efficient. But, when I try to run the following code with a value o
On Saturday 15 August 2009 03:25:45 Dr. Phillip M. Feldman wrote:
> It seems as though Python is actually expanding range(2,n) into a list of
> numbers, even though this is incredibly wasteful of memory. There should be
> a looping mechanism that generates the index variable values incrementally
>
look at xrange -- http://docs.python.org/library/functions.html#xrange
--
http://mail.python.org/mailman/listinfo/python-list
On Aug 14, 8:25 pm, "Dr. Phillip M. Feldman"
wrote:
> I wrote the following correct but inefficient test of primality for purposes
> of demonstrating that the simplest algorithm is often not the most
> efficient. But, when I try to run the following code with a value of n that
> is large enough t
Dr. Phillip M. Feldman wrote:
I wrote the following correct but inefficient test of primality for purposes
of demonstrating that the simplest algorithm is often not the most
efficient. But, when I try to run the following code with a value of n that
is large enough to produce a significant amoun
Dr. Phillip M. Feldman wrote:
I wrote the following correct but inefficient test of primality for purposes
of demonstrating that the simplest algorithm is often not the most
efficient. But, when I try to run the following code with a value of n that
is large enough to produce a significant amoun
>
> It seems as though Python is actually expanding range(2,n) into a list of
> numbers, even though this is incredibly wasteful of memory. There should be
> a looping mechanism that generates the index variable values incrementally
> as they are needed.
This has nothing to do with Python's for l
I wrote the following correct but inefficient test of primality for purposes
of demonstrating that the simplest algorithm is often not the most
efficient. But, when I try to run the following code with a value of n that
is large enough to produce a significant amount of running time, I get an
out
In article ,
Lou Pecora wrote:
>In article
><5c92e9bd-1fb4-4c01-a928-04d7f6733...@e21g2000yqb.googlegroups.com>,
> Aaron Brady wrote:
>>
>> Did I tell you guys that 'natural' has 38 definitions at
>> dictionary.com?
>
>Amazing. I suggest you pick the one that fits best.
"The wonderful thing
On Apr 3, 10:43 am, alex23 wrote:
> On Apr 3, 10:36 pm, Lou Pecora wrote:
>
> > Aaron Brady wrote:
> > > Did I tell you guys that 'natural' has 38 definitions at
> > > dictionary.com?
>
> > Amazing. I suggest you pick the one that fits best.
>
> You mean the one that feels most natural?
No, n
On Apr 3, 10:36 pm, Lou Pecora wrote:
> Aaron Brady wrote:
> > Did I tell you guys that 'natural' has 38 definitions at
> > dictionary.com?
>
> Amazing. I suggest you pick the one that fits best.
You mean the one that feels most natural?
--
http://mail.python.org/mailman/listinfo/python-list
Lie wrote:
[snip]
Alternatively:
"One friend of mine half-seriously advanced the following thesis: We
should count from zero. But "first" is, etymologically, a diminution
of "foremost", and (as TomStambaugh says) should mean "0th" when we
count from 0. And "second" is from the Latin "secundus", m
In article
<5c92e9bd-1fb4-4c01-a928-04d7f6733...@e21g2000yqb.googlegroups.com>,
Aaron Brady wrote:
> On Apr 2, 6:34 pm, Tim Wintle wrote:
> > On Thu, 2009-04-02 at 15:16 -0700, Emile van Sebille wrote:
> > > Lou Pecora wrote:
> > > > Confusion only comes when you try to force the
> > > > defin
On Apr 2, 5:29 pm, Steven D'Aprano
wrote:
> On Wed, 01 Apr 2009 21:58:47 -0700, Lie wrote:
> > On Apr 1, 7:06 pm, Steven D'Aprano
> > wrote:
>
> >> There is a major clash between the names of ordinals in human languages
> >> and zero-based counting. In human languages, the Nth-ordinal item comes
On Apr 2, 6:34 pm, Tim Wintle wrote:
> On Thu, 2009-04-02 at 15:16 -0700, Emile van Sebille wrote:
> > Lou Pecora wrote:
> > > Confusion only comes when you try to force the
> > > defintion of one of them on the other and then say it's illogical or not
> > > natural. Both are natural.
>
> > Consi
On Thu, 2009-04-02 at 15:16 -0700, Emile van Sebille wrote:
> Lou Pecora wrote:
> > Confusion only comes when you try to force the
> > defintion of one of them on the other and then say it's illogical or not
> > natural. Both are natural.
>
> Consider the French 'Premiere etage' vs the American
Lou Pecora wrote:
Confusion only comes when you try to force the
defintion of one of them on the other and then say it's illogical or not
natural. Both are natural.
Consider the French 'Premiere etage' vs the American 'First Floor'
Emile
--
http://mail.python.org/mailman/listinfo/python-l
In article
,
Carl Banks wrote:
>
> I think people were being facetious. To me the first item in the list
> is x[0]--ordinal does not match cardinal. However, I don't use
> ordinals much when talking about list items; I'll say item 2, not
> third item.
Well, it's been said in many forms in
On Thu, 2009-04-02 at 06:28 +, Steven D'Aprano wrote:
> In set theory, you start by defining the integers like this:
>
> 0 = len( {} )
> 1 = len( {{}} )
> 2 = len( {{}, {{}}} )
> 3 = len( {{}, {{}}, {{}, {{}}} )
> etc.
not quite len() - surely you mean something like "any object along with
an
In article ,
Steven D'Aprano wrote:
> So an ordinality of zero just means the number
> of elements of something that doesn't exist.
You do realize that will give most people headaches. :-)
--
-- Lou Pecora
--
http://mail.python.org/mailman/listinfo/python-list
En Wed, 01 Apr 2009 08:04:12 -0300, andrew cooke
escribió:
something i don't think has been mentioned much - if you're using
"range()" in your python code then you're almost always doing it wrong.
i just grepped lepl and i use range 20 times in 9600 lines of code. out
of those, all but 3 ar
Steven D'Aprano wrote:
> In set theory, you start by defining the integers like this:
>
> 0 is the cardinality (size) of the empty set, the set with nothing in it.
>
> 1 is the cardinality of the set of empty sets, that is, the set
> containing nothing but the empty set.
>
> 2 is the cardinality o
On Thu, 2 Apr 2009, Steven D'Aprano wrote:
> On Thu, 02 Apr 2009 04:23:32 +, John O'Hagan wrote:
> > Beyond being part of a conventionally-ordered set of keys, what can an
> > ordinality of zero actually mean? (That's a sincere question.)
>
[snip erudite definition of cardinality]
> For non-i
On Apr 1, 11:28 pm, Hrvoje Niksic wrote:
> Carl Banks writes:
> > This is unforgiveable, not only changing the indexing semantics of
> > Python (because a user would have NO CLUE that something underlying
> > has been changed, and thus it should never be done), but also for
> > the needless abuse
Carl Banks wrote:
> On Apr 1, 2:32 pm, Arnaud Delobelle wrote:
Check the date on the line above (and the PS in that post).
>
> If I were your boss and you ever pulled something like this, your ass
> would be so fired.
>
> This is unforgiveable, not only changing the indexing semantics of
> Pyth
Carl Banks writes:
> This is unforgiveable, not only changing the indexing semantics of
> Python (because a user would have NO CLUE that something underlying
> has been changed, and thus it should never be done), but also for
> the needless abuse of exec.
Then I guess you'd fire Guido, too -- fr
On Apr 2, 1:29 am, Steven D'Aprano
wrote:
> On Wed, 01 Apr 2009 21:58:47 -0700, Lie wrote:
> > On Apr 1, 7:06 pm, Steven D'Aprano
> > wrote:
>
> >> There is a major clash between the names of ordinals in human languages
> >> and zero-based counting. In human languages, the Nth-ordinal item comes
On Apr 1, 9:23 pm, John O'Hagan wrote:
> Despite being thoroughly acclimatised to zero-based indexing and having no
> wish to change it, I'm starting to see the OP's point.
>
> Many of the arguments presented in this thread in favour of zero-based
> indexing have rather been arguments for half-ope
On Wed, 01 Apr 2009 21:58:47 -0700, Lie wrote:
> On Apr 1, 7:06 pm, Steven D'Aprano
> wrote:
>
>> There is a major clash between the names of ordinals in human languages
>> and zero-based counting. In human languages, the Nth-ordinal item comes
>> in position N. You can keep that useful conventi
On Thu, 02 Apr 2009 04:23:32 +, John O'Hagan wrote:
> Beyond being part of a conventionally-ordered set of keys, what can an
> ordinality of zero actually mean? (That's a sincere question.)
In set theory, you start by defining the integers like this:
0 is the cardinality (size) of the empty
On Apr 2, 4:05 pm, Aaron Brady wrote:
> On Apr 1, 11:58 pm, Lie wrote:
>
> > On Apr 1, 7:06 pm, Steven D'Aprano
>
> > wrote:
> > > There is a major clash between the names of ordinals in human languages
> > > and zero-based counting. In human languages, the Nth-ordinal item comes
> > > in positi
On Apr 1, 11:58 pm, Lie wrote:
> On Apr 1, 7:06 pm, Steven D'Aprano
>
> wrote:
> > There is a major clash between the names of ordinals in human languages
> > and zero-based counting. In human languages, the Nth-ordinal item comes
> > in position N. You can keep that useful convention with zero-b
On Apr 1, 7:06 pm, Steven D'Aprano
wrote:
> There is a major clash between the names of ordinals in human languages
> and zero-based counting. In human languages, the Nth-ordinal item comes
> in position N. You can keep that useful convention with zero-based
> counting by inventing the ugly word
On Wed, 1 Apr 2009, Steven D'Aprano wrote:
> On Wed, 01 Apr 2009 04:39:26 +0100, Rhodri James wrote:
> > Dragging this back to the original topic, you clearly find starting list
> > indices from zero unintuitive. To me, with a mathematical background,
> > it's not just intuitive, it's correct. Al
On Wed, 01 Apr 2009 15:12:27 +0100, Lada Kugis
wrote:
On 01 Apr 2009 08:06:28 GMT, Steven D'Aprano
wrote:
There are advantages and disadvantages to both systems, but on balance,
I
think that zero-based is a better system for programming, and one-based
for natural language.
Nicely put
Lada Kugis wrote:
> On 01 Apr 2009 01:26:41 GMT, Steven D'Aprano
> wrote:
>
>
>> Why Python (and other languages) count from zero instead of one, and
>> why half-open intervals are better than closed intervals:
>>
>> http://www.johndcook.com/blog/2008/06/26/why-computer-scientists-count-from-z
On Apr 1, 2:32 pm, Arnaud Delobelle wrote:
> Lada Kugis writes:
> > I'm coming from fortran and c background so I'm certainly biased by
> > them. But if you could explain one thing to me:
>
> > in fortran for example:
> > for i=1,n
> > goes from 1,2,3,4,...,n
>
> > in python for example:
> > for
Lada Kugis writes:
> I'm coming from fortran and c background so I'm certainly biased by
> them. But if you could explain one thing to me:
>
> in fortran for example:
> for i=1,n
> goes from 1,2,3,4,...,n
>
> in python for example:
> for i in range(1,n)
> goes from 1,2,3,4,...,n-1
> (that is, it
In article <91t6t4hfjicgvdrcgkhdjfro3ko3ktu...@4ax.com>,
Lada Kugis wrote:
> On Wed, 1 Apr 2009 00:40:17 -0700 (PDT), Carl Banks
> wrote:
>
> >
> >Lada,
> >
> >I am also an engineer, and I can tell your idea of intuitive is not
> >universal, even among engineers. I certainly do not lean towar
On Apr 1, 9:08 am, Lada Kugis wrote:
> On Wed, 1 Apr 2009 00:40:17 -0700 (PDT), Carl Banks
>
>
>
>
>
> wrote:
>
> >Lada,
>
> >I am also an engineer, and I can tell your idea of intuitive is not
> >universal, even among engineers. I certainly do not lean toward one-
> >based indexing.
>
> >From a
andrew cooke wrote:
MRAB wrote:
Steven D'Aprano wrote:
On Wed, 01 Apr 2009 04:58:48 +0200, Lada Kugis wrote:
Why do we try to create languages that are intuitive to humans, then ?
Because of the foolish hope that sufficiently easy syntax will make
excellent programmers out of average people.
On Apr 1, 7:08 am, Lada Kugis wrote:
> On Wed, 1 Apr 2009 00:40:17 -0700 (PDT), Carl Banks
>
>
>
>
>
> wrote:
>
> >Lada,
>
> >I am also an engineer, and I can tell your idea of intuitive is not
> >universal, even among engineers. I certainly do not lean toward one-
> >based indexing.
>
> >From a
MRAB wrote:
> Steven D'Aprano wrote:
>> On Wed, 01 Apr 2009 04:58:48 +0200, Lada Kugis wrote:
>>
>>> Why do we try to create languages that are intuitive to humans, then ?
>>
>> Because of the foolish hope that sufficiently easy syntax will make
>> excellent programmers out of average people.
>>
>>
Steven D'Aprano wrote:
On Wed, 01 Apr 2009 04:58:48 +0200, Lada Kugis wrote:
Why do we try to create languages that are intuitive to humans, then ?
Because of the foolish hope that sufficiently easy syntax will make
excellent programmers out of average people.
Programming is not intuitive
Lada Kugis wrote:
[snip]
Yes, that's it. I won't argue over it, since I can't change it, but 1
is still more natural to me (it is "the real world" way). The above
pros seem to me to be very little compared to the cons of the ... and
the (m-n) point Chris was trying to explain doesn't seem that re
On 01 Apr 2009 08:06:28 GMT, Steven D'Aprano
wrote:
>
>There are advantages and disadvantages to both systems, but on balance, I
>think that zero-based is a better system for programming, and one-based
>for natural language.
Nicely put.
Yes, along with some of your other arguments, I think I
On Wed, 1 Apr 2009 00:40:17 -0700 (PDT), Carl Banks
wrote:
>
>Lada,
>
>I am also an engineer, and I can tell your idea of intuitive is not
>universal, even among engineers. I certainly do not lean toward one-
>based indexing.
>
>From a programming standpoint--and remember Python is a programming
In article <72i5t4tgfo2h4gd6ggcs02flkca85kg...@4ax.com>,
Lada Kugis wrote:
> and
> the (m-n) point Chris was trying to explain doesn't seem that relevant
> to me.
That's because you haven't done enough programming really using the
Python structures and objects. You can really do a lot with
In article <1ej5t4930m29h0f6ttpdcd83t08q2q3...@4ax.com>,
Lada Kugis wrote:
> On 01 Apr 2009 01:26:41 GMT, Steven D'Aprano
> wrote:
>
> >
> >Why Python (and other languages) count from zero instead of one, and
> >why half-open intervals are better than closed intervals:
> >
> >http://www.johnd
2009/4/1 Carl Banks :
> I am also an engineer, and I can tell your idea of intuitive is not
> universal, even among engineers. I certainly do not lean toward one-
> based indexing.
Another engineer here who finds 0-based indexing more intuitive than
1-based indexing.
--
Tim Rowe
--
http://mail
On Wed, 01 Apr 2009 04:39:39 -0700, bearophileHUGS wrote:
> Lada Kugis:
>> (you have 1 apple, you start counting from 1 ...<
>
> To little children I now show how to count starting from zero: apple
> number zero, apple number one, etc, and they find it natural enough :-)
Ah, but that's not the
Lada Kugis:
> (you have 1 apple, you start counting from 1 ...<
To little children I now show how to count starting from zero: apple
number zero, apple number one, etc, and they find it natural
enough :-)
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Natural language is full of ambiguity, which is why my parents used to
argue about the meaning of "next Wednesday," or of "the next exit."
Until you have a starting reference, and until you decide whether it's a
closed or open interval, you can't be sure everyone will get the same
semantics.
andrew cooke wrote:
[...]
> so in a small/moderate size library of 600 lines (including blanks and
6000
> comments, but excluding tests and exploratory code) the only time i have
> used range with array indices i was either unhappy with the code, or
> implem
something i don't think has been mentioned much - if you're using
"range()" in your python code then you're almost always doing it wrong.
i just grepped lepl and i use range 20 times in 9600 lines of code. out
of those, all but 3 are in "quick and dirty" tests or experimental code,
not in the ma
On Wed, 01 Apr 2009 04:39:26 +0100, Rhodri James wrote:
> Dragging this back to the original topic, you clearly find starting list
> indices from zero unintuitive. To me, with a mathematical background,
> it's not just intuitive, it's correct. All sorts of useful properties
> fall out from that,
Lada Kugis schrieb:
On 01 Apr 2009 01:26:41 GMT, Steven D'Aprano
wrote:
Why Python (and other languages) count from zero instead of one, and
why half-open intervals are better than closed intervals:
http://www.johndcook.com/blog/2008/06/26/why-computer-scientists-count-from-zero/
http://www.
On Mar 31, 7:23 pm, Lada Kugis wrote:
> On 01 Apr 2009 01:26:41 GMT, Steven D'Aprano
>
> wrote:
>
> >Why Python (and other languages) count from zero instead of one, and
> >why half-open intervals are better than closed intervals:
>
> >http://www.johndcook.com/blog/2008/06/26/why-computer-scienti
Chris Rebert writes:
> Among other things, it has the nice property that:
> len(some_list[n:m]) == m-n
And also that it is intuitive how to represent an empty slice
(foo[n:n]). When traversing over sublists, it's also a useful
property that foo[a:b] + foo[b:c] == foo.
--
http://mail.python.org/
On Wed, 01 Apr 2009 04:58:48 +0200, Lada Kugis wrote:
> Why do we try to create languages that are intuitive to humans, then ?
Because of the foolish hope that sufficiently easy syntax will make
excellent programmers out of average people.
Programming is not intuitive to humans. *Counting* isn'
On Wed, 01 Apr 2009 03:58:48 +0100, Lada Kugis
wrote:
I thoughts high level languages were created primarily so we don't
have to think about what happens inside a programming language, memory
offsets and the like.
Different programming languages were created for different purposes.
FORTRAN
On Wed, 01 Apr 2009 04:15:00 +0100, Lada Kugis
wrote:
On Wed, 01 Apr 2009 03:59:36 +0100, "Rhodri James"
wrote:
Two opportunities to forget to lie about how big your array is
It is rank 3, meaning a33 is the last element. I don't see how any
alternative can be simpler than that.
You
On Wed, 01 Apr 2009 03:59:36 +0100, "Rhodri James"
wrote:
>
>Two opportunities to forget to lie about how big your array is :-)
It is rank 3, meaning a33 is the last element. I don't see how any
alternative can be simpler than that.
>
>> I wrote in my other post, 0 is weird to me, I have model o
Since when should a machine (that's what a computer is after all), be
forced to contort itself into something that is capable of reflecting
the laws of physical matter?
Better perhaps to look at it from another angle - it's
counter-intuitive to think that the digital should mirror the
analogue. Th
On Tue, 31 Mar 2009 19:30:15 -0700 (PDT), woo...@gmail.com wrote:
>Counting from zero through n-1 is used because it is the memory offset
>and not any kind of counter. Simplified, if you are iterating through
>a list, using a for loop or anything else, the first element/number is
>at memory offse
1 - 100 of 117 matches
Mail list logo
