[issue2735] range: lean and mean

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Yeah, let's just reject this. There doesn't appear to be much demand. -- resolution: -> rejected status: open -> closed ___ Python tracker <[EMAIL PROTECTED]>

[issue2735] range: lean and mean

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Guido, is it safe to safe this isn't going to happen? ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue2735] range: lean and mean

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Address more concerns with attached patch. Added file: http://bugs.python.org/file10183/range_lean_and_mean5.patch __ Tracker <[EMAIL PROTECTED]> _

[issue2735] range: lean and mean

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: I brought __len__ back, and tried to fix the tests failing because they were indexing range. I couldn't figure out how to fix test_itertools. (It's on codereview, too). Added file: http://bugs.python.org/file10176/range_lean_and_mean4.patc

[issue2735] range: lean and mean

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Fair enough. Let's keep __len__. Did you upload the patch to the codde review site yet? Hopefully I have time to look at it tonight. __ Tracker <[EMAIL PROTECTED]> __

[issue2735] range: lean and mean

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: On Fri, May 2, 2008 at 5:46 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Guido van Rossum <[EMAIL PROTECTED]> added the comment: > > We need to look at more details why those fail. Perhaps there's one > common place where this is

[issue2735] range: lean and mean

Guido van Rossum <[EMAIL PROTECTED]> added the comment: We need to look at more details why those fail. Perhaps there's one common place where this is used? Did you add __length_hint__ yet? __ Tracker <[EMAIL PROTECTED]> __

[issue2735] range: lean and mean

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: 16 tests failed: test_ctypes test_datetime test_deque test_enumerate test_heapq test_itertools test_list test_mutants test_operator test_pickle test_pickletools test_random test_richcmp test_set test_trace test_userlist ___

[issue2735] range: lean and mean

Terry J. Reedy <[EMAIL PROTECTED]> added the comment: Does this/will this supercede http://bugs.python.org/issue2690 ? -- nosy: +tjreedy __ Tracker <[EMAIL PROTECTED]> __ _

[issue2735] range: lean and mean

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Show me which tests break and I'll decide. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list

[issue2735] range: lean and mean

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Are you sure you want to remove len of range? It breaks quite a few tests. __ Tracker <[EMAIL PROTECTED]> __ ___

[issue2735] range: lean and mean

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Attaching a new patch from reviews. __len__ has been removed. I'll post it to Guido's Codereview tool when it's active (I'm getting 500 server errors when I try to upload.) Added file: http://bugs.python.org/file10172/range_lean_and_mean3.

[issue2735] range: lean and mean

Guido van Rossum <[EMAIL PROTECTED]> added the comment: See also comments published on the code review site: http://codereview.appspot.com/602 __ Tracker <[EMAIL PROTECTED]> __ ___

[issue2735] range: lean and mean

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: One more nit: you don't need to zero out trailing range_as_sequence members explicitly. static PySequenceMethods range_as_sequence = { (lenfunc)range_length, /* sq_length */ }; should be enough. __

[issue2735] range: lean and mean

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: - With length precomputed in range_new, we can probably get rid of get_len_of_range. - There is no need to recompute length in range_iter. A nit: iterator object's size member is called "len", but the same member of the range object

[issue2735] range: lean and mean

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: On Thu, May 1, 2008 at 9:38 PM, Alexander Belopolsky <[EMAIL PROTECTED]> wrote: > > Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: > > The start/step/stop getter functions should INCREF return values. Is > there a reason no

[issue2735] range: lean and mean

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: The start/step/stop getter functions should INCREF return values. Is there a reason not to adapt slice implementation: static PyMemberDef slice_members[] = { {"start", T_OBJECT, offsetof(PySliceObject, start), READONLY},

[issue2735] range: lean and mean

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: __len__ always has to return a Py_ssize_t because that's the data type that represents lengths in C. It's just the way it is. __ Tracker <[EMAIL PROTECTED]> ___

[issue2735] range: lean and mean

Facundo Batista <[EMAIL PROTECTED]> added the comment: Just for the record: Why __len__ tries to convert it to Py_size_t (possibly generating an Overflow), and not just returns the PyLong object? -- nosy: +facundobatista __ Tracker <[EMAIL PROTECTED]>

[issue2735] range: lean and mean

New submission from Benjamin Peterson <[EMAIL PROTECTED]>: Per discussions on Python-3000, I've stipped range down to a bare minimum. Here's an overview of the patch: 1. No slicing. 2. Length is computed in constructor and is a PyLong in the object's struct. __len__ simply tries to convert it to