[issue2610] string representation of range and dictionary views

Benjamin Peterson added the comment: Closing since this is now implemented. -- resolution: -> out of date status: open -> closed ___ Python tracker ___ _

[issue2610] string representation of range and dictionary views

Brad Miller added the comment: Just to restart the discussion on the original issue since I see that the latest 3.1 has solved the problem with dict_keys, dict_values, etc al objects. Many thanks! A suggestion was made by Alexander to create a custom displayhook that could be included in th

[issue2610] string representation of range and dictionary views

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: It's going to have to be deferred to 3.1. -- versions: +Python 3.1 -Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue2610] string representation of range and dictionary views

And Clover <[EMAIL PROTECTED]> added the comment: I would like to see something along the general lines of bmiller's patch for dict views in a 3.x release... there are probably other iterators that could do with chattier reprs also. (Range, on the other hand, is fine as it is.) It's not just at

[issue2610] string representation of range and dictionary views

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I do not understand why you think that having the interpreter display > > when x.keys() is called is not an improvement over > I didn't say that the change in dict_keys is not an improvement, but that the patch doesn't achieve its object

[issue2610] string representation of range and dictionary views

Brad Miller <[EMAIL PROTECTED]> added the comment: On Tue, Jun 17, 2008 at 12:23 AM, Martin v. Löwis <[EMAIL PROTECTED]> wrote: > > Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > > After reviewing this again, I'm skeptical that this is a good idea. It > doesn't achieve its original purp

[issue2610] string representation of range and dictionary views

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: I'm also -1 on the patch and think it is the wrong solution. Efforts should probably be directed at hooking the output of the interactive interpreter. We already have code that suppresses None return values and assigns results to "_".

[issue2610] string representation of range and dictionary views

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: After reviewing this again, I'm skeptical that this is a good idea. It doesn't achieve its original purpose (anymore), as it only changes tp_str for range objects (although it does change tp_repr for dict views - why this inconsistency?). So

[issue2610] string representation of range and dictionary views

Brad Miller <[EMAIL PROTECTED]> added the comment: On May 7, 2008, at 1:55 PM, Martin v. Löwis wrote: Thanks for the very clear answer. This being my first attempt at contributing to the Python core, I am looking for some sort of clarity on the future of this patch. It feels like some sort

[issue2610] string representation of range and dictionary views

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Is there any chance this patch will make it into the latest alpha?? I don't think there is any such chance. __ Tracker <[EMAIL PROTECTED]>

[issue2610] string representation of range and dictionary views

Brad Miller <[EMAIL PROTECTED]> added the comment: Is there any chance this patch will make it into the latest alpha?? Brad __ Tracker <[EMAIL PROTECTED]> __ __

[issue2610] string representation of range and dictionary views

Brad Miller <[EMAIL PROTECTED]> added the comment: On Apr 17, 2008, at 4:26 PM, Amaury Forgeot d'Arc wrote: > > Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: > > Some review of dv_range.patch: > > - repr(d.keys()) depends on the internal ordering of items, their hash > values, the

[issue2610] string representation of range and dictionary views

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Some review of dv_range.patch: - repr(d.keys()) depends on the internal ordering of items, their hash values, the insertion order... the test seems fragile. Or you may rely on the fact that ints are their own hash values, so a small dic

[issue2610] string representation of range and dictionary views

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- title: string representation of range -> string representation of range and dictionary views __ Tracker <[EMAIL PROTECTED]> __ ___

[issue2610] string representation of range

