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
On 02:12 am, pavlovevide...@gmail.com wrote:
On Aug 16, 3:35�pm, sturlamolden sturlamol...@yahoo.no wrote:
On 16 Aug, 14:57, Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
Well, the alternative would be to have two keywords for
looping: one
for your simple incrementing integer
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 sturlamol...@yahoo.no
wrote:
A compiler could easily recognise a statement like
� for i in range(n):
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 really
On 16 Aug, 19:12, Carl Banks pavlovevide...@gmail.com 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
exar...@twistedmatrix.com wrote:
On 02:12 am, pavlovevide...@gmail.com wrote:
On Aug 16, 3:35�pm, sturlamolden sturlamol...@yahoo.no wrote:
On 16 Aug, 14:57, Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
� � � � Well, the alternative would be to have two keywords for
looping: one
for your
Carl Banks wrote:
On Aug 16, 3:35 pm, sturlamolden sturlamol...@yahoo.no wrote:
On 16 Aug, 14:57, Dennis Lee Bieber wlfr...@ix.netcom.com 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
On Sun, 16 Aug 2009 15:35:26 -0700, sturlamolden wrote:
On 16 Aug, 14:57, Dennis Lee Bieber wlfr...@ix.netcom.com 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
John Machin wrote:
On Aug 17, 8:35 am, sturlamolden sturlamol...@yahoo.no 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
On Sun, Aug 16, 2009 at 11:10 PM, Nobodynob...@nowhere.com 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
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 Aug 17, 4:40 am, exar...@twistedmatrix.com wrote:
On 02:12 am, pavlovevide...@gmail.com wrote:
On Aug 16, 3:35 pm, sturlamolden sturlamol...@yahoo.no wrote:
On 16 Aug, 14:57, Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
Well, the alternative would be to have two keywords for
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 sturlamol...@yahoo.no wrote:
On 16 Aug, 14:57, Dennis Lee Bieber wlfr...@ix.netcom.com 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 couple of years ago. Starting using
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 should
be
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
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 idiom:
for
On Sun, Aug 16, 2009 at 2:30 AM, Emmanuel Surleau
emmanuel.surl...@gmail.com 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
Steven D'Aprano st...@remove-this-cybersource.com.au 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
bartc wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au 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
On 16 Aug, 11:45, bartc ba...@freeuk.com 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
On 16 Aug, 14:57, Dennis Lee Bieber wlfr...@ix.netcom.com 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
On Sun, Aug 16, 2009 at 6:35 PM, sturlamolden sturlamol...@yahoo.no 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 sturlamol...@yahoo.no 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
On 01:23 am, benjamin.kap...@case.edu wrote:
On Sun, Aug 16, 2009 at 6:35 PM, sturlamolden sturlamol...@yahoo.no
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
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?
--
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 sturlamol...@yahoo.no
wrote:
A compiler could easily recognise a statement like
for i in range(n):
as a simple integer loop. In fact, Cython
On Aug 16, 3:35 pm, sturlamolden sturlamol...@yahoo.no wrote:
On 16 Aug, 14:57, Dennis Lee Bieber wlfr...@ix.netcom.com 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
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, for the
look at xrange -- http://docs.python.org/library/functions.html#xrange
--
http://mail.python.org/mailman/listinfo/python-list
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
as
On Aug 15, 11:38 am, Mark Lawrence breamore...@yahoo.co.uk 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
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 as
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
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
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
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 loop
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
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
On Aug 14, 8:25 pm, Dr. Phillip M. Feldman pfeld...@verizon.net
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
40 matches
Mail list logo