for循环中range（）和xrange（）的效率 [英] efficiency of range() and xrange() in for loops
问题描述
当您在范围（1000）中编译表达式
时：
通过
Python为range（）创建一个迭代器，然后动态生成值
？或者Python实际上是否分配了列表[0,1,2，...，999]
然后单步执行它？
我是在最近发布的Python优化了这个
案例的印象，但经过反思，我不知道我在哪里得到了这样的印象。
如果Python实际分配了这个列表，显然我们都应该使用
for x in xrange。但是对于我在范围内看起来更干净，并且可能比xrange更轻盈
。当然，如果你想编写在旧版本的Python上运行良好的代码，你需要使用xrange（）。
如果Python目前还没有优化这种情况，是否有可能增加这个
优化？
PS看起来所有很酷的人都会看到生成的字节码来回答像这样的问题。我也想变得很酷。我在哪里可以找到有关如何为我编译的Python获取字节码列表的信息？
-
Steve R.黑斯廷斯Vita est
st***@hastings.org http://www.blarg.net/~steveha
Steve R. Hastings写道：
如果Python目前还没有优化这种情况，那么这个优化是否有可能是添加？
我刚刚问过这个问题，显然它将在3.0中更改：
内置命名空间
*使内置函数在适当的时候返回迭代器（例如
range（），
zip（）等。）
要删除：
* xrange（）：使用range（）代替[1]
Steve R. Hastings写道：当你在范围（1000）中为i编译表达式时
：
Python是否为range（）创建一个迭代器，然后生成
即时的价值观？或者Python实际上是否分配了列表[0,1,2，...，999]
然后逐步执行它？
确实如此。
我的印象是最近发布的Python优化了这个案例，但经过反思，我不知道在哪里我得到了这样的印象。
如果Python实际上分配了列表，那么显然我们都应该使用
for i in xrange。但是对于我在范围内看起来更干净，并且可能比xrange更轻巧。当然，如果你想编写在旧版本的Python上运行良好的代码，你需要使用xrange（）。
如果Python目前还没有优化这种情况，那么有没有可能增加这种优化？
由于替代方案非常简单（添加单个字符），我认为这将是
不会进入2.x行。 SF上存在旧编译器的补丁，
但它不适用于新的AST编译器。
P.S.看起来所有很酷的人都会看到生成的字节码来回答像这样的问题。我也想变得很酷。我在哪里可以找到有关如何为我编译的Python获取字节码列表的信息？
dis模块。
Georg
Steve R. Hastings写道：
如果是Python实际上分配列表，然后显然我们都应该使用
for x in xrange。
显然我们应该全部？为自己说话。差别不是很大，在某些python版本中，xrange实际上比较慢，而且你迟早需要整个对象... b $ b ...
如果Python目前还没有优化这种情况，是否有可能添加这个
优化？
in Python 2.X，范围定义为返回列表。如果你开始返回
别的东西，你就会破坏东西。
< / F>
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 Python optimize this
case, but upon reflection, I have no idea where I got that impression.
If Python actually allocates the list, then clearly we should all use
"for i in xrange". But "for i in range" looks cleaner, and is potentially
more lightweight than xrange. Of course, if you want to write code that
runs well on older versions of Python, you need to use xrange().
If Python doesn''t currently optimize this case, is there any chance this
optimization could be added?
P.S. It looks like all the cool people look at the generated bytecodes to
answer questions like this one. I want to be cool too. Where can I find
information about how to get a bytecodes listing for my compiled Python?
--
Steve R. Hastings "Vita est"
st***@hastings.org http://www.blarg.net/~steveha
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(),
zip(), etc.)
To be removed:
* xrange(): use range() instead [1]
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.
I was under the impression that recent releases of Python optimize this
case, but upon reflection, I have no idea where I got that impression.
If Python actually allocates the list, then clearly we should all use
"for i in xrange". But "for i in range" looks cleaner, and is potentially
more lightweight than xrange. Of course, if you want to write code that
runs well on older versions of Python, you need to use xrange().
If Python doesn''t currently optimize this case, is there any chance this
optimization could be added?
As the alternative is so easy (adding a single character), I think this will
not make it into the 2.x line. A patch for the old compiler existed on SF,
but it will not work with the new AST compiler.
P.S. It looks like all the cool people look at the generated bytecodes to
answer questions like this one. I want to be cool too. Where can I find
information about how to get a bytecodes listing for my compiled Python?
The "dis" module.
Georg
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 later anyway...
If Python doesn''t currently optimize this case, is there any chance this
optimization could be added?
in Python 2.X, range is defined to return a list. if you start returning
something else, you''ll break stuff.
</F>
这篇关于for循环中range（）和xrange（）的效率的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
