why dict_items object does not support indexing

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
6
down vote

favorite












I know that you can cast dict_items into a list to allow item indexing. But I do not know why this operation is not allowed directly. Is it because dict_items objects are generators? If so, when I'm seeing



>>> "foo": "bar", "baz": "qux".items()
dict_items([('foo', 'bar'), ('baz', 'qux')])


is python evaluating my generator when repr is called?






python python-3.x







share|improve this question



















  • 2




    Note that you're not casting it to a list; you're creating a new list from it. Whether or not this is efficient depends on the Python implementation.
    – Jonathon Reinhart
    3 hours ago










  • There is no built-in named dict_items. I assume you mean the dict method items().
    – martineau
    3 hours ago






  • 3




    @martineau: type(.items()).__name__ -> 'dict_items'
    – Mad Physicist
    3 hours ago






  • 1




    I think it's because the object of type dict_items that the dict.items() method returns is a dictionary view object which are dynamic and reflect changes that may be occurring to the dictionary on-the-fly—so indexing something like that which might change at any moment doesn't make too much sense. If you convert it to a list, the contents of that list would be changed by updates to the dictionary it came from.
    – martineau
    3 hours ago










  • Related: Accessing dictionary items by position in Python 3.6+ efficiently, specifically this answer.
    – jpp
    2 hours ago














up vote
6
down vote

favorite












I know that you can cast dict_items into a list to allow item indexing. But I do not know why this operation is not allowed directly. Is it because dict_items objects are generators? If so, when I'm seeing



>>> "foo": "bar", "baz": "qux".items()
dict_items([('foo', 'bar'), ('baz', 'qux')])


is python evaluating my generator when repr is called?






python python-3.x







share|improve this question



















  • 2




    Note that you're not casting it to a list; you're creating a new list from it. Whether or not this is efficient depends on the Python implementation.
    – Jonathon Reinhart
    3 hours ago










  • There is no built-in named dict_items. I assume you mean the dict method items().
    – martineau
    3 hours ago






  • 3




    @martineau: type(.items()).__name__ -> 'dict_items'
    – Mad Physicist
    3 hours ago






  • 1




    I think it's because the object of type dict_items that the dict.items() method returns is a dictionary view object which are dynamic and reflect changes that may be occurring to the dictionary on-the-fly—so indexing something like that which might change at any moment doesn't make too much sense. If you convert it to a list, the contents of that list would be changed by updates to the dictionary it came from.
    – martineau
    3 hours ago










  • Related: Accessing dictionary items by position in Python 3.6+ efficiently, specifically this answer.
    – jpp
    2 hours ago












up vote
6
down vote

favorite









up vote
6
down vote

favorite











I know that you can cast dict_items into a list to allow item indexing. But I do not know why this operation is not allowed directly. Is it because dict_items objects are generators? If so, when I'm seeing



>>> "foo": "bar", "baz": "qux".items()
dict_items([('foo', 'bar'), ('baz', 'qux')])


is python evaluating my generator when repr is called?






python python-3.x







share|improve this question















I know that you can cast dict_items into a list to allow item indexing. But I do not know why this operation is not allowed directly. Is it because dict_items objects are generators? If so, when I'm seeing



>>> "foo": "bar", "baz": "qux".items()
dict_items([('foo', 'bar'), ('baz', 'qux')])


is python evaluating my generator when repr is called?






python python-3.x




python python-3.x






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 3 hours ago









Mad Physicist

30.7k156389




30.7k156389










asked 3 hours ago









ohe

1,80911835