Brad Miller <[EMAIL PROTECTED]> added the comment: Based on the discussion on python-dev I've worked up a patch and tests for repr of dict_items, dict_keys, and dict_values. I've also modified the patch and test for str of the range object. (If there was a way to get the str(range(10)) to a

[issue2610] string representation of range

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: FWIW, I would like to see a newsgroup or python-dev discussion for a more general solution to the problem for helpful repr's for iterators. In 3.0, lots of things return iterators, not just range(). Before applying one ad-hoc patch, i

[issue2610] string representation of range

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Now there are objections. > > Other than some mild frustration at having invested a fair amount of > time in producing my first python patch, I am also in the middle of > editing a textbook that will come out this fall. Don't be frustra

[issue2610] string representation of range

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I don't think <0, 1, ..., 9> is much clearer than range(0, 10). The > only problem students may have is that 10 not in range(0, 10), but this > can be learned very quickly. The <..> repr breaks x == eval(repr(x)) > invariant which is a

[issue2610] string representation of range

Brad Miller <[EMAIL PROTECTED]> added the comment: > I would suggest considering a custom displayhook approach. You can > write a custom displayhook that will print range(..), {}.keys(), > {}.values() etc in a student-friendly way. I believe a module > installing such display hook can be includ

[issue2610] string representation of range

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Fri, Apr 11, 2008 at 2:45 PM, Brad Miller <[EMAIL PROTECTED]> wrote: .. > My question is how does this get resolved. When I posted this idea to > python-dev Guido suggested an approach. Nobody else expressed an opinion > so after

[issue2610] string representation of range

Brad Miller <[EMAIL PROTECTED]> added the comment: Clearly neither Alexander nor I are going to get the other to come around to our point of view. Thats fine, I think we can disagree here, and I can adapt and change my class either way. My question is how does this get resolved. When I poste

[issue2610] string representation of range

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Fri, Apr 11, 2008 at 12:06 PM, Brad Miller <[EMAIL PROTECTED]> wrote: > Our use of range in the first few classes is exactly for iteration > purposes, but I do not like students to have to have too many mysteries. > So I always ha

[issue2610] string representation of range

Brad Miller <[EMAIL PROTECTED]> added the comment: Our use of range in the first few classes is exactly for iteration purposes, but I do not like students to have to have too many mysteries. So I always have liked to show that range(10) simply produces a sequence of integers. In Python 3.0 r

[issue2610] string representation of range

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: It looks like our messages have crossed in flight. > this little patch allows them to print(range(100,0,-1)) > and get a much better intuition about what is happening. This is a really bad example. Why would you want to introduce the

[issue2610] string representation of range

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: I did not realize that the proposed patch only affects str and not repr. Some of may previous arguments against it do not hold in this case, but I am still -1. If you introduce range before list, it will be hard to explain why lists

[issue2610] string representation of range

Brad Miller <[EMAIL PROTECTED]> added the comment: The patch does not change the behavior of repr. It modifies the behavior of str. I agree that learning list/tuple sooner is better, but students who have never written a line of code before can only absorb so much information, this little pa

[issue2610] string representation of range

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: -1 I don't think <0, 1, ..., 9> is much clearer than range(0, 10). The only problem students may have is that 10 not in range(0, 10), but this can be learned very quickly. The <..> repr breaks x == eval(repr(x)) invariant which is

[issue2610] string representation of range

Brad Miller <[EMAIL PROTECTED]> added the comment: Here is a new patch file. This one contains the modifications to rangeobject.c as well as test_range.py I think this is everything. If there is something else I need to do please let me know. I looked to see if there was any documentation I

[issue2610] string representation of range

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > In a world where ints and long ints have been unified the existence of > this error seems like a bug. > > I think the right thing would be to fix range_item and range_length so > they do not use Py_ssize_t for the length of the range. B

[issue2610] string representation of range

Brad Miller <[EMAIL PROTECTED]> added the comment: Thanks for all of the help. Using range_item certainly simplified my job. Although I more than made up for it with all of the decref and error checking calls. One side effect of using range_item is that str(range(...)) is now subject to the

[issue2610] string representation of range

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I use Python in my CS1 and CS2 curriculum and I have a question. At this point, I would have almost stopped reading - the tracker is not a place for questions. I read on and then noticed that you have a patch also, not just a question :-)

[issue2610] string representation of range

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Thanks for the patch! You can avoid the compiler warning by casting to reprfunc like this: (reprfunc)range_str /* tp_str */ Also, some of the whitespace needs reformating. Please put a space between the parameters passed a function, and r

[issue2610] string representation of range

New submission from Brad Miller <[EMAIL PROTECTED]>: I use Python in my CS1 and CS2 curriculum and I have a question. As I've been using the Python 3.0 alphas one of the things that I am bothered by is that I cannot see the sequence produced by range without introducing students to the list() fun