[issue2610] string representation of range and dictionary views

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Closing since this is now implemented.

--
resolution:  -> out of date
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2610] string representation of range and dictionary views

[Brad Miller]

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 the standard library.  From the research I've done 
it looks like a solution for range would be something like the 
following:

import sys
def eduhook(o):
if o is None:
return
if isinstance(o,range):
print(list(o))
else:
print(repr(o))

sys.displayhook = eduhook

Now if 5233/5234 were approved I could tell my students to setup an 
environment variable PYTHONSTARTUP that points to a file that imports a 
module containing the above code.  (or I could just tell them to import 
said module each time.)

The above hook appears to work fine.  Is there anything obvious I'm 
missing?  If this is along the right track then I could extend it to 
support other custom display ideas that my fellow educators have in 
mind.

Thanks,

Brad

--
message_count: 30.0 -> 31.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2610] string representation of range and dictionary views

[Benjamin Peterson]

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]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2610] string representation of range and dictionary views

[And Clover]

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 the interactive prompt that good reprs are useful, it's
also in debugging: debug-prints in scripts in general, web application
error pages that dump variable information, error detail logging to a
database for inspection long after the ability to inspect the value has
passed, and so on.

I think it's better to put the feature in repr than require all these
things - everything that might want to display values helpfully - to
implement detection and prettification for specific iterators.

Sure, you can apply list() if you know in advance you're going to need
to, but for beginners and debuggers getting the information out there
without having to ask for it is a real win. I certainly remember how
pleasantly surprised I was when learning Python 1.something and finding
it just told me what I wanted to know without having to ask for it - in
contrast to previous tedious languages that only ever said 'object' or
'[Array]'...

I can't really think of any advantage to having repr keep that
information hidden.

--
nosy: +aclover

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2610] string representation of range and dictionary views

[Martin v. Löwis]

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 objective anymore, which
was to display range() nicely at the interactive prompt.

> Maybe it is just because I spend a lot more time in the interactive
> interpreter that I see this as a big improvement.

So do I. But I typically display the dictionary itself when looking
at it in an interactive prompt; I would not normally look at .keys(),
except when I want to know what all the keys in the dictionary are,
in which case the new repr won't help, either (and I will have to
apply list() in 3.0, or, rather, sorted())

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2610] string representation of range and dictionary views

[Brad Miller]

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 purpose (anymore), as it only changes
> tp_str for range objects (although it does change tp_repr for dict views
> - why this inconsistency?).
>
The reason for the inconsistency is that there was a strong argument
that the tp_repr for range already returned something useful that
people could take advantage of in their code.  The same was not the
case for the dict views.

I do not understand why you think that having the interpreter display

when x.keys() is called is not an improvement over


Maybe it is just because I spend a lot more time in the interactive
interpreter that I see this as a big improvement.

So if, as Raymond Hettinger suggests, the interpreter is the right
place to make this change I'd still be happy to provide a patch if
someone could give me a pointer for where to start looking.

Brad

> So I'm -0 on the patch, meaning that I won't commit it, but won't object
> to anybody else committing it, either.
>
> Technically, in dictview_repr, the first call to PyUnicode_Concat isn't
> checked for exceptions.
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> 
> ___
>

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2610] string representation of range and dictionary views

[Raymond Hettinger]

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 "_".  That same code can also add 
custom interactive reporting for a few, known iterators.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2610] string representation of range and dictionary views

[Martin v. Löwis]

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 I'm -0 on the patch, meaning that I won't commit it, but won't object
to anybody else committing it, either.

Technically, in dictview_repr, the first call to PyUnicode_Concat isn't
checked for exceptions.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2610] string representation of range and dictionary views

[Brad Miller]

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 of consensus was reached and now the patch has  
been lingering without additional comment for several weeks.   I have  
some sense of urgency in knowing the future as the final opportunity  
to include these changes in my introduction to CS book is looming on  
the horizon.

Thanks,

Brad

> __
> Tracker <[EMAIL PROTECTED]>
> 
> __

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2610] string representation of range and dictionary views

[Martin v. Löwis]

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]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2610] string representation of range and dictionary views

[Brad Miller]

Brad Miller <[EMAIL PROTECTED]> added the comment:

Is there any chance this patch will make it into the latest alpha??

Brad

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2610] string representation of range and dictionary views

[Brad Miller]

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 insertion order... the test seems fragile.
> Or you may rely on the fact that ints are their own hash values, so a
> small dict containing small keys will appear ordered. I suggest
> something like {6: 1.2, 1: 'A', 7: 42, 4: None}

I wondered about that, but my assumption was that the hash function  
for strings and ints was equally unlikely to change.  I can go with  
all ints if that is really a safer assumption.

>
>
> - empty dicts or empty ranges will display:
>   
>   
> Isn't there a better repr? At least this should appear in the tests.

I'm not sure how to represent that better.

   -- These seem misleading


   -- I'm not sure that is better than  
 and empty may not mean anything to non-english speakers

I'll be happy to add the test for the empty case after once I know  
what it should look like.

>
>
> --
> nosy: +amaury.forgeotdarc
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2610] string representation of range and dictionary views

[Amaury Forgeot d'Arc]

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 dict containing small keys will appear ordered. I suggest
something like {6: 1.2, 1: 'A', 7: 42, 4: None}

- empty dicts or empty ranges will display:
   
   
Isn't there a better repr? At least this should appear in the tests.

--
nosy: +amaury.forgeotdarc

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2610] string representation of range and dictionary views

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
title: string representation of range -> string representation of range and 
dictionary views

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com