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 "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 like
� �for i in range(n):
as a simple integer loop.
It would be a simple to do if you were writing it for a different
langauge was a lot less dynamic than Python is. It'd be quite a
complex hack to add it to CPython's compiler while maintaing the
current highly dynamic runtime semantics and backwards compatibility,
which is a design constraint of Python whether you like it or not.
In your other message, you said this wasn't a legitimate CPython
complaint. Here, you say that it would be a "complex hack" to implement
this in CPython. "complex hack" has negative connotations in my mind.
This seems contradictory to me.
And all this complaining about an issue that can be worked around by
xrange instead of range. Sheesh.
Sure. The specific issue of range vs xrange is quite a small one. There
is a slightly larger one regarding the flexibility (or relative lack
thereof) of the CPython runtime, though.
A possible solution would be to make 'range' return an instance of, say,
'RangeList', a subclass of list which would behave like 'list'
externally but create the list of values internally only when needed.
--
http://mail.python.org/mailman/listinfo/python-list
