[issue21607] results of `zip` are displayed as 'zip object at 0xxxxxx
New submission from Sasha Ovsankin: Python 3.4.0 (default, May 20 2014, 20:42:24) [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin Type help, copyright, credits or license for more information. zip([1, 2, 3], [a, b, c]) zip object at 0x1017c79c8 Python 2.7.5 (default, Mar 9 2014, 22:15:05) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin Type help, copyright, credits or license for more information. zip([1, 2, 3], [a, b, c]) [(1, 'a'), (2, 'b'), (3, 'c')] -- components: Library (Lib) messages: 219348 nosy: Sasha.Ovsankin priority: normal severity: normal status: open title: results of `zip` are displayed as 'zip object at 0xx versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21607 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21607] results of `zip` are displayed as 'zip object at 0xxxxxx
SilentGhost added the comment: This is the correct behaviour. In python 3 zip returns an iterator. Detailed information is available in documentation. https://docs.python.org/3/library/functions.html#zip -- nosy: +SilentGhost resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21607 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21607] results of `zip` are displayed as 'zip object at 0xxxxxx
Eric Snow added the comment: It may be the correct behavior but that doesn't mean we cannot update the repr to be more informative. We've already done that for a number of types that previously used the default __repr__() implementation. So in the case, how hard would it be to have the following repr? zip([1, 2, 3], [a, b, c]) zip([1, 2, 3], [a, b, c]) -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21607 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21607] results of `zip` are displayed as 'zip object at 0xxxxxx
Serhiy Storchaka added the comment: zip(list_iterator object at 0xb70c7c8c, list_iterator object at 0xb70c7cac) doesn't look more readable to me. -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21607 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21607] results of `zip` are displayed as 'zip object at 0xxxxxx
Sasha Ovsankin added the comment: It's also showing up in iPython. list(...) is a reasonable workaround but I disagree with the not a bug opinion. This is definitely the regression vs Python 2. Who else can I talk to about reopening this? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21607 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21607] results of `zip` are displayed as 'zip object at 0xxxxxx
Eric Snow added the comment: zip(list_iterator object at 0xb70c7c8c, list_iterator object at 0xb70c7cac) doesn't look more readable to me. Well, that seems more informative to me. Now you know that you're zipping together two list iterators. By readable do you mean shorter? In my opinion the size of a repr is less of a concern (though not insignificant) than the usefulness of the information the repr contains. The fact that some objects (like list iterators) don't themselves have informative reprs is an issue for any object with a custom repr that reports it's attrs/args. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21607 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21607] results of `zip` are displayed as 'zip object at 0xxxxxx
Mark Lawrence added the comment: How do you display the contents of an iterable without using them up, or have I grossly overlooked something? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21607 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21607] results of `zip` are displayed as 'zip object at 0xxxxxx
Sasha Ovsankin added the comment: How do you display the contents of an iterable without using them up In general case you can't, but zip object _is_ reusable iterable so we can reuse it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21607 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21607] results of `zip` are displayed as 'zip object at 0xxxxxx
SilentGhost added the comment: How do you display the contents of an iterable without using them up In general case you can't, but zip object _is_ reusable iterable so we can reuse it? I think you're misunderstanding what an iterator is or how it functions. Just to make it clear, it cannot be reused. What Eric suggested, was to look at the inputs of zip and construct a representation of zip object that is more user friendly. The point that Serhiy's is making is that its usefulness is actually fairly limited. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21607 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21607] results of `zip` are displayed as 'zip object at 0xxxxxx
Sasha Ovsankin added the comment: Yep, you are right. Even the zip thingy is not reusable. Oh well... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21607 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