1,80911835







  • 2




    Note that you're not casting it to a list; you're creating a new list from it. Whether or not this is efficient depends on the Python implementation.
    – Jonathon Reinhart
    3 hours ago










  • There is no built-in named dict_items. I assume you mean the dict method items().
    – martineau
    3 hours ago






  • 3




    @martineau: type(.items()).__name__ -> 'dict_items'
    – Mad Physicist
    3 hours ago






  • 1




    I think it's because the object of type dict_items that the dict.items() method returns is a dictionary view object which are dynamic and reflect changes that may be occurring to the dictionary on-the-fly—so indexing something like that which might change at any moment doesn't make too much sense. If you convert it to a list, the contents of that list would be changed by updates to the dictionary it came from.
    – martineau
    3 hours ago










  • Related: Accessing dictionary items by position in Python 3.6+ efficiently, specifically this answer.
    – jpp
    2 hours ago












  • 2




    Note that you're not casting it to a list; you're creating a new list from it. Whether or not this is efficient depends on the Python implementation.
    – Jonathon Reinhart
    3 hours ago










  • There is no built-in named dict_items. I assume you mean the dict method items().
    – martineau
    3 hours ago






  • 3




    @martineau: type(.items()).__name__ -> 'dict_items'
    – Mad Physicist
    3 hours ago






  • 1




    I think it's because the object of type dict_items that the dict.items() method returns is a dictionary view object which are dynamic and reflect changes that may be occurring to the dictionary on-the-fly—so indexing something like that which might change at any moment doesn't make too much sense. If you convert it to a list, the contents of that list would be changed by updates to the dictionary it came from.
    – martineau
    3 hours ago










  • Related: Accessing dictionary items by position in Python 3.6+ efficiently, specifically this answer.
    – jpp
    2 hours ago







2




2




Note that you're not casting it to a list; you're creating a new list from it. Whether or not this is efficient depends on the Python implementation.
– Jonathon Reinhart
3 hours ago




Note that you're not casting it to a list; you're creating a new list from it. Whether or not this is efficient depends on the Python implementation.
– Jonathon Reinhart
3 hours ago












There is no built-in named dict_items. I assume you mean the dict method items().
– martineau
3 hours ago




There is no built-in named dict_items. I assume you mean the dict method items().
– martineau
3 hours ago




3




3




@martineau: type(.items()).__name__ -> 'dict_items'
– Mad Physicist
3 hours ago




@martineau: type(.items()).__name__ -> 'dict_items'
– Mad Physicist
3 hours ago




1




1




I think it's because the object of type dict_items that the dict.items() method returns is a dictionary view object which are dynamic and reflect changes that may be occurring to the dictionary on-the-fly—so indexing something like that which might change at any moment doesn't make too much sense. If you convert it to a list, the contents of that list would be changed by updates to the dictionary it came from.
– martineau
3 hours ago




I think it's because the object of type dict_items that the dict.items() method returns is a dictionary view object which are dynamic and reflect changes that may be occurring to the dictionary on-the-fly—so indexing something like that which might change at any moment doesn't make too much sense. If you convert it to a list, the contents of that list would be changed by updates to the dictionary it came from.
– martineau
3 hours ago












Related: Accessing dictionary items by position in Python 3.6+ efficiently, specifically this answer.
– jpp
2 hours ago




Related: Accessing dictionary items by position in Python 3.6+ efficiently, specifically this answer.
– jpp
2 hours ago












1 Answer
1






active

oldest

votes

















up vote
7
down vote













dict_items do not support indexing because these objects are intended to be set-like, and sets do not support indexing.



They do quack like sets in other ways:



>>> d1 = 'k1': 'v1', 'k2': 'v2', 'k3': 'v3'
>>> d2 = 'k2': 'v2', 'k3': 'not v3'
>>> d1.items() & d2.items()
('k2', 'v2')
>>> d1.items() | d2.items()
('k1', 'v1'), ('k2', 'v2'), ('k3', 'not v3'), ('k3', 'v3')


If any value is not hashable, you lose the ability to treat the dict items views with set operations.



It is not sensible to give indexing support to dict_items views, because the dict does not have an ordering until Python 3.7+, so accessing "the 0th" item would not be well-defined. Even in Python 3.7, where there is a sensible ordering to use for indexing (i.e. the insertion order), it is non-trivial to implement this with O(1) complexity, so it's not supported. The "unwritten rule" is that indexing should be constant-time operation (as it is for list, tuple, dict, str - see here).






share|improve this answer


















  • 2




    That's actually a much better reason than the one I gave of "It's not supported because there's no support for it" :)
    – Mad Physicist
    3 hours ago






  • 1




    wim: How did you learn all this about the undocumented type? Just by experiments or perhaps reading the CPython source code?
    – martineau
    3 hours ago






  • 1




    Good question..reading the mailing lists, seeing the comments from CPython core developers on bugs.python.org, finding bugs in the implementation etc.
    – wim
    3 hours ago






  • 2




    Good answer. To appreciate it is non-trivial to implement this with O(1) complexity, see this answer and the comments.
    – jpp
    2 hours ago











Your Answer





StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52900328%2fwhy-dict-items-object-does-not-support-indexing%23new-answer', 'question_page');

);

Post as a guest

















1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
7
down vote













dict_items do not support indexing because these objects are intended to be set-like, and sets do not support indexing.



They do quack like sets in other ways:



>>> d1 = 'k1': 'v1', 'k2': 'v2', 'k3': 'v3'
>>> d2 = 'k2': 'v2', 'k3': 'not v3'
>>> d1.items() & d2.items()
('k2', 'v2')
>>> d1.items() | d2.items()
('k1', 'v1'), ('k2', 'v2'), ('k3', 'not v3'), ('k3', 'v3')


If any value is not hashable, you lose the ability to treat the dict items views with set operations.



It is not sensible to give indexing support to dict_items views, because the dict does not have an ordering until Python 3.7+, so accessing "the 0th" item would not be well-defined. Even in Python 3.7, where there is a sensible ordering to use for indexing (i.e. the insertion order), it is non-trivial to implement this with O(1) complexity, so it's not supported. The "unwritten rule" is that indexing should be constant-time operation (as it is for list, tuple, dict, str - see here).






share|improve this answer


















  • 2




    That's actually a much better reason than the one I gave of "It's not supported because there's no support for it" :)
    – Mad Physicist
    3 hours ago






  • 1




    wim: How did you learn all this about the undocumented type? Just by experiments or perhaps reading the CPython source code?
    – martineau
    3 hours ago






  • 1




    Good question..reading the mailing lists, seeing the comments from CPython core developers on bugs.python.org, finding bugs in the implementation etc.
    – wim
    3 hours ago






  • 2




    Good answer. To appreciate it is non-trivial to implement this with O(1) complexity, see this answer and the comments.
    – jpp
    2 hours ago















up vote
7
down vote













dict_items do not support indexing because these objects are intended to be set-like, and sets do not support indexing.



They do quack like sets in other ways:



>>> d1 = 'k1': 'v1', 'k2': 'v2', 'k3': 'v3'
>>> d2 = 'k2': 'v2', 'k3': 'not v3'
>>> d1.items() & d2.items()
('k2', 'v2')
>>> d1.items() | d2.items()
('k1', 'v1'), ('k2', 'v2'), ('k3', 'not v3'), ('k3', 'v3')


If any value is not hashable, you lose the ability to treat the dict items views with set operations.



It is not sensible to give indexing support to dict_items views, because the dict does not have an ordering until Python 3.7+, so accessing "the 0th" item would not be well-defined. Even in Python 3.7, where there is a sensible ordering to use for indexing (i.e. the insertion order), it is non-trivial to implement this with O(1) complexity, so it's not supported. The "unwritten rule" is that indexing should be constant-time operation (as it is for list, tuple, dict, str - see here).






share|improve this answer


















  • 2




    That's actually a much better reason than the one I gave of "It's not supported because there's no support for it" :)
    – Mad Physicist
    3 hours ago






  • 1




    wim: How did you learn all this about the undocumented type? Just by experiments or perhaps reading the CPython source code?
    – martineau
    3 hours ago






  • 1




    Good question..reading the mailing lists, seeing the comments from CPython core developers on bugs.python.org, finding bugs in the implementation etc.
    – wim
    3 hours ago






  • 2




    Good answer. To appreciate it is non-trivial to implement this with O(1) complexity, see this answer and the comments.
    – jpp
    2 hours ago













up vote
7
down vote










up vote
7
down vote









dict_items do not support indexing because these objects are intended to be set-like, and sets do not support indexing.



They do quack like sets in other ways:



>>> d1 = 'k1': 'v1', 'k2': 'v2', 'k3': 'v3'
>>> d2 = 'k2': 'v2', 'k3': 'not v3'
>>> d1.items() & d2.items()
('k2', 'v2')
>>> d1.items() | d2.items()
('k1', 'v1'), ('k2', 'v2'), ('k3', 'not v3'), ('k3', 'v3')


If any value is not hashable, you lose the ability to treat the dict items views with set operations.



It is not sensible to give indexing support to dict_items views, because the dict does not have an ordering until Python 3.7+, so accessing "the 0th" item would not be well-defined. Even in Python 3.7, where there is a sensible ordering to use for indexing (i.e. the insertion order), it is non-trivial to implement this with O(1) complexity, so it's not supported. The "unwritten rule" is that indexing should be constant-time operation (as it is for list, tuple, dict, str - see here).






share|improve this answer














dict_items do not support indexing because these objects are intended to be set-like, and sets do not support indexing.



They do quack like sets in other ways:



>>> d1 = 'k1': 'v1', 'k2': 'v2', 'k3': 'v3'
>>> d2 = 'k2': 'v2', 'k3': 'not v3'
>>> d1.items() & d2.items()
('k2', 'v2')
>>> d1.items() | d2.items()
('k1', 'v1'), ('k2', 'v2'), ('k3', 'not v3'), ('k3', 'v3')


If any value is not hashable, you lose the ability to treat the dict items views with set operations.



It is not sensible to give indexing support to dict_items views, because the dict does not have an ordering until Python 3.7+, so accessing "the 0th" item would not be well-defined. Even in Python 3.7, where there is a sensible ordering to use for indexing (i.e. the insertion order), it is non-trivial to implement this with O(1) complexity, so it's not supported. The "unwritten rule" is that indexing should be constant-time operation (as it is for list, tuple, dict, str - see here).







share|improve this answer














share|improve this answer



share|improve this answer








edited 2 hours ago









user2357112

144k12147229




144k12147229










answered 3 hours ago









wim

150k45282409




150k45282409







  • 2




    That's actually a much better reason than the one I gave of "It's not supported because there's no support for it" :)
    – Mad Physicist
    3 hours ago






  • 1




    wim: How did you learn all this about the undocumented type? Just by experiments or perhaps reading the CPython source code?
    – martineau
    3 hours ago






  • 1




    Good question..reading the mailing lists, seeing the comments from CPython core developers on bugs.python.org, finding bugs in the implementation etc.
    – wim
    3 hours ago






  • 2




    Good answer. To appreciate it is non-trivial to implement this with O(1) complexity, see this answer and the comments.
    – jpp
    2 hours ago













  • 2




    That's actually a much better reason than the one I gave of "It's not supported because there's no support for it" :)
    – Mad Physicist
    3 hours ago






  • 1




    wim: How did you learn all this about the undocumented type? Just by experiments or perhaps reading the CPython source code?
    – martineau
    3 hours ago






  • 1




    Good question..reading the mailing lists, seeing the comments from CPython core developers on bugs.python.org, finding bugs in the implementation etc.
    – wim
    3 hours ago






  • 2




    Good answer. To appreciate it is non-trivial to implement this with O(1) complexity, see this answer and the comments.
    – jpp
    2 hours ago








