[issue33872] doc Add list access time to list definition

Raymond Hettinger added the comment: -1 We've historically chosen to not include such implementation specific details and it seems to have not been a problem for users. The glossary in particular is no place to talk about such specifics. -- nosy: +rhettinger, tim.peters resolution:

[issue33872] doc Add list access time to list definition

Xiang Zhang added the comment: I concur with INADA. I don't prefer to add such implementation choice in definition. As for glossary, it may be unnecessary either but since it's already there, I don't think it needs to be removed. -- nosy: +xiang.zhang ___

[issue33872] doc Add list access time to list definition

INADA Naoki added the comment: Andrés Delfino : > > Andrés Delfino added the comment: > > IMHO, if we deem it useful for users not to expect the time complexity of > a linked list for list elements access to the extent of adding a comment in > the glossary, there's no reason it isn't useful to

[issue33872] doc Add list access time to list definition

Andrés Delfino added the comment: IMHO, if we deem it useful for users not to expect the time complexity of a linked list for list elements access to the extent of adding a comment in the glossary, there's no reason it isn't useful to someone who is reading the actual list definition. Moreove

[issue33872] doc Add list access time to list definition

INADA Naoki added the comment: In case of "difference with linked-list", I don't want to make list definition longer and longer for readers only small part of people. I think that's why difference with "linked-list" is documented only in glossary. By adding all information for non-zero grou

[issue33872] doc Add list access time to list definition

Andrés Delfino added the comment: INADA, I believe that piece of information is on the Glossary just to make the difference with a "linked list", but in that case, it should be in the list definition too, as it's fair to think people can learn what a list is by reading its definition first, i

[issue33872] doc Add list access time to list definition

INADA Naoki added the comment: List is documented in “sequence” section and O(1) index access is typical for sequences. At least, every builtin types have it. So adding such note only to list seems a bit curious to me. -- nosy: +inada.naoki ___ Pyt

[issue33872] doc Add list access time to list definition

Ammar Askar added the comment: I'd say edit the PR and the bug tracker issue to reflect the change. Though you might want to wait for the opinion of a core dev or someone with more documentation experience than me. -- ___ Python tracker

[issue33872] doc Add list access time to list definition

Andrés Delfino added the comment: If O(1) time complexity for element access is not a requirement (which it seems it's not), I agree that this PR as it is should be closed, and the Glossary entry should have this detail removed. In that case, can I edit the PR or should I open a new one? ---

[issue33872] doc Add list access time to list definition

Ammar Askar added the comment: I don't think this should be documented at all, not in the glossary, nor the stdtypes section. A quick search through of the glossary and stdtypes indicates that the glossary entry of list is the only place where a time complexity is documented. The problem wi

[issue33872] doc Add list access time to list definition

Change by Andrés Delfino : -- keywords: +patch pull_requests: +7341 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-li

[issue33872] doc Add list access time to list definition

New submission from Andrés Delfino : Glossary talks about list access complexity, but the actual list definition doesn't. I think glossary entries should have more information than actual definitions. PR adds list access complexity to list definition. -- assignee: docs@python componen