dict!ident as equivalent of dict["ident"]

Discussion in 'Python' started by Alexander Kozlovsky, May 21, 2006.

  1. Hello all!
    I have small silly syntax suggestion (SSSS)

    In many cases, keys in dictionary-like objects are strings,
    and moreover - valid Python identifiers. Something like:

    foo["bar"]["baz"].x = y

    How about small syntactic sugar:

    foo!bar!baz.x = y

    With this suggestion, mapping!identifier
    becomes fully equivalent to mapping["identifier"]


    --
    Best regards,
    Alexander mailto:
     
    Alexander Kozlovsky, May 21, 2006
    #1
    1. Advertising

  2. Alexander Kozlovsky

    Roy Smith Guest

    In article <>,
    Alexander Kozlovsky <> wrote:

    > Hello all!
    > I have small silly syntax suggestion (SSSS)
    >
    > In many cases, keys in dictionary-like objects are strings,
    > and moreover - valid Python identifiers. Something like:
    >
    > foo["bar"]["baz"].x = y
    >
    > How about small syntactic sugar:
    >
    > foo!bar!baz.x = y


    Ugh. Syntactic sugar like that leads to language obesity. Anyway, you can
    already do what you want with just a little bit of work. Define a class
    (perhaps a subclass of dict, if you like) with a __getattr__ method. Then
    you can just do

    foo.bar.baz.x = y

    with no changes needed to the language.
     
    Roy Smith, May 21, 2006
    #2
    1. Advertising

  3. Alexander Kozlovsky

    Dan Sommers Guest

    On Sun, 21 May 2006 16:19:29 +0400,
    Alexander Kozlovsky <> wrote:

    > How about small syntactic sugar:


    > foo!bar!baz.x = y


    > With this suggestion, mapping!identifier
    > becomes fully equivalent to mapping["identifier"]


    Take a look at the "Bunch" recipe in the Python Cookbook:

    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52308

    Regards,
    Dan

    --
    Dan Sommers
    <http://www.tombstonezero.net/dan/>
    "I wish people would die in alphabetical order." -- My wife, the genealogist
     
    Dan Sommers, May 21, 2006
    #3
  4. Roy Smith wrote:
    > Define a class (perhaps a subclass of dict, if you like)
    > with a __getattr__ method. Then you can just do
    >
    > foo.bar.baz.x = y
    >
    > with no changes needed to the language.


    I think, your solution is very error-prone. If such enhanced
    dictionary contains "keys" key, what is meaning of d.keys?
    Is it bound method or dictionary item? After you introduce
    such dictionary, you cannot add any new method for it, because
    it may destroy user code, if acciddent name clashing take place.

    Consider SQLTable class, which have "name" attribute, and
    bunch of dynamically created named columns. With __getattr__
    method you can use SQLTable.column_1 syntax for column access,
    but what if same column have name "name"? It may be very
    psychologically inconvenient for user of such class to use
    same foo.bar syntax for two different purposes.

    In most real cases it is important to distinguish between
    two different namespaces - "members" namespace with methods
    properties etc., and "items" namespace with truly dynamic
    content. In todays Python such distinction accomplished
    with two different methods - __getattr(ibute)__ and __getitem__.

    It is not possible to successfully use only __getattr__
    to serve two different purposes. Hense I suggest use
    __getitem__ for its direct purpose, and only add some
    syntactic sugar for it

    Dan Sommers wrote:
    > Take a look at the "Bunch" recipe in the Python Cookbook:
    >
    > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52308


    This recipe is what is stated in its name - "collector
    of a bunch of named stuff". It is not suitable for
    elaborate classes with many methods (such as SQLTable),
    for above mentioned reason - name cluttering between
    methods, properties and dynamic content.


    --
    Best regards,
    Alexander mailto:
     
    Alexander Kozlovsky, May 21, 2006
    #4
  5. Alexander Kozlovsky wrote:

    > With this suggestion, mapping!identifier
    > becomes fully equivalent to mapping["identifier"]


    Penny-wise, pound-foolish. Saves 3 character strokes at the cost of a new
    special-purpose operator which only works in limited circumstances. To
    avoid parsing ambiguity, identifier can only contain (as the name implies)
    alphanumerics and _. So your ! is limited not only to dicts but to certain
    keys in certain dicts. More complicated than it's worth.

    --
    Edward Elliott
    UC Berkeley School of Law (Boalt Hall)
    complangpython at eddeye dot net
     
    Edward Elliott, May 21, 2006
    #5
  6. Edward Elliott wrote:
    >> With this suggestion, mapping!identifier
    >> becomes fully equivalent to mapping["identifier"]

    >
    > Penny-wise, pound-foolish. Saves 3 character strokes at the cost of a new
    > special-purpose operator which only works in limited circumstances. To
    > avoid parsing ambiguity, identifier can only contain (as the name implies)
    > alphanumerics and _. So your ! is limited not only to dicts but to certain
    > keys in certain dicts. More complicated than it's worth.


    Yes, it is limited use-case, but IMHO important one.
    The benefits are:
    1. Code looks more neat, because IDE will highlight it as identifier,
    and not as string
    2. Limited form of code completion (as in PythonWin) becomes possible
    3. A bit easier to type, and to read

    Anyway, I don't intent strongly on this, I just like to see
    common attitude

    > So your ! is limited not only to dicts


    Not only to dict, but to any class with __getitem__ or __setitem__
    methods

    --
    Best regards,
    Alexander mailto:
     
    Alexander Kozlovsky, May 22, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Skip Montanaro
    Replies:
    0
    Views:
    428
    Skip Montanaro
    Aug 15, 2003
  2. Erik Max Francis
    Replies:
    0
    Views:
    362
    Erik Max Francis
    Sep 27, 2003
  3. Erik Max Francis
    Replies:
    0
    Views:
    351
    Erik Max Francis
    Oct 22, 2003
  4. malachi
    Replies:
    0
    Views:
    552
    malachi
    Mar 23, 2005
  5. steen
    Replies:
    9
    Views:
    446
    Tom Anderson
    May 24, 2010
Loading...

Share This Page