2




2




That's actually a much better reason than the one I gave of "It's not supported because there's no support for it" :)
– Mad Physicist
3 hours ago




That's actually a much better reason than the one I gave of "It's not supported because there's no support for it" :)
– Mad Physicist
3 hours ago




1




1




wim: How did you learn all this about the undocumented type? Just by experiments or perhaps reading the CPython source code?
– martineau
3 hours ago




wim: How did you learn all this about the undocumented type? Just by experiments or perhaps reading the CPython source code?
– martineau
3 hours ago




1




1




Good question..reading the mailing lists, seeing the comments from CPython core developers on bugs.python.org, finding bugs in the implementation etc.
– wim
3 hours ago




Good question..reading the mailing lists, seeing the comments from CPython core developers on bugs.python.org, finding bugs in the implementation etc.
– wim
3 hours ago




2




2




Good answer. To appreciate it is non-trivial to implement this with O(1) complexity, see this answer and the comments.
– jpp
2 hours ago





Good answer. To appreciate it is non-trivial to implement this with O(1) complexity, see this answer and the comments.
– jpp
2 hours ago


















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52900328%2fwhy-dict-items-object-does-not-support-indexing%23new-answer', 'question_page');

);

Post as a guest
































































Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

Image
Clash Royale CLAN TAG #URR8PPP .everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0; up vote -3 down vote favorite Say, for example I have worked in the following companies, Company A => 2010 - 2011 Company B => 2011 - 2012 Company C => 2012 - Till Date Company D => Have offer Now assume Company D is asking to submit documents from my second last employer. So from the list of companies given, which company would be qualified as second last employer? software-industry employer share | improve this question asked Aug 10 '14 at 5:16 Rajaprabhu Aravindasamy 559 1 6 13 closed as off-topic by Jim G., jmort253 ♦ Aug 11 '14 at 1:58 This question appears to be off-topic. The users who voted to close gave this specific reason: "Questions seeking advice on company-specific regulations, agreements, or policies should be directed to your manager or HR department. Questions that address...
Read more

Installing NextGIS Connect into QGIS 3?

Image
Clash Royale CLAN TAG #URR8PPP .everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0; up vote 1 down vote favorite Just acquired free version of NEXTGIS and trying to install the plugin for QGIS. It tells me it was not designed for version 3 of QGIS. How do I set up the QGIS-NEXTGIS interface then? qgis qgis-plugins nextgis share | improve this question edited 3 hours ago PolyGeo ♦ 51.9k 17 77 233 asked 4 hours ago IanGS 16 4 New contributor IanGS is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct. add a comment  |  up vote 1 down vote favorite Just acquired free version of NEXTGIS and trying to install the plugin for QGIS. It tells me it was not designed for version 3 of QGIS. How do I set up the QGIS-NEXTGIS interface then? qgis qgis-plugin...
Read more

One-line joke

A one-liner is a joke that is delivered in a single line. A good one-liner is said to be pithy - concise and meaningful. [1] Comedians and actors use this comedic method as part of their act, e.g. Jimmy Carr, Tommy Cooper, Rodney Dangerfield, Norm Macdonald, Ken Dodd, Stewart Francis, Zach Galifianakis, Mitch Hedberg, Anthony Jeselnik, Milton Jones, Shappi Khorsandi, Jay London, Mark Linn-Baker, Demetri Martin, Groucho Marx, Dan Mintz, Emo Philips, Tim Vine, Steven Wright and Henny Youngman and Arnold Schwarzenegger. [ citation needed ] Many fictional characters are also known to deliver one-liners, including James Bond, who usually includes pithy and laconic quips after disposing of a villain. [ citation needed ] Examples "A baby seal walks into a club." "A dyslexic man walks into a bra." (Anonymous) "There are three types of people, those who can count and those who can't." "Venison's dear, isn't it?" (Jimmy Carr) "An escala...
Read more