Why is there no natural syntax for accessing attributes with namesnot being valid identifiers?

Discussion in 'Python' started by Piotr Dobrogost, Dec 3, 2013.

  1. Hi!

    I find global getattr() function awkward when reading code.
    What is the reason there's no "natural" syntax allowing to access attributes with names not being valid Python identifiers in a similar way to other attributes?
    Something along the line of my_object.'valid-attribute-name-but-not-valid-identifier'?


    Regards,
    Piotr Dobrogost
     
    Piotr Dobrogost, Dec 3, 2013
    #1
    1. Advertising

  2. Piotr Dobrogost

    Ethan Furman Guest

    Re: Why is there no natural syntax for accessing attributes withnames not being valid identifiers?

    On 12/03/2013 09:14 AM, Piotr Dobrogost wrote:
    >
    > I find global getattr() function awkward when reading code.
    > What is the reason there's no "natural" syntax allowing to
    > access attributes with names not being valid Python
    > identifiers in a similar way to other attributes?
    >
    > Something along the line of my_object.'valid-attribute-name-but-not-valid-identifier'?


    When would you have attribute names that are not valid identifiers?

    --
    ~Ethan~
     
    Ethan Furman, Dec 3, 2013
    #2
    1. Advertising

  3. Re: Why is there no natural syntax for accessing attributes withnames not being valid identifiers?

    On 12/3/13 12:14 PM, Piotr Dobrogost wrote:
    > Hi!
    >
    > I find global getattr() function awkward when reading code.
    > What is the reason there's no "natural" syntax allowing to access attributes with names not being valid Python identifiers in a similar way to other attributes?
    > Something along the line of my_object.'valid-attribute-name-but-not-valid-identifier'?
    >
    >
    > Regards,
    > Piotr Dobrogost
    >


    I don't know the real reason, but I imagine it would be that it would be
    very rarely used. It would need to be an attribute that isn't a valid
    identifier, and you know the attribute at the time you write the code.

    I can see scenarios for needing attributes that aren't identifiers, but
    in many of them you also need to access them through a variable rather
    than literally.

    --Ned.
     
    Ned Batchelder, Dec 3, 2013
    #3
  4. Piotr Dobrogost

    Dave Angel Guest

    Re: Why is there no natural syntax for accessing attributes with names
    not being valid identifiers?


    On Tue, 3 Dec 2013 09:14:49 -0800 (PST), Piotr Dobrogost
    <> wrote:
    > I find global getattr() function awkward when reading code.


    Me too.
    > What is the reason there's no "natural" syntax allowing to access

    attributes with names not being valid Python identifiers in a similar
    way to other attributes?

    There is. Just use a dictionary.

    --
    DaveA
     
    Dave Angel, Dec 3, 2013
    #4
  5. Piotr Dobrogost

    Guest

    On Tue, Dec 3, 2013, at 12:14, Piotr Dobrogost wrote:
    > Hi!
    >
    > I find global getattr() function awkward when reading code.
    > What is the reason there's no "natural" syntax allowing to access
    > attributes with names not being valid Python identifiers in a similar way
    > to other attributes?
    > Something along the line of
    > my_object.'valid-attribute-name-but-not-valid-identifier'?


    The getattr function is meant for when your attribute name is in a
    variable. Being able to use strings that aren't valid identifiers is a
    side effect. Why are you designing classes with attributes that aren't
    valid identifiers?
     
    , Dec 3, 2013
    #5
  6. Re: Why is there no natural syntax for accessing attributes withnames not being valid identifiers?

    On Tuesday, December 3, 2013 7:03:41 PM UTC+1, wrote:
    > On Tue, Dec 3, 2013, at 12:14, Piotr Dobrogost wrote:
    >
    > > Hi!

    >
    > > I find global getattr() function awkward when reading code.
    > > What is the reason there's no "natural" syntax allowing to access
    > > attributes with names not being valid Python identifiers in a similar way
    > > to other attributes?
    > > Something along the line of
    > > my_object.'valid-attribute-name-but-not-valid-identifier'?

    >
    > The getattr function is meant for when your attribute name is in a
    > variable. Being able to use strings that aren't valid identifiers is a
    > side effect.


    Why do you say it's a side effect? Could you elaborate? I see nothing odd in passing literal (string literal in this case) as a value of function's argument.

    > Why are you designing classes with attributes that aren't
    > valid identifiers?


    Attribute access syntax being very concise is very often preferred to dict's interface. That's why various containers expose their elements as attributes. In my case I'm using in-house web form library which provides FieldSetclass holding objects of type Field or other FieldSets. This nesting leadsto names of the form 'outer_fieldset-inner_fieldset-third_field' which arenot valid identifiers due to minus sign.
     
    Piotr Dobrogost, Dec 3, 2013
    #6
  7. Re: Why is there no natural syntax for accessing attributes withnames not being valid identifiers?

    On Tuesday, December 3, 2013 6:31:58 PM UTC+1, Ethan Furman wrote:
    >
    > When would you have attribute names that are not valid identifiers?
    >

    See my answer to rand's post.
     
    Piotr Dobrogost, Dec 3, 2013
    #7
  8. Piotr Dobrogost

    Tim Chase Guest

    Re: Why is there no natural syntax for accessing attributes withnames not being valid identifiers?

    On 2013-12-03 15:47, Piotr Dobrogost wrote:
    > > The getattr function is meant for when your attribute name is in a
    > > variable. Being able to use strings that aren't valid identifiers
    > > is a side effect.

    >
    > Why do you say it's a side effect?


    I think random832 is saying that the designed purpose of setattr()
    was to dynamically set attributes by name, so they could later be
    accessed the traditional way; not designed from the ground-up to
    support non-identifier names. But because of the getattr/setattr
    machinery (dict key/value pairs), it doesn't prevent you from having
    non-identifiers as names as long as you use only the getattr/setattr
    method of accessing them.

    I see non-traditional-identifiers most frequently in test code where
    the globals() dictionary gets injected with various objects for
    testing purposes, driven by a table with descriptors. Something like
    (untested)

    tests = [
    dict(desc="Test 1", input=10, expected=42),
    dict(desc="Test 2", input=314, expected=159),
    ]
    for test in tests:
    test_name = "test_" + test["desc"]
    globals()[test_name] = generate_test_function(
    test["input"], test["output"])

    -tkc
     
    Tim Chase, Dec 4, 2013
    #8
  9. Piotr Dobrogost

    Tim Roberts Guest

    Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?

    Piotr Dobrogost <> wrote:
    >
    >Attribute access syntax being very concise is very often preferred
    >to dict's interface.


    It is not "very concise". It is slightly more concise.

    x = obj.value1
    x = dct['value1']

    You have saved 3 keystrokes. That is not a significant enough savings to
    create new syntax. Remember the Python philosophy that there ought to be
    one way to do it.
    --
    Tim Roberts,
    Providenza & Boekelheide, Inc.
     
    Tim Roberts, Dec 4, 2013
    #9
  10. Piotr Dobrogost

    rusi Guest

    Re: Why is there no natural syntax for accessing attributes withnames not being valid identifiers?

    On Wednesday, December 4, 2013 11:15:05 AM UTC+5:30, Tim Roberts wrote:
    > Piotr Dobrogost wrote:
    > >
    > >Attribute access syntax being very concise is very often preferred
    > >to dict's interface.

    >
    > It is not "very concise". It is slightly more concise.
    >
    > x = obj.value1
    > x = dct['value1']
    >
    > You have saved 3 keystrokes. That is not a significant enough savings to
    > create new syntax. Remember the Python philosophy that there ought to be
    > one way to do it.


    Its a more fundamental problem than that:
    It emerges from the OP's second post) that he wants '-' in the attributes.
    Is that all?

    Where does this syntax-enlargement stop? Spaces? Newlines?
     
    rusi, Dec 4, 2013
    #10
  11. Piotr Dobrogost

    Ian Kelly Guest

    Re: Why is there no natural syntax for accessing attributes withnames not being valid identifiers?

    On Tue, Dec 3, 2013 at 11:31 PM, rusi <> wrote:
    > Its a more fundamental problem than that:
    > It emerges from the OP's second post) that he wants '-' in the attributes.
    > Is that all?
    >
    > Where does this syntax-enlargement stop? Spaces? Newlines?


    At non-strings.

    >>> setattr(foo, 21+21, 42)

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    TypeError: attribute name must be string, not 'int'
     
    Ian Kelly, Dec 4, 2013
    #11
  12. Piotr Dobrogost

    Ethan Furman Guest

    Re: Why is there no natural syntax for accessing attributes withnames not being valid identifiers?

    On 12/03/2013 09:45 PM, Tim Roberts wrote:
    > Piotr Dobrogost <> wrote:
    >>
    >> Attribute access syntax being very concise is very often preferred
    >> to dict's interface.

    >
    > It is not "very concise". It is slightly more concise.
    >
    > x = obj.value1
    > x = dct['value1']
    >
    > You have saved 3 keystrokes. That is not a significant enough savings to
    > create new syntax. Remember the Python philosophy that there ought to be
    > one way to do it.


    That should be "one obvious way".

    On my keyboard, at least, those are an important three keystrokes! ;)

    To be clear, I am

    -1

    on the new syntax.

    --
    ~Ethan~
     
    Ethan Furman, Dec 4, 2013
    #12
  13. Piotr Dobrogost

    rusi Guest

    Re: Why is there no natural syntax for accessing attributes withnames not being valid identifiers?

    On Wednesday, December 4, 2013 2:27:28 PM UTC+5:30, Ian wrote:
    > On Tue, Dec 3, 2013 at 11:31 PM, rusi wrote:
    > > Its a more fundamental problem than that:
    > > It emerges from the OP's second post) that he wants '-' in the attributes.
    > > Is that all?
    > >
    > > Where does this syntax-enlargement stop? Spaces? Newlines?

    >
    > At non-strings.
    >
    > >>> setattr(foo, 21+21, 42)

    > Traceback (most recent call last):
    > File "<stdin>", line 1, in <module>
    > TypeError: attribute name must be string, not 'int'


    Not sure what's your point.

    OP wants attribute identifiers like outer_fieldset-inner_fieldset-third_field.
    Say I have a python expression:
    obj.outer_fieldset-inner_fieldset-third_field

    It can (in the proposed extension) be parsed as above, or as:
    obj.outer_fieldset - inner_fieldset-third_field
    the first hyphen being minus and the second being part of the identifier.

    How do we decide which '-' are valid identifier components -- hyphens
    and which minus-signs?

    So to state my point differently:
    The grammar of python is well-defined
    It has a 'sub-grammar' of strings that is completely* free-for-all ie just
    about anything can be put into a string literal.
    The border between the orderly and the wild world are the quote-marks.
    Remove that border and you get complete grammatical chaos.
    [Maybe I should have qualified my reference to 'spaces'.
    Algol-68 allowed spaces in identifiers (for readability!!)
    The result was chaos]

    I used the spaces case to indicate the limit of chaos. Other characters (that
    already have uses) are just as problematic.

    * Oh well there are some restrictions like quotes need to be escaped, no
    newlines etc etc -- minor enough to be ignored.
     
    rusi, Dec 4, 2013
    #13
  14. Re: Why is there no natural syntax for accessing attributes withnames not being valid identifiers?

    Op 04-12-13 11:09, rusi schreef:
    > On Wednesday, December 4, 2013 2:27:28 PM UTC+5:30, Ian wrote:
    >> On Tue, Dec 3, 2013 at 11:31 PM, rusi wrote:
    >>> Its a more fundamental problem than that:
    >>> It emerges from the OP's second post) that he wants '-' in the attributes.
    >>> Is that all?
    >>>
    >>> Where does this syntax-enlargement stop? Spaces? Newlines?

    >>
    >> At non-strings.
    >>
    >>>>> setattr(foo, 21+21, 42)

    >> Traceback (most recent call last):
    >> File "<stdin>", line 1, in <module>
    >> TypeError: attribute name must be string, not 'int'

    >
    > Not sure what's your point.
    >
    > OP wants attribute identifiers like outer_fieldset-inner_fieldset-third_field.
    > Say I have a python expression:
    > obj.outer_fieldset-inner_fieldset-third_field
    >
    > It can (in the proposed extension) be parsed as above, or as:
    > obj.outer_fieldset - inner_fieldset-third_field
    > the first hyphen being minus and the second being part of the identifier.
    >
    > How do we decide which '-' are valid identifier components -- hyphens
    > and which minus-signs?
    >
    > So to state my point differently:
    > The grammar of python is well-defined
    > It has a 'sub-grammar' of strings that is completely* free-for-all ie just
    > about anything can be put into a string literal.
    > The border between the orderly and the wild world are the quote-marks.
    > Remove that border and you get complete grammatical chaos.
    > [Maybe I should have qualified my reference to 'spaces'.
    > Algol-68 allowed spaces in identifiers (for readability!!)
    > The result was chaos]
    >
    > I used the spaces case to indicate the limit of chaos. Other characters (that
    > already have uses) are just as problematic.


    I don't agree with the latter. As it is now python can make the
    distinction between

    from A import B and fromAimportB.

    I see no a priori reason why this should be limited to letters. A
    language designer might choose to allow a bigger set of characters
    in identifiers like '-', '+' and others. In that case a-b would be
    an identifier and a - b would be the operation. Just as in python
    fromAimportB is an identifier and from A import B is an import
    statement.

    --
    Antoon Pardon
     
    Antoon Pardon, Dec 4, 2013
    #14
  15. Piotr Dobrogost

    Tim Chase Guest

    Re: Why is there no natural syntax for accessing attributes withnames not being valid identifiers?

    On 2013-12-04 21:33, Chris Angelico wrote:
    > I don't think so. What the OP asked for was:
    >
    > my_object.'valid-attribute-name-but-not-valid-identifier'
    >
    > Or describing it another way: A literal string instead of a token.
    > This is conceivable, at least, but I don't think it gives any
    > advantage over a dictionary.


    In both cases (attribute-access-as-dict-functionality and
    attribute-access-as-avoiding-setattr), forcing a literal actually
    diminishes Python's power. I like the ability to do

    a[key.strip().lower()] = some_value
    setattr(thing, key.strip().lower(), some_value)

    which can't be done (?) with mere literal notation. What would they
    look like?

    a.(key.strip().lower()) = some_value

    (note that "key.strip().lower()" not actually a "literal" that
    ast.literal_eval would accept). That's pretty ugly, IMHO :)

    -tkc
     
    Tim Chase, Dec 4, 2013
    #15
  16. Piotr Dobrogost

    rusi Guest

    Re: Why is there no natural syntax for accessing attributes withnames not being valid identifiers?

    On Wednesday, December 4, 2013 4:03:14 PM UTC+5:30, Chris Angelico wrote:
    > On Wed, Dec 4, 2013 at 9:09 PM, rusi wrote:
    > > OP wants attribute identifiers like outer_fieldset-inner_fieldset-third_field.
    > > Say I have a python expression:
    > > obj.outer_fieldset-inner_fieldset-third_field

    >
    > I don't think so. What the OP asked for was:
    >
    > my_object.'valid-attribute-name-but-not-valid-identifier'
    >
    > Or describing it another way: A literal string instead of a token.


    This is just pushing the issue one remove away.
    Firstly a literal string is very much a token -- lexically.
    Now consider the syntax as defined by the grammar.

    Let Ident = Set of strings* that are valid python identifiers --
    something like [a-zA-Z][a-zA-Z0-9]*

    Let Exp = Set to strings* that are python expressions

    * Note that I am using string from the language implementers pov not language
    user ie the python identifier var is the implementers string "var" whereas
    the python string literal "var" is the implementer's string "\"var\""

    Now clearly Ident is a proper subset of Exp.

    Now what is the proposal?
    You want to extend the syntactically allowable a.b set.
    If the b's can be any arbitrary expression we can have
    var.fld(1,2) with the grammatical ambiguity that this can be
    (var.fld)(1,2) -- the usual interpretation
    Or
    var.(fld(1,2)) -- the new interpretation -- ie a computed field name.

    OTOH if you say superset of Ident but subset of Exp, then we have to determine
    what this new limbo set is to be. ie what is the grammatical category of
    'what-follows-a-dot' ??

    Some other-language notes:
    1. In C there is one case somewhat like this:
    #include "string"
    the "string" cannot be an arbitrary expression as the rest of C. But then this
    is not really C but the C preprocessor

    2. In lisp the Ident set is way more permissive than in most languages --
    allowing operators etc that would be delimiters in most languages.
    If one wants to go even beyond that and include say spaces and parenthesis --
    almost the only delimiters that lisp has -- one must write |ident with spaces|
    ie for identifiers the bars behave somewhat like strings' quote marks.
    Because the semantics of identifiers and strings are different -- the lexical
    structures need to reflect that difference -- so you cannot replace the bars
    by quotes.
     
    rusi, Dec 4, 2013
    #16
  17. Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?

    rusi writes:
    > On Wednesday, December 4, 2013 2:27:28 PM UTC+5:30, Ian wrote:
    > > On Tue, Dec 3, 2013 at 11:31 PM, rusi wrote:
    > > > Its a more fundamental problem than that:
    > > > It emerges from the OP's second post) that he wants '-' in the
    > > > attributes. Is that all?
    > > >
    > > > Where does this syntax-enlargement stop? Spaces? Newlines?

    > >
    > > At non-strings.
    > >
    > > >>> setattr(foo, 21+21, 42)

    > > Traceback (most recent call last):
    > > File "<stdin>", line 1, in <module>
    > > TypeError: attribute name must be string, not 'int'

    >
    > Not sure what's your point.
    >
    > OP wants attribute identifiers like
    > outer_fieldset-inner_fieldset-third_field.
    > Say I have a python expression:
    > obj.outer_fieldset-inner_fieldset-third_field
    >
    > It can (in the proposed extension) be parsed as above, or as:
    > obj.outer_fieldset - inner_fieldset-third_field
    > the first hyphen being minus and the second being part of the
    > identifier.
    >
    > How do we decide which '-' are valid identifier components --
    > hyphens and which minus-signs?


    I think the OP might be after the JavaScript mechanism where an
    attribute name can be any string, the indexing brackets are always
    available, and the dot notation is available when the attribute name
    looks like a simple identifier. That could be made to work. (I'm not
    saying should, or should not. Just that it seems technically simple.)

    Hm. Can't specific classes be made to behave this way even now by
    implementing suitable underscored methods?
     
    Jussi Piitulainen, Dec 4, 2013
    #17
  18. Re: Why is there no natural syntax for accessing attributes withnames not being valid identifiers?

    On Wed, Dec 4, 2013 at 10:30 PM, Jussi Piitulainen
    <> wrote:
    > Hm. Can't specific classes be made to behave this way even now by
    > implementing suitable underscored methods?


    Yup. Definitely possible. I don't think it'd be a good idea, though,
    not without somehow changing every dict method into a stand-alone
    function.

    ChrisA
     
    Chris Angelico, Dec 4, 2013
    #18
  19. Piotr Dobrogost

    rusi Guest

    Re: Why is there no natural syntax for accessing attributes withnames not being valid identifiers?

    On Wednesday, December 4, 2013 3:59:06 PM UTC+5:30, Antoon Pardon wrote:
    > Op 04-12-13 11:09, rusi schreef:
    > > I used the spaces case to indicate the limit of chaos.
    > > Other characters (that
    > > already have uses) are just as problematic.

    >
    > I don't agree with the latter. As it is now python can make the
    > distinction between
    >
    > from A import B and fromAimportB.
    >
    > I see no a priori reason why this should be limited to letters. A
    > language designer might choose to allow a bigger set of characters
    > in identifiers like '-', '+' and others. In that case a-b would be
    > an identifier and a - b would be the operation. Just as in python
    > fromAimportB is an identifier and from A import B is an import
    > statement.


    Im not sure what you are saying.
    Sure a language designer can design a language differently from python.
    I mentioned lisp. Cobol is another behaving exactly as you describe.

    My point is that when you do (something like) that, you will need to change the
    lexical and grammatical structure of the language. And this will make
    for rather far-reaching changes ALL OVER the language not just in what-follows-dot.

    IOW: I dont agree that we have a disagreement :)
     
    rusi, Dec 4, 2013
    #19
  20. Re: Why is there no natural syntax for accessing attributes withnames not being valid identifiers?

    Op 04-12-13 13:01, rusi schreef:
    > On Wednesday, December 4, 2013 3:59:06 PM UTC+5:30, Antoon Pardon wrote:
    >> Op 04-12-13 11:09, rusi schreef:
    >>> I used the spaces case to indicate the limit of chaos.
    >>> Other characters (that
    >>> already have uses) are just as problematic.

    >>
    >> I don't agree with the latter. As it is now python can make the
    >> distinction between
    >>
    >> from A import B and fromAimportB.
    >>
    >> I see no a priori reason why this should be limited to letters. A
    >> language designer might choose to allow a bigger set of characters
    >> in identifiers like '-', '+' and others. In that case a-b would be
    >> an identifier and a - b would be the operation. Just as in python
    >> fromAimportB is an identifier and from A import B is an import
    >> statement.

    >
    > Im not sure what you are saying.
    > Sure a language designer can design a language differently from python.
    > I mentioned lisp. Cobol is another behaving exactly as you describe.
    >
    > My point is that when you do (something like) that, you will need to change the
    > lexical and grammatical structure of the language. And this will make
    > for rather far-reaching changes ALL OVER the language not just in what-follows-dot.


    No you don't need to change the lexical and grammatical structure of
    the language. Changing the characters allowed in identifiers, is not a
    change in lexical structure. The only difference in lexical structuring
    would be that '-', '>=' and other similars symbols would have to be
    treated like keyword like 'from', 'as' etc instead of being recognizable
    by just being present.

    And the grammatical structure of the language wouldn't change at all.
    Sure a-b would now be an identifier and not an operation but that is
    of no concern for the parser.

    People would have to be careful to insert spaces around operators
    and that might make the language somewhat error prone but that doesn't
    mean the syntactical structure is different.

    --
    Antoon Pardon
     
    Antoon Pardon, Dec 4, 2013
    #20
    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. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,263
    Smokey Grindel
    Dec 2, 2006
  2. Replies:
    1
    Views:
    370
    Roedy Green
    Apr 22, 2008
  3. Laszlo Nagy

    Generating valid identifiers

    Laszlo Nagy, Jul 26, 2012, in forum: Python
    Replies:
    8
    Views:
    296
    Laszlo Nagy
    Jul 27, 2012
  4. Arnaud Delobelle

    Re: Generating valid identifiers

    Arnaud Delobelle, Jul 26, 2012, in forum: Python
    Replies:
    0
    Views:
    208
    Arnaud Delobelle
    Jul 26, 2012
  5. Terry Reedy

    Re: Generating valid identifiers

    Terry Reedy, Jul 26, 2012, in forum: Python
    Replies:
    0
    Views:
    210
    Terry Reedy
    Jul 26, 2012
Loading...

Share This Page