dict.keys() ?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • bearophileHUGS@lycos.com

    #1

    dict.keys() ?

    The PEP 3100:
    This PEP, previously known as PEP 3000, describes smaller scale changes and new features for which no separate PEP is written yet, all targeted for Python 3000.

    says:

    Return iterators instead of lists where appropriate for atomic type
    methods (e.g. dict.keys(), dict.values(), dict.items(), etc.); iter*
    methods will be removed. Better: make keys(), etc. return views ala
    Java collections???
    ....
    To be removed:
    dict.setdefault ()? [15]
    dict.has_key() method [done]


    I may be sleepy now, but maybe the keys() method too can be removed;
    otherwise the following two become really the same:

    print list(adict)
    for k in adict: ...

    print list(adict.keys ())
    for k in adict.keys(): ...

    Bye,
    bearophile

  • George Sakkis

    #2
    Re: dict.keys() ?

    On Jan 26, 10:04 pm, bearophileH...@ lycos.com wrote:
    The PEP 3100:http://www.python.org/dev/peps/pep-3100/
    says:
    >
    Return iterators instead of lists where appropriate for atomic type
    methods (e.g. dict.keys(), dict.values(), dict.items(), etc.); iter*
    methods will be removed. Better: make keys(), etc. return views ala
    Java collections???
    ...
    To be removed:
    dict.setdefault ()? [15]
    dict.has_key() method [done]
    >
    I may be sleepy now, but maybe the keys() method too can be removed;
    otherwise the following two become really the same:
    >
    print list(adict)
    for k in adict: ...
    >
    print list(adict.keys ())
    for k in adict.keys(): ...
    Alas, the consensus has moved away from simple iterators to less
    lightweight "views":



    "The objects returned by the .keys() and .items() methods behave like
    sets with limited mutability; the allow removing elements, but not
    adding them.(...) The object returned by the values() method behaves
    like a multiset."

    I for one am not convinced that adding three new types is worth the
    complexity and the error-proneness of having two new
    similar-but-not-quite-the-same APIs with sets. Not only iteration is
    arguably the most common operation on a view, but the cost (in extra
    keystrokes and runtime performance) of populating any container that
    the user may need from an iterator is pretty low.

    George

    Comment

    Working...