On Wed, Jul 12, 2000 at 01:10:56PM -0500, Paul Prescod wrote: > Thomas Wouters wrote: > > For that reason I think it's better to live with xrange() ;) > If we had first class range syntax then it would be relatively easy to > recognize the pattern > > for i in [x:y:z]: > .... > > Then we could generate a special FOR_INTS bytecode. I've heard that "C" > has a pretty efficient implementation of that construct. <wink> Yes. This was one of the reasons Guido was interested in this. (We talked about this in private email before I implemented it ;) > Plus, if your loops are so large that they need xrange, you would > probably get an interesting speedup from using a real C for-loop instead > of an object! I mean for small values xrange is slower than range and > when you think about what range is doing under the covers. <shudder> Well, with the new 'sq_contains' PySequenceMethods member, the operation: number in xrange(19,23578294,3)*393 # for instance ;) also gets very efficient. A *lot* more efficient than using the equivalent [ra::ge] syntax in any case. That would be one reason to add at least a 'BUILD_XRANGE' bytecode, so when the compiler is made sufficiently intelligent, it could issue 'BUILD_XRANGE' opcodes instead of BUILD_RANGE opcodes for if x in [:y:z]: and other instances where the resulting list isn't stored anywhere, so will never be modified. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4