Why can function definitions only use identifiers, and not attributereferences or any other primarie

Discussion in 'Python' started by Jeremy Banks, Apr 23, 2009.

  1. Jeremy Banks

    Jeremy Banks Guest

    Hi. I'm sure there've been debates about this before, but I can't seem
    to figure out what to search for to pull them up, so I'm asking here.

    It seems to me that a lot of things could be made much easier if you
    could use primaries other than basic identifiers for the target of
    function definitions. For example, if attribute references were
    allowed I'd be able to do:

    def foo.bar():
    return("I'm a method!")

    If we wanted to get even more liberal (which I don't see as a bad
    thing, but I could see being found more objectionable by some), we
    could allow the use of anything that's a valid assignment target. For
    example:

    def foo["bar']():
    return("I'm a function referenced in a mapping object!")


    In this case I could see there being a problem in that there's nothing
    to get the function's __name__ from, but that doesn't apply for the
    first example.

    Many uses of this may not be Pythonic, but I'm sure there are many
    that are. It just feels like an arbitrary restriction, preventing
    users from doing something that may be useful.

    Any feedback or direction to previous discussion on the subject would
    be appreciated. Thanks!
     
    Jeremy Banks, Apr 23, 2009
    #1
    1. Advertising

  2. Jeremy Banks

    Gary Herron Guest

    Re: Why can function definitions only use identifiers,and not attribute references or any other primaries?

    Jeremy Banks wrote:
    > Hi. I'm sure there've been debates about this before, but I can't seem
    > to figure out what to search for to pull them up, so I'm asking here.
    >
    > It seems to me that a lot of things could be made much easier if you
    > could use primaries other than basic identifiers for the target of
    > function definitions. For example, if attribute references were
    > allowed I'd be able to do:
    >
    > def foo.bar():
    > return("I'm a method!")
    >


    There's no need for a specific addition to the syntax to do this.

    Try this:

    def foo_bar():
    return(...)
    foo.bar = foo_bar

    > If we wanted to get even more liberal (which I don't see as a bad
    > thing, but I could see being found more objectionable by some), we
    > could allow the use of anything that's a valid assignment target. For
    > example:
    >
    > def foo["bar']():
    > return("I'm a function referenced in a mapping object!")
    >


    and this:

    def foo_bar():
    return(...)
    foo["bar"] = foo_bar



    >
    > In this case I could see there being a problem in that there's nothing
    > to get the function's __name__ from, but that doesn't apply for the
    > first example.
    >


    Not sure what you mean here.


    > Many uses of this may not be Pythonic, but I'm sure there are many
    > that are. It just feels like an arbitrary restriction, preventing
    > users from doing something that may be useful.
    >
    > Any feedback or direction to previous discussion on the subject would
    > be appreciated. Thanks!
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >
     
    Gary Herron, Apr 23, 2009
    #2
    1. Advertising

  3. Re: Why can function definitions only use identifiers, and not attribute references or any other primaries?

    Jeremy Banks was kind enough to say:

    > Hi. I'm sure there've been debates about this before, but I can't seem
    > to figure out what to search for to pull them up, so I'm asking here.


    I'm not exactly sure what you mean... if you want to add functions to
    another fuction, just do it this way:

    def foo():
    return "i'm the main function."

    foo.bar = lambda: "i'm the bar attr"

    print foo()
    print foo.bar()

    > def foo.bar():
    > return("I'm a method!")


    So you'd just like some "syntactic sugar" to let function declarations to
    be "shorter"?

    I think this wouldn't make the language that clear. In order to accomplish
    what you want, you could just use a class and the __call__ method for the
    "main" function.

    I think that what you really mean is that you would like an "improved
    lambda" or "different def". E.g., that could you write anonymous functions
    ( or ruby-like code blocks ) in a different way. Something like this:

    d["func"] = def pippo(a, b, c):
    ...
    ...
    ...

    I suppose the reason behind this is that it's not really needed. There're
    plenty of ways to do this sort of things in python; if you just declare
    methods in a class you can just use the plain def in order to achieve this,
    and you can inherit from your container and specialize some methods in
    order to achieve results which are similar to those you want.



    --
    Alan Franzoni <>
    -
    Remove .xyzz from my email in order to contact me.
    -
    GPG Key Fingerprint:
    5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E
     
    Alan Franzoni, Apr 23, 2009
    #3
  4. Jeremy Banks

    Jeremy Banks Guest

    Re: Why can function definitions only use identifiers, and notattribute references or any other primaries?

    Thanks for your comments.

    On Thu, Apr 23, 2009 at 11:52, Gary Herron <> wrote:
    > > [...]

    >
    > There's no need for a specific addition to the syntax to do this.
    >
    > Try this:
    >
    >   def foo_bar():
    >       return(...)
    >   foo.bar = foo_bar
    >
    >> [...]

    >
    > and this:
    >
    >   def foo_bar():
    >       return(...)
    >   foo["bar"] = foo_bar
    >


    I understand that this is possible now, but I just don't see why it's
    necessary to do it at all.

    >> In this case I could see there being a problem in that there's nothing
    >> to get the function's __name__ from, but that doesn't apply for the
    >> first example.
    >>

    >
    > Not sure what you mean here.


    >>> def foo(): pass
    ...
    >>> bar = foo
    >>> bar.__name__
    'foo'
    >>>

    If I defined foo.bar it would know that the method name was "bar", but
    if I defined foo["bar"] there's be no clear identifier to use for the
    function's name. I don't see this as a great problem, since anonymous
    functions already exist, but I thought it was worth acknowledging.

    To be clear, I don't see this as a serious fault in the language, but
    as an unnecessary restriction that makes code a little less direct
    than it could be.
     
    Jeremy Banks, Apr 23, 2009
    #4
  5. Jeremy Banks

    Gary Herron Guest

    Re: Why can function definitions only use identifiers,and not attribute references or any other primaries?

    Jeremy Banks wrote:
    > Thanks for your comments.
    >
    > On Thu, Apr 23, 2009 at 11:52, Gary Herron <> wrote:
    >
    >>> [...]
    >>>

    >> There's no need for a specific addition to the syntax to do this.
    >>
    >> Try this:
    >>
    >> def foo_bar():
    >> return(...)
    >> foo.bar = foo_bar
    >>
    >>
    >>> [...]
    >>>

    >> and this:
    >>
    >> def foo_bar():
    >> return(...)
    >> foo["bar"] = foo_bar
    >>
    >>

    >
    > I understand that this is possible now, but I just don't see why it's
    > necessary to do it at all.
    >
    >
    >>> In this case I could see there being a problem in that there's nothing
    >>> to get the function's __name__ from, but that doesn't apply for the
    >>> first example.
    >>>
    >>>

    >> Not sure what you mean here.
    >>

    >
    > >>> def foo(): pass
    > ...
    > >>> bar = foo
    > >>> bar.__name__
    > 'foo'
    > >>>
    >
    > If I defined foo.bar it would know that the method name was "bar", but
    > if I defined foo["bar"] there's be no clear identifier to use for the
    > function's name. I don't see this as a great problem, since anonymous
    > functions already exist, but I thought it was worth acknowledging.
    >
    > To be clear, I don't see this as a serious fault in the language, but
    > as an unnecessary restriction that makes code a little less direct
    > than it could be.
    >



    Things like your suggestion are called "syntactic-sugar" -- syntax that
    adds a convenience, but *no* new functionality. Python has plenty of
    "syntactic-sugar"s, and more will be added in the future. To make an
    argument for such an addition, one would have to describe some
    compelling (and general) use cases in a well-argued PEP. You're welcome
    to try, but be forewarned, most PEP's (especially syntax changing PEPs)
    don't fly far.


    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >
     
    Gary Herron, Apr 23, 2009
    #5
  6. Jeremy Banks

    Jeremy Banks Guest

    Re: Why can function definitions only use identifiers, and notattribute references or any other primaries?

    > Things like your suggestion are called "syntactic-sugar"  -- syntax that
    > adds a convenience, but *no* new functionality.  Python has plenty of
    > "syntactic-sugar"s, and more will be added in the future.  To make an
    > argument for such an addition, one would have to describe some compelling
    > (and general) use cases in a well-argued PEP.  You're welcome to try, but be
    > forewarned, most PEP's (especially syntax changing PEPs) don't fly far.


    Thank you very much for the feedback. I might throw something at
    Python-Ideas if I think I can come up with an adequate justification
    and don't come accross a previous similar propsition (though if I do
    miss it I'm sure it will be pointed out to me fairly quickly). I fully
    appreciate the small chance of success, but it certainly couldn't hurt
    to give it a try.
     
    Jeremy Banks, Apr 23, 2009
    #6
  7. Jeremy Banks

    John Krukoff Guest

    Re: Why can function definitions only use identifiers, and notattribute references or any other primaries?

    On Thu, 2009-04-23 at 12:26 -0300, Jeremy Banks wrote:
    > > Things like your suggestion are called "syntactic-sugar" -- syntax that
    > > adds a convenience, but *no* new functionality. Python has plenty of
    > > "syntactic-sugar"s, and more will be added in the future. To make an
    > > argument for such an addition, one would have to describe some compelling
    > > (and general) use cases in a well-argued PEP. You're welcome to try, but be
    > > forewarned, most PEP's (especially syntax changing PEPs) don't fly far.

    >
    > Thank you very much for the feedback. I might throw something at
    > Python-Ideas if I think I can come up with an adequate justification
    > and don't come accross a previous similar propsition (though if I do
    > miss it I'm sure it will be pointed out to me fairly quickly). I fully
    > appreciate the small chance of success, but it certainly couldn't hurt
    > to give it a try.
    > --
    > http://mail.python.org/mailman/listinfo/python-list


    You probably want to be searching for multi-line lambda to find the past
    decade or so of this argument, as that's where most people who argued
    for this came from. But, if you'd just like a bit of discouragement,
    here's GvR arguing that there's just no good way to mix statements and
    expressions in python:
    http://www.artima.com/weblogs/viewpost.jsp?thread=147358

    --
    John Krukoff <>
    Land Title Guarantee Company
     
    John Krukoff, Apr 23, 2009
    #7
  8. Jeremy Banks

    Jeremy Banks Guest

    Re: Why can function definitions only use identifiers, and notattribute references or any other primaries?

    On Thu, Apr 23, 2009 at 13:03, John Krukoff <> wrote:
    > You probably want to be searching for multi-line lambda to find the past
    > decade or so of this argument, as that's where most people who argued
    > for this came from. But, if you'd just like a bit of discouragement,
    > here's GvR arguing that there's just no good way to mix statements and
    > expressions in python:
    > http://www.artima.com/weblogs/viewpost.jsp?thread=147358


    I've read those discussion before, but somehow never made the
    connection between those and this. I'll give that article a read, it
    probably details exactly the perspective I'm looking for. Thank you!
     
    Jeremy Banks, Apr 23, 2009
    #8
  9. Re: Why can function definitions only use identifiers, and not attributereferences or any other primaries?

    Jeremy Banks wrote:

    > I've read those discussion before, but somehow never made the
    > connection between those and this. I'll give that article a read, it
    > probably details exactly the perspective I'm looking for. Thank you!


    You could also read this:

    http://unlimitednovelty.com/2009/03/indentation-sensitivity-post-mortem.html

    The author is writing a language for the Erlang VM inspired by Python
    and Ruby. He had some trouble (at the grammar level) in keeping both
    "indentation working like in python" (dear to Guido and many of us) and
    "anonymous blocks" (dear to functional languages).
    So he got braces and was happy :)
     
    Marco Mariani, Apr 23, 2009
    #9
  10. Jeremy Banks

    Terry Reedy Guest

    Re: Why can function definitions only use identifiers,and not attribute references or any other primaries?

    Jeremy Banks wrote:
    > Hi. I'm sure there've been debates about this before, but I can't seem
    > to figure out what to search for to pull them up, so I'm asking here.
    >
    > It seems to me that a lot of things could be made much easier if you
    > could use primaries other than basic identifiers for the target of
    > function definitions. For example, if attribute references were
    > allowed I'd be able to do:
    >
    > def foo.bar():
    > return("I'm a method!")
    >
    > If we wanted to get even more liberal (which I don't see as a bad
    > thing, but I could see being found more objectionable by some), we
    > could allow the use of anything that's a valid assignment target. For
    > example:
    >
    > def foo["bar']():
    > return("I'm a function referenced in a mapping object!")
    >
    >
    > In this case I could see there being a problem in that there's nothing
    > to get the function's __name__ from, but that doesn't apply for the
    > first example.
    >
    > Many uses of this may not be Pythonic, but I'm sure there are many
    > that are. It just feels like an arbitrary restriction, preventing
    > users from doing something that may be useful.
    >
    > Any feedback or direction to previous discussion on the subject would
    > be appreciated. Thanks!


    There has been some discussion on py-dev and perhaps python-ideas, but I
    cannot remember any specifics as to why Guido was unpersuaded/negative.

    If one regards

    def name(params): body

    as syntantic sugar for a (somewhat hypothetical) assignment statement

    name = make_func('name', "params", "body")

    (there is a function_maker function in the new module, though with a
    more complicated interface), then generalizing the target would seem
    reasonable. The function's __name__ does not seem like an issue:
    "foo.bar" and "foo['bar']" both direct one to the proper definition code.

    Counter-argument: class and import are also implied assignments, and
    they also subject to the same limitation.

    Counter-counter-argument: a) doing actual assignments with name =
    type('name', bases, dict) and name = __import__('name',...) is more
    feasible, and b) the need for qualified names is less for class and
    probably for import and c) the restriction *could* also be lifted for
    those two statements also.

    For some, a plus for this proposal is that is directly binds the
    function to the target without introducing a spurious name into the
    local scope. It would thus reduce the perceived need for and hence
    pressure for generalized function expressions. I believe Guido would
    consider this last point a plus if so stated.

    I do not believe this recurring idea has been the subject of a PEP. If
    not, writing one might be a service, should you choose to do so, even if
    rejected.

    Terry Jan Reedy
     
    Terry Reedy, Apr 23, 2009
    #10
  11. Jeremy Banks

    Jeremy Banks Guest

    Re: Why can function definitions only use identifiers, and notattribute references or any other primaries?

    On Apr 23, 5:23 pm, Terry Reedy <> wrote:
    > Jeremy Banks wrote:
    > > Hi. I'm sure there've been debates about this before, but I can't seem
    > > to figure out what to search for to pull them up, so I'm asking here.

    >
    > > It seems to me that a lot of things could be made much easier if you
    > > could use primaries other than basic identifiers for the target of
    > > function definitions. For example, if attribute references were
    > > allowed I'd be able to do:

    >
    > >     def foo.bar():
    > >         return("I'm a method!")

    >
    > > If we wanted to get even more liberal (which I don't see as a bad
    > > thing, but I could see being found more objectionable by some), we
    > > could allow the use of anything that's a valid assignment target. For
    > > example:

    >
    > >     def foo["bar']():
    > >         return("I'm a function referenced in a mapping object!")

    >
    > > In this case I could see there being a problem in that there's nothing
    > > to get the function's __name__ from, but that doesn't apply for the
    > > first example.

    >
    > > Many uses of this may not be Pythonic, but I'm sure there are many
    > > that are. It just feels like an arbitrary restriction, preventing
    > > users from doing something that may be useful.

    >
    > > Any feedback or direction to previous discussion on the subject would
    > > be appreciated. Thanks!

    >
    > There has been some discussion on py-dev and perhaps python-ideas, but I
    > cannot remember any specifics as to why Guido was unpersuaded/negative.
    >
    > If one regards
    >
    > def name(params): body
    >
    > as syntantic sugar for a (somewhat hypothetical) assignment statement
    >
    > name = make_func('name', "params", "body")
    >
    > (there is a function_maker function in the new module, though with a
    > more complicated interface), then generalizing the target would seem
    > reasonable.  The function's __name__ does not seem like an issue:
    > "foo.bar" and "foo['bar']" both direct one to the proper definition code.
    >
    > Counter-argument: class and import are also implied assignments, and
    > they also subject to the same limitation.
    >
    > Counter-counter-argument: a) doing actual assignments with name =
    > type('name', bases, dict) and name = __import__('name',...) is more
    > feasible, and b) the need for qualified names is less for class and
    > probably for import and c) the restriction *could* also be lifted for
    > those two statements also.
    >
    > For some, a plus for this proposal is that is directly binds the
    > function to the target without introducing a spurious name into the
    > local scope.  It would thus reduce the perceived need for and hence
    > pressure for generalized function expressions.  I believe Guido would
    > consider this last point a plus if so stated.
    >
    > I do not believe this recurring idea has been the subject of a PEP.  If
    > not, writing one might be a service, should you choose to do so, even if
    > rejected.
    >
    > Terry Jan Reedy


    Interesting, thank you very much for your suggestions. I'll try to put
    together a draft.
     
    Jeremy Banks, Apr 23, 2009
    #11
  12. Re: Why can function definitions only use identifiers, and not attributereferences or any other primaries?

    Scott David Daniels wrote:

    > I am afraid it will make it too easy to define functions in other
    > modules remotely, a tempting sharp stick to poke your eye out with.


    It's not very hard at the moment, and I don't see lots of eyes flying
    by. I don't know about Ruby where monkeypatching seems to be common
    practice, though.

    > Imagine debugging a pile of code that includes a module with:
    > import random
    > def random.random():
    > return .42


    No need to imagine. I can do the same, one line shorter:

    >>> import random
    >>> random.random = lambda: .42
     
    Marco Mariani, Apr 24, 2009
    #12
  13. Re: Why can function definitions only use identifiers, and notattribute references or any other primaries?

    On Thu, 23 Apr 2009 10:48:57 -0700, Scott David Daniels wrote:

    > I am afraid it will make it too easy to define functions in other
    > modules remotely, a tempting sharp stick to poke your eye out with.


    It's not terribly difficult to do so already:

    >>> def spam():

    .... return "spam spam spam"
    ....
    >>> import math
    >>> math.spam = spam
    >>> math.spam()

    'spam spam spam'


    > Note
    > also, that it will not be so easy to find the definition of a function
    > provided as a argument to a failing function. Right now you can get the
    > function name and (with a bit more effort) its module. Imagine debugging
    > a pile of code that includes a module with:
    > import random
    > def random.random():
    > return .42


    Easy-peasy.

    >>> import random
    >>> random.random = lambda: 0.42
    >>>
    >>> random.random()

    0.41999999999999998
    >>> random.random.__name__

    '<lambda>'
    >>> random.random.__module__

    '__main__'


    Sure, if somebody wants to really work at it, they could create a
    function that looks exactly like the original, including claiming to come
    from the same module, but that's possible now anyway.

    I don't think the proposed syntax is useful because it doesn't actually
    gain us anything. Currently, you add a function to a class at class
    creation time:

    class Spam(object):
    def spam(self):
    return "spam spam spam"

    Adding functions to a class after the class already exists is rare, but
    not unheard of. Currently you can do this:

    def ham(self):
    return "ham is not spam"

    Spam.ham = ham
    del ham # if you can be bothered


    And you're done. The proposal gives us this:

    class Spam(object):
    pass # Need to have a class before you can add methods to it.

    def Spam.spam(self):
    return "spam spam spam"

    def Spam.ham(self):
    return "ham is not spam"



    Whatever benefit there might be from doing this, it's so minor I don't
    think it's worth the effort to implement it. Unlike decorators, I'd be
    surprised if it opens the door to bigger and better things.



    --
    Steven
     
    Steven D'Aprano, Apr 24, 2009
    #13
    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. Fred Ma
    Replies:
    8
    Views:
    349
    Fred Ma
    Apr 13, 2004
  2. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    999
    Mark Rae
    Dec 21, 2006
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,271
    Smokey Grindel
    Dec 2, 2006
  4. Replies:
    1
    Views:
    370
    Roedy Green
    Apr 22, 2008
  5. Giacomo Boffi
    Replies:
    4
    Views:
    1,813
    Jean-Michel Pichavant
    Apr 19, 2010
Loading...

Share This Page