Alan Morgan wrote:
> >How would xrange(100).remove(1) work?
>
> One way is by first converting the xrange to a list. If we think of
> the xrange as an efficient and space lean way to store certain types
> of lists then it isn't unreasonable to return a regular list when
> the conditions no longer
In article <[EMAIL PROTECTED]>,
Georg Brandl <[EMAIL PROTECTED]> wrote:
>Alan Morgan wrote:
>
>>>range is giving you a real list, while xrange is giving you an xrange object.
>>>Have you tried to slice an xrange object? Or using .append on it?
>>
>> No, I hadn't. I presume these could all be def
Carl Banks wrote:
> > I wondered if the Python compiler could, as a special case, turn:
> >
> > for i in range(n)
> >
> > into compiled code equivalent to
> >
> > for i in itr
> >
> > where "itr" is a lightweight iterator that returns the same values as
> > iter(range(n)).
>
> Nope, out of the que
On Wed, 05 Apr 2006 22:08:29 -0700, Carl Banks wrote:
>> for i in range(n)
>>
>> into compiled code equivalent to
>>
>> for i in itr
>>
>> where "itr" is a lightweight iterator that returns the same values as
>> iter(range(n)).
> Nope, out of the question for Python 2.x. Note that the the builtin
I wondered at the tone of some of the replies, re-read the repliess and
your original message. On first readings ithought that your original
message was OK and that the replies were a bit 'strong' . On second
reading I thought that the original could be interpreted a little less
nicely, but I had t
Alan Morgan wrote:
>>range is giving you a real list, while xrange is giving you an xrange object.
>>Have you tried to slice an xrange object? Or using .append on it?
>
> No, I hadn't. I presume these could all be defined.
How would xrange(100).remove(1) work?
Georg
--
http://mail.python.org/
Steve R. Hastings wrote:
> > the difference isn't very
> > large, xrange is actually slower in some python versions, and you'll
> > need the integer objects sooner or later anyway...
>
> Actually, for many uses of "for i in (range|xrange)", you only need the
> value of i, and you aren't doing anyt
Steve R. Hastings wrote:
> I wondered if the Python
> compiler could, as a special case, turn:
>
> for i in range(n)
>
> into compiled code equivalent to
>
> for i in itr
>
> where "itr" is a lightweight iterator that returns the same values as
> iter(range(n)).
Nope, out of the question for Pytho
Steve R. Hastings wrote:
> On Thu, 06 Apr 2006 02:33:16 +0200, Azolex wrote:
>> Don't. It's quite funny, thanks.
>
> I guess I should laugh. :-/
>
>
> When you read my original articles, did *you* think I was proposing that
> range() be changed to always return an iterator? I thought what I wr
Em Qua, 2006-04-05 às 19:15 -0700, Alex Martelli escreveu:
> Steve R. Hastings <[EMAIL PROTECTED]> wrote:
>...
> > Actually, for many uses of "for i in (range|xrange)", you only need the
> > value of i, and you aren't doing anything with the integer object. You
>
> Then, the speediest approac
Steve R. Hastings <[EMAIL PROTECTED]> wrote:
...
> Actually, for many uses of "for i in (range|xrange)", you only need the
> value of i, and you aren't doing anything with the integer object. You
Then, the speediest approach may be completely different:
import itertools
for i in itertools.re
Em Qua, 2006-04-05 às 22:24 +0200, Fredrik Lundh escreveu:
> the difference isn't very
> large, xrange is actually slower in some python versions, and you'll
> need the integer objects sooner or later anyway...
Some code is worth a thousand words:
$ python2.3
Python 2.3.5 (#2, Mar 6 2006, 10:1
Steve R. Hastings wrote:
> On Thu, 06 Apr 2006 09:08:45 +1000, Steven D'Aprano wrote:
>> Yes, the above example is a good use case for xrange. Did you think that
>> anyone denied that there were good cases for it?
>
> I am now officially sorry for starting this thread.
Don't. It's quite funny, th
On Thu, 06 Apr 2006 02:33:16 +0200, Azolex wrote:
> Don't. It's quite funny, thanks.
I guess I should laugh. :-/
When you read my original articles, did *you* think I was proposing that
range() be changed to always return an iterator? I thought what I wrote
was pretty clear...
--
Steve R. Has
In article <[EMAIL PROTECTED]>,
Erik Max Francis <[EMAIL PROTECTED]> wrote:
>Alan Morgan wrote:
>
>> In article <[EMAIL PROTECTED]>,
>> Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> >
>>>Because you assume that the only use-case of range() is within a for-loop.
>>>range() is a builtin function that c
On Thu, 06 Apr 2006 09:08:45 +1000, Steven D'Aprano wrote:
> Yes, the above example is a good use case for xrange. Did you think that
> anyone denied that there were good cases for it?
I am now officially sorry for starting this thread.
Please let me just summarize what I wanted to say:
* Ques
In article <[EMAIL PROTECTED]>,
Georg Brandl <[EMAIL PROTECTED]> wrote:
>Alan Morgan wrote:
>> In article <[EMAIL PROTECTED]>,
>> Giovanni Bajo <[EMAIL PROTECTED]> wrote:
>>>Steve R. Hastings wrote:
>>>
> in Python 2.X, range is defined to return a list. if you start
> returning something
On Wed, 05 Apr 2006 15:02:33 -0700, Steve R. Hastings wrote:
> On Wed, 05 Apr 2006 22:24:24 +0200, Fredrik Lundh wrote:
>>> If Python actually allocates the list, then clearly we should all use
>>> "for i in xrange".
>>
>> clearly we should all? speak for yourself.
>
> I apologize for my pithy
Alan Morgan wrote:
> In article <[EMAIL PROTECTED]>,
> Giovanni Bajo <[EMAIL PROTECTED]> wrote:
>>Steve R. Hastings wrote:
>>
in Python 2.X, range is defined to return a list. if you start
returning something else, you'll break stuff.
>>>
>>> Perhaps I'm mistaken here, but I don't see ho
Alan Morgan wrote:
> In article <[EMAIL PROTECTED]>,
> Giovanni Bajo <[EMAIL PROTECTED]> wrote:
>
>>Because you assume that the only use-case of range() is within a for-loop.
>>range() is a builtin function that can be used in any Python expression. For
>>instance:
>>
>>RED, GREEN, BLUE, WHITE, B
On Wed, 05 Apr 2006 22:09:29 +, Giovanni Bajo wrote:
> [...] you assume that the only use-case of range() is within a for-loop.
No, I do not assume any such thing. I have not suggested that range()
should be changed to always return an iterator. I wondered if the Python
compiler could, as a
In article <[EMAIL PROTECTED]>,
Giovanni Bajo <[EMAIL PROTECTED]> wrote:
>Steve R. Hastings wrote:
>
>>> in Python 2.X, range is defined to return a list. if you start
>>> returning something else, you'll break stuff.
>>
>> Perhaps I'm mistaken here, but I don't see how this optimization could
>>
Steve R. Hastings wrote:
>> in Python 2.X, range is defined to return a list. if you start
>> returning something else, you'll break stuff.
>
> Perhaps I'm mistaken here, but I don't see how this optimization could
> possibly break anything.
Because you assume that the only use-case of range() i
On Wed, 05 Apr 2006 22:24:24 +0200, Fredrik Lundh wrote:
>> If Python actually allocates the list, then clearly we should all use
>> "for i in xrange".
>
> clearly we should all? speak for yourself.
I apologize for my pithy turn of phrase. Clearly what I should have
written was:
"If Python act
Todd wrote:
> Steve R. Hastings wrote:
> > When you compile the expression
> >
> > for i in range(1000):
> > pass
> >
> > does Python make an iterator for range(), and then generate the values
> > on the fly? Or does Python actually allocate the list [0, 1, 2, ..., 999]
> > and then s
Steve R. Hastings wrote:
> When you compile the expression
>
> for i in range(1000):
> pass
>
> does Python make an iterator for range(), and then generate the values
> on the fly? Or does Python actually allocate the list [0, 1, 2, ..., 999]
> and then step through it?
I ran an expe
Steve R. Hastings wrote:
> If Python actually allocates the list, then clearly we should all use
> "for i in xrange".
clearly we should all? speak for yourself. the difference isn't very
large, xrange is actually slower in some python versions, and you'll
need the integer objects sooner or late
Steve R. Hastings wrote:
> When you compile the expression
>
> for i in range(1000):
> pass
>
> does Python make an iterator for range(), and then generate the values
> on the fly? Or does Python actually allocate the list [0, 1, 2, ..., 999]
> and then step through it?
It does.
Steve R. Hastings wrote:
> If Python doesn't currently optimize this case, is there any chance this
> optimization could be added?
I was just asking about this, and apparently it will be changed in 3.0:
Built-in Namespace
* Make built-ins return an iterator where appropriate (e.g.
range(),
When you compile the expression
for i in range(1000):
pass
does Python make an iterator for range(), and then generate the values
on the fly? Or does Python actually allocate the list [0, 1, 2, ..., 999]
and then step through it?
I was under the impression that recent releases of
30 matches
Mail list logo
