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
42 matches
Mail list logo