text_combined: guido van rossum hoaufpythonorg propose remove support indexing carryover python 22 next method good reasons range return iterable iterator eg r rangen r j r propose keep status quo lets also fix __len__ returns sysmaxintmaxsize result doesnt fit py_ssize_t worried debates reprhasheq similarly stuck vicious circles ill think untie knots theyre unrelated sequenceiteratoriterable debate guido tue apr 29 2008 716 pm alexander belopolsky wrote tue apr 29 2008 748 pm guido van rossum wrote lets stop discussion kill proposals add indexingslicing etc sorry alexander isnt anyone besides favor nobody brought convincing use case thats fair let wrap rehashing current state affairs 1 2x xrange 3x range support indexing comment py3k branch says rangex necessary seq range apparently wrong x x iter123 x 1 2 3 2 3x ranges longer syssizemax allowed indexed even small indexes example range21000 raises overflowerror little justification behavior 3line patch fix situation small indexes amaury demonstrated 1 effort arbitrary indexes supported 1 httpbugspythonorgfile10109anyrangepatch 3 ongoing debate 2 comparison hashing implemented range objects point current implementation 3x neither simple even documentation says printrange__doc__ rangestart stop step range object returns iterator generates numbers range demand range10__next__ traceback recent call last file line 1 attributeerror range object attribute __next__ supports sequence methods len subscripting others __contains__ slicing use case making range sequence follows frequently deal data organized column oriented tables tables often need column represents row number range object would allow efficient representation column virtual column table would mean generic sequence manipulation functions work columns strong itch though virtualizing row number column using range attractive solution practice memory savings compared numpys arange arrayi range significant however slicing support axed based complexity considerations dont see supporting indexing justified moreover since indexing slicing reuse start istep computation incremental code complexity slicing support small two go hand hand reasons believe either following alternatives better status quo 1 make range return sequence 2 make range return iterator prefer 1 several advantages proposal common listrange range cases creation intermediate object go away stop debating hashrange return 2 finally need change docstring 2 httpbugspythonorgissue2603 __len__ always problematic values counted signed c long maybe java collections package java chooses practicality purity simply states length doesnt fit largest number fit returned ie us would sysmaxsize 30 sysmaxint 2x another simple way fix range21000 buglett guido van rossum home page httpwwwpythonorgguido _______________________________________________ python3000 mailing list smsbmo9552pythonorg httpmailpythonorgmailmanlistinfopython3000 unsubscribe httpmailpythonorgmailmanoptionspython3000python300040tangomucom thu 07 aug 2008 213206 0700 python3000 range issues