Would Anonymous Functions Help in Learning Programming/Python?

Discussion in 'Python' started by Cristian, Sep 21, 2007.

  1. Cristian

    Cristian Guest

    A friend of mine is an engineer and he's been needing to do more and
    more programming as he goes on with is career. I convinced him to
    learn Python instead of Perl and he's really started to like it. He
    usually comes to me when he can't accomplish a task with his current
    knowledge and I introduce him to a new feature in Python. FYIW, he
    thought List Comprehensions were freakin' awesome. He's started
    writing his own personal scripts for tasks like web scraping. So, from
    personal experience, Python truly is a great first language to learn.

    Although his learning experience has gone mostly smoothly, he's hit a
    lot of speed bumps with functions. Specifically, he's having trouble
    thinking of functions as first order data (don't worry, I haven't
    confused him with such terminology yet). He had a little trouble
    understanding that you can pass functions as arguments to other
    functions (e.g., passing a key to the list.sort method). He also had a
    little trouble grasping functions within other functions. Last but not
    least, he had trouble grasping methods in class declarations,
    especially the required self as the first argument (I'm sure he wasn't
    the first).

    Now, my friend's a smart guy so I know it isn't any lack of brain
    cells on his part. I still remember many students in my CS classes
    having trouble grasping the very same concept. And, after we finally
    get a hold of first order functions, we appreciate its incorporation
    into languages. It would be a shame if my friend just learns the
    motions and never incorporates first order functions into his
    programs. I began to wonder if there was anything Python could do to
    help newcomers grasp the power of first order functions or, as
    Pythonistas put it, everything is an object.

    To me, the biggest setback for new programmers is the different syntax
    Python has for creating functions. Instead of the common (and easy to
    grasp) syntax of foo = bar Python has the def foo(): syntax. So, when
    a new programmer is first introduced to functions they are immediately
    confronted with the notion that functions are "different". After all,
    they have their own special syntax. This seems to only further the
    separation newbies make between "data" and "functions" or "stuff" and
    "actions". Now, the vast majority of us learned this dichotomy when we
    first began to program, so we are ingrained to assume and even expect
    a different syntax for function declaration, but in a program like
    Python there doesn't seem to be any other reason to have it.
    Furthermore, I think it actually inhibits the learning of the
    uninitiated. We can, of course, keep the current syntax as sugar.

    To someone who's learning to program wouldn't a syntax like the
    further give them all they need and also reinforces the idea that
    functions are data just like everything else?

    my_function = function(foo, bar): pass
    an_instance_method = function(self, foo): pass
    a_method_declaration = method(self, foo): pass

    The last one is mostly my pet peeve of having Python "magically"
    create methods out of (what is essentially) a function declaration.
    When I first learned it, it felt wrong but you had to press through it
    because there was really no other way of declaring methods.

    What do you think? Have you hit this roadblock when helping others
    learn Python? Does the current syntax make you feel that functions are
    still treated as second class (get it?) citizens?
    Cristian, Sep 21, 2007
    #1
    1. Advertising

  2. Cristian

    Guest

    On Sep 21, 5:37 pm, Cristian <> wrote:
    > A friend of mine is an engineer and he's been needing to do more and
    > more programming as he goes on with is career. I convinced him to
    > learn Python instead of Perl and he's really started to like it. He
    > usually comes to me when he can't accomplish a task with his current
    > knowledge and I introduce him to a new feature in Python. FYIW, he
    > thought List Comprehensions were freakin' awesome. He's started
    > writing his own personal scripts for tasks like web scraping. So, from
    > personal experience, Python truly is a great first language to learn.
    >
    > Although his learning experience has gone mostly smoothly, he's hit a
    > lot of speed bumps with functions. Specifically, he's having trouble
    > thinking of functions as first order data (don't worry, I haven't
    > confused him with such terminology yet). He had a little trouble
    > understanding that you can pass functions as arguments to other
    > functions (e.g., passing a key to the list.sort method). He also had a
    > little trouble grasping functions within other functions. Last but not
    > least, he had trouble grasping methods in class declarations,
    > especially the required self as the first argument (I'm sure he wasn't
    > the first).
    >
    > Now, my friend's a smart guy so I know it isn't any lack of brain
    > cells on his part. I still remember many students in my CS classes
    > having trouble grasping the very same concept. And, after we finally
    > get a hold of first order functions, we appreciate its incorporation
    > into languages. It would be a shame if my friend just learns the
    > motions and never incorporates first order functions into his
    > programs. I began to wonder if there was anything Python could do to
    > help newcomers grasp the power of first order functions or, as
    > Pythonistas put it, everything is an object.
    >
    > To me, the biggest setback for new programmers is the different syntax
    > Python has for creating functions. Instead of the common (and easy to
    > grasp) syntax of foo = bar Python has the def foo(): syntax. So, when
    > a new programmer is first introduced to functions they are immediately
    > confronted with the notion that functions are "different". After all,
    > they have their own special syntax. This seems to only further the
    > separation newbies make between "data" and "functions" or "stuff" and
    > "actions". Now, the vast majority of us learned this dichotomy when we
    > first began to program, so we are ingrained to assume and even expect
    > a different syntax for function declaration, but in a program like
    > Python there doesn't seem to be any other reason to have it.
    > Furthermore, I think it actually inhibits the learning of the
    > uninitiated. We can, of course, keep the current syntax as sugar.
    >
    > To someone who's learning to program wouldn't a syntax like the
    > further give them all they need and also reinforces the idea that
    > functions are data just like everything else?
    >
    > my_function = function(foo, bar): pass
    > an_instance_method = function(self, foo): pass
    > a_method_declaration = method(self, foo): pass
    >
    > The last one is mostly my pet peeve of having Python "magically"
    > create methods out of (what is essentially) a function declaration.
    > When I first learned it, it felt wrong but you had to press through it
    > because there was really no other way of declaring methods.
    >
    > What do you think? Have you hit this roadblock when helping others
    > learn Python? Does the current syntax make you feel that functions are
    > still treated as second class (get it?) citizens?


    There are already anonymous functions in Python.

    lambda x, y, z: x + y + z

    is the same as:

    def _(x, y, z): return x + y + z

    As for the method stuff, check out staticmethod(). If you assign
    staticmethod(<function here>) to an object, it will be treated as a
    normal function and not as a "method."

    I have my own personal opinions about how methods should be in Python,
    but, whatever. It's weird to deal with stuff like this:

    x.y = re.match # Assign a function to an attribute of a class, but it
    doesn't work because you can't assign anything but methods!
    x.y = staticmethod(re.match) # Ugly
    , Sep 21, 2007
    #2
    1. Advertising

  3. Cristian

    Cristian Guest

    On Sep 21, 2:48 pm, wrote:
    > There are already anonymous functions in Python.
    >
    > lambda x, y, z: x + y + z
    >
    > is the same as:
    >
    > def _(x, y, z): return x + y + z
    >
    > As for the method stuff, check out staticmethod(). If you assign
    > staticmethod(<function here>) to an object, it will be treated as a
    > normal function and not as a "method."
    >
    > I have my own personal opinions about how methods should be in Python,
    > but, whatever. It's weird to deal with stuff like this:
    >
    > x.y = re.match # Assign a function to an attribute of a class, but it
    > doesn't work because you can't assign anything but methods!
    > x.y = staticmethod(re.match) # Ugly


    True, there is lambda, but that is very limited. It might be useful
    for key arguments, but not much else. It doesn't solve the teaching
    problem of "See, functions are just like any other data type. You can
    assign it to a variable." It would be a footnote if it's mentioned at
    all. My hope is to subtly reinforce the notion that functions are data
    and can be passed around. The current function declaration doesn't
    help with this. Creating a function and assigning it to a name is
    exactly what Python does, why not have it come out in the syntax? It's
    not necessary, yes, but I think it would be helpful for teaching
    purposes.

    Again, it's not necessary as much as it's more intuitive and obvious
    what's going on. This helps a beginner sort out the process from the
    syntax without taking it on faith. They can see the class declaration
    and see "I'm defining just another attribute to this class only this
    time it happens to be method".

    There is nothing functionally lacking in Python. I'm just curious if
    there's anything Python can do syntax-wise to help a person better
    grasp programming ideas and Python's inner workings.
    Cristian, Sep 21, 2007
    #3
  4. Cristian

    Guest

    On Sep 21, 6:07 pm, Cristian <> wrote:
    > On Sep 21, 2:48 pm, wrote:
    >
    >
    >
    > > There are already anonymous functions in Python.

    >
    > > lambda x, y, z: x + y + z

    >
    > > is the same as:

    >
    > > def _(x, y, z): return x + y + z

    >
    > > As for the method stuff, check out staticmethod(). If you assign
    > > staticmethod(<function here>) to an object, it will be treated as a
    > > normal function and not as a "method."

    >
    > > I have my own personal opinions about how methods should be in Python,
    > > but, whatever. It's weird to deal with stuff like this:

    >
    > > x.y = re.match # Assign a function to an attribute of a class, but it
    > > doesn't work because you can't assign anything but methods!
    > > x.y = staticmethod(re.match) # Ugly

    >
    > True, there is lambda, but that is very limited. It might be useful
    > for key arguments, but not much else. It doesn't solve the teaching
    > problem of "See, functions are just like any other data type. You can
    > assign it to a variable." It would be a footnote if it's mentioned at
    > all. My hope is to subtly reinforce the notion that functions are data
    > and can be passed around. The current function declaration doesn't
    > help with this. Creating a function and assigning it to a name is
    > exactly what Python does, why not have it come out in the syntax? It's
    > not necessary, yes, but I think it would be helpful for teaching
    > purposes.
    >
    > Again, it's not necessary as much as it's more intuitive and obvious
    > what's going on. This helps a beginner sort out the process from the
    > syntax without taking it on faith. They can see the class declaration
    > and see "I'm defining just another attribute to this class only this
    > time it happens to be method".
    >
    > There is nothing functionally lacking in Python. I'm just curious if
    > there's anything Python can do syntax-wise to help a person better
    > grasp programming ideas and Python's inner workings.


    Guido apparently doesn't like lambda; I'm not really sure why, it's
    extremely useful. There were rumors of it leaving in Python 3000, but
    thankfully there was the decision to keep them. (I have a feeling if
    they weren't kept in, a project fork would have happened or such.)
    Anyway, one of the biggest problems implementation wise is indentation
    in an expression - there is no expression currently that uses
    significant whitespace. Python draws a pretty clear line between
    expression and statement. I do agree with you however, it seems as if
    there is an arbitrary line between function definitions and normal
    variable assignment that shouldn't be there for the sake of
    consistency.

    A question: if you WERE to implement function definitions as normal
    expressions, how would you go about embedding it within an expression?

    x = map(def a:
    <line of code>
    <line of code>
    <line of code>
    , [1, 2, 3])

    It looks hideous in my opinion and lining up the , with the def is
    ugly. Not to mention currently, inside groupings, whitespace is
    ignored. How would you handle a whitespace signif. expression inside a
    grouping which by definition ignores whitespace?
    , Sep 21, 2007
    #4
  5. Cristian

    Cristian Guest

    On Sep 21, 3:22 pm, wrote:
    > On Sep 21, 6:07 pm, Cristian <> wrote:
    >
    >
    >
    > > On Sep 21, 2:48 pm, wrote:

    >
    > > > There are already anonymous functions in Python.

    >
    > > > lambda x, y, z: x + y + z

    >
    > > > is the same as:

    >
    > > > def _(x, y, z): return x + y + z

    >
    > > > As for the method stuff, check out staticmethod(). If you assign
    > > > staticmethod(<function here>) to an object, it will be treated as a
    > > > normal function and not as a "method."

    >
    > > > I have my own personal opinions about how methods should be in Python,
    > > > but, whatever. It's weird to deal with stuff like this:

    >
    > > > x.y = re.match # Assign a function to an attribute of a class, but it
    > > > doesn't work because you can't assign anything but methods!
    > > > x.y = staticmethod(re.match) # Ugly

    >
    > > True, there is lambda, but that is very limited. It might be useful
    > > for key arguments, but not much else. It doesn't solve the teaching
    > > problem of "See, functions are just like any other data type. You can
    > > assign it to a variable." It would be a footnote if it's mentioned at
    > > all. My hope is to subtly reinforce the notion that functions are data
    > > and can be passed around. The current function declaration doesn't
    > > help with this. Creating a function and assigning it to a name is
    > > exactly what Python does, why not have it come out in the syntax? It's
    > > not necessary, yes, but I think it would be helpful for teaching
    > > purposes.

    >
    > > Again, it's not necessary as much as it's more intuitive and obvious
    > > what's going on. This helps a beginner sort out the process from the
    > > syntax without taking it on faith. They can see the class declaration
    > > and see "I'm defining just another attribute to this class only this
    > > time it happens to be method".

    >
    > > There is nothing functionally lacking in Python. I'm just curious if
    > > there's anything Python can do syntax-wise to help a person better
    > > grasp programming ideas and Python's inner workings.

    >
    > Guido apparently doesn't like lambda; I'm not really sure why, it's
    > extremely useful. There were rumors of it leaving in Python 3000, but
    > thankfully there was the decision to keep them. (I have a feeling if
    > they weren't kept in, a project fork would have happened or such.)
    > Anyway, one of the biggest problems implementation wise is indentation
    > in an expression - there is no expression currently that uses
    > significant whitespace. Python draws a pretty clear line between
    > expression and statement. I do agree with you however, it seems as if
    > there is an arbitrary line between function definitions and normal
    > variable assignment that shouldn't be there for the sake of
    > consistency.
    >
    > A question: if you WERE to implement function definitions as normal
    > expressions, how would you go about embedding it within an expression?
    >
    > x = map(def a:
    > <line of code>
    > <line of code>
    > <line of code>
    > , [1, 2, 3])
    >
    > It looks hideous in my opinion and lining up the , with the def is
    > ugly. Not to mention currently, inside groupings, whitespace is
    > ignored. How would you handle a whitespace signif. expression inside a
    > grouping which by definition ignores whitespace?


    Yeah, I agree, that does look pretty ugly. Correct me if I'm wrong,
    but I thought the way Python determines a block is by the whitespace
    of the first line. So, as long as the spacing (or !tabbing!) is
    consistent from line to line the parser will know it's part of the
    same block. From that I don't think the parser would have much trouble
    extracting the function definition from the above example. I would
    change the word "def". That's never been informative enough for me. I
    would follow Javascript and call it "function." Also, I think
    parentheses should be required.

    If there's no implementation problem, I don't see why Python shouldn't
    allow the above example, but I would certainly discourage it. Just
    like Python doesn't prevent you from writing an insanely long and
    convoluted function, Python shouldn't enforce any arbitrary length in
    anonymous functions. I think the above example should be discouraged
    as a style violation, not syntax.
    Cristian, Sep 21, 2007
    #5
  6. Cristian

    Ron Adam Guest

    Cristian wrote:
    > My hope is to subtly reinforce the notion that functions are data
    > and can be passed around. The current function declaration doesn't
    > help with this. Creating a function and assigning it to a name is
    > exactly what Python does, why not have it come out in the syntax? It's
    > not necessary, yes, but I think it would be helpful for teaching
    > purposes.


    I think key may be to discuss names and name binding with your friend. How
    a name is not the object it self, like a variable is in other languages.
    For example show him how an object can have more than one name. And discus
    how names can be bound to nearly anything, including classes and functions.


    > Again, it's not necessary as much as it's more intuitive and obvious
    > what's going on. This helps a beginner sort out the process from the
    > syntax without taking it on faith. They can see the class declaration
    > and see "I'm defining just another attribute to this class only this
    > time it happens to be method".
    >
    > There is nothing functionally lacking in Python. I'm just curious if
    > there's anything Python can do syntax-wise to help a person better
    > grasp programming ideas and Python's inner workings.


    You could also discus factory functions with him. Once he gets that a
    function can return another function, then it won't be so much of a leap
    for a function to take a function as an argument.

    Of course he'll figure out all this sooner or later anyway. You can't be
    an engineer without a fair amount of brain cells committed to processing
    abstract concepts.

    Cheers,
    Ron
    Ron Adam, Sep 21, 2007
    #6
  7. Cristian

    Ron Adam Guest

    Cristian wrote:
    > My hope is to subtly reinforce the notion that functions are data
    > and can be passed around. The current function declaration doesn't
    > help with this. Creating a function and assigning it to a name is
    > exactly what Python does, why not have it come out in the syntax? It's
    > not necessary, yes, but I think it would be helpful for teaching
    > purposes.


    I think key may be to discuss names and name binding with your friend. How
    a name is not the object it self, like a variable is in other languages.
    For example show him how an object can have more than one name. And discus
    how names can be bound to nearly anything, including classes and functions.


    > Again, it's not necessary as much as it's more intuitive and obvious
    > what's going on. This helps a beginner sort out the process from the
    > syntax without taking it on faith. They can see the class declaration
    > and see "I'm defining just another attribute to this class only this
    > time it happens to be method".
    >
    > There is nothing functionally lacking in Python. I'm just curious if
    > there's anything Python can do syntax-wise to help a person better
    > grasp programming ideas and Python's inner workings.


    You could also discus factory functions with him. Once he gets that a
    function can return another function, then it won't be so much of a leap
    for a function to take a function as an argument.

    Of course he'll figure out all this sooner or later anyway. You can't be
    an engineer without a fair amount of brain cells committed to processing
    abstract concepts.

    Cheers,
    Ron
    Ron Adam, Sep 21, 2007
    #7
  8. Cristian

    Cristian Guest

    On Sep 21, 3:44 pm, Ron Adam <> wrote:

    > I think key may be to discuss names and name binding with your friend. How
    > a name is not the object it self, like a variable is in other languages.
    > For example show him how an object can have more than one name. And discus
    > how names can be bound to nearly anything, including classes and functions.


    I could discuss name binding but it would be great if Python said this
    itself. After all, you can even bind a module with the foo = bar
    syntax by using __import__ function. If function definitions followed
    the same pattern, I think a beginner would subconsciously (maybe even
    consciously) realize that function names are just like everything
    else. Actually, this would be helpful for many people. If you come
    from a language like Java you're used to thinking of attributes and
    methods as living in different namespaces. I think a new syntax will
    encourage seasoned programmers think in a more Pythonic way.

    Python has done a very good job in easing people into programming. My
    friend doesn't come to me very often because the syntax is clear and
    simple and the builtin datatypes allow you to do so much. My goal is
    that I would never have to explain to him about name binding; that
    he'd pick it up by learning the language on his own. He's learned
    lists, dictionaries and even some OOP without me. I don't think name
    binding would be a stretch.

    > You could also discus factory functions with him. Once he gets that a
    > function can return another function, then it won't be so much of a leap
    > for a function to take a function as an argument.


    I think this isn't the most intuitive way of approaching first order
    functions. It's true that if a function can return another function
    then a function must be first order (i.e., it's just like any other
    variable), but that seems almost backwards to me. I think it would
    make more sense to have beginners _know_ that functions are like all
    other variables and can therefore be passed by other functions or
    returned by other functions. That I think would be better accomplished
    if they define functions the same way you would define other variables
    that you know can be passed and returned.
    Cristian, Sep 22, 2007
    #8
  9. Cristian

    Donn Cave Guest

    In article <>,
    Cristian <> wrote:
    ....

    > To someone who's learning to program wouldn't a syntax like the
    > further give them all they need and also reinforces the idea that
    > functions are data just like everything else?
    >
    > my_function = function(foo, bar): pass
    > an_instance_method = function(self, foo): pass
    > a_method_declaration = method(self, foo): pass


    I think one followup has already alluded to the division
    between Python `statements' and `expressions'. The `def'
    statement may create and bind a value, but since it's a
    statement and not an expression, it doesn't have any value.
    Python is not a functional programming language. It probably
    could be reinvented to eliminate statements, but ... there
    are already plenty of languages to choose from.

    If we're going there, though, I think it's obvious that
    once you have defined

    an_instance_method = function(self, foo): ...

    it should be invoked

    an_instance_method(an_instance, foo)

    which would be much less messy in nested expressions where
    the current standard OOP notation flips from right to left
    too much ...

    string.join(x.split('-'), '').lower()

    --> lower(string.join('', split(x, '-')))

    It might make for some interesting problems, but that's what
    it's about, changing things so it stays fun for everyone.
    At the same time, partial function parameter binding should
    be implemented, so you could say

    dotted = string.join('.')
    ...
    v = dotted(['comp', 'lang', 'python'])

    As you probably well know, that isn't my idea, it's a common
    functional programming language idiom.

    Donn Cave,
    Donn Cave, Sep 22, 2007
    #9
  10. Cristian wrote:
    > On Sep 21, 3:44 pm, Ron Adam <> wrote:
    >
    >
    >> I think key may be to discuss names and name binding with your friend. How
    >> a name is not the object it self, like a variable is in other languages.
    >> For example show him how an object can have more than one name. And discus
    >> how names can be bound to nearly anything, including classes and functions.
    >>

    >
    > I could discuss name binding but it would be great if Python said this
    > itself. After all, you can even bind a module with the foo = bar
    > syntax by using __import__ function. If function definitions followed
    > the same pattern, I think a beginner would subconsciously (maybe even
    > consciously) realize that function names are just like everything
    > else. Actually, this would be helpful for many people. If you come
    > from a language like Java you're used to thinking of attributes and
    > methods as living in different namespaces. I think a new syntax will
    > encourage seasoned programmers think in a more Pythonic way.
    >


    However, you still have to solve the problem of using a single-line
    construct (x = y) with a multi-line definition. That is the essential
    difference that def is designed to solve. The __import__ trick works
    because import is also a single line construct.

    The only proposal given in this thread is using consistent indentation
    within the parentheses, but parentheses are already explicitly designed
    to let you ignore the whitespace rules. To suddenly create a situation
    in which you have significant whitespace on the right side of an
    assignment statement, and *within parentheses* will break too much code,
    and make the solution unnecessarily ugly. Multi-line lambdas have been
    rejected because of this very problem, so unless you have a clean
    solution, I think your proposal falls into the category of "would be
    nice, but not in Python."

    Cheers,
    Cliff
    J. Cliff Dyer, Sep 22, 2007
    #10
  11. Cristian

    Sean Tierney Guest

    Just tell him that "functions are like all other variables and can
    therefore be passed by other functions or returned by other functions.
    "

    If your friend understands variables and functions and he can't make
    the "leap" (and assuming you're right, of course) then your friend
    doesn't understand variables and functions.

    Happy Friday.

    Sean

    On 9/21/07, Cristian <> wrote:
    > On Sep 21, 3:44 pm, Ron Adam <> wrote:
    >
    > > I think key may be to discuss names and name binding with your friend. How
    > > a name is not the object it self, like a variable is in other languages.
    > > For example show him how an object can have more than one name. And discus
    > > how names can be bound to nearly anything, including classes and functions.

    >
    > I could discuss name binding but it would be great if Python said this
    > itself. After all, you can even bind a module with the foo = bar
    > syntax by using __import__ function. If function definitions followed
    > the same pattern, I think a beginner would subconsciously (maybe even
    > consciously) realize that function names are just like everything
    > else. Actually, this would be helpful for many people. If you come
    > from a language like Java you're used to thinking of attributes and
    > methods as living in different namespaces. I think a new syntax will
    > encourage seasoned programmers think in a more Pythonic way.
    >
    > Python has done a very good job in easing people into programming. My
    > friend doesn't come to me very often because the syntax is clear and
    > simple and the builtin datatypes allow you to do so much. My goal is
    > that I would never have to explain to him about name binding; that
    > he'd pick it up by learning the language on his own. He's learned
    > lists, dictionaries and even some OOP without me. I don't think name
    > binding would be a stretch.
    >
    > > You could also discus factory functions with him. Once he gets that a
    > > function can return another function, then it won't be so much of a leap
    > > for a function to take a function as an argument.

    >
    > I think this isn't the most intuitive way of approaching first order
    > functions. It's true that if a function can return another function
    > then a function must be first order (i.e., it's just like any other
    > variable), but that seems almost backwards to me. I think it would
    > make more sense to have beginners _know_ that functions are like all


    > other variables and can therefore be passed by other functions or
    > returned by other functions. That I think would be better accomplished
    > if they define functions the same way you would define other variables
    > that you know can be passed and returned.
    >
    >
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >



    --
    Sean Tierney
    Sean Tierney, Sep 22, 2007
    #11
  12. Cristian

    Carl Banks Guest

    On Fri, 21 Sep 2007 21:37:18 +0000, Cristian wrote:
    > Although his learning experience has gone mostly smoothly, he's hit a
    > lot of speed bumps with functions. Specifically, he's having trouble
    > thinking of functions as first order data (don't worry, I haven't
    > confused him with such terminology yet). He had a little trouble
    > understanding that you can pass functions as arguments to other
    > functions (e.g., passing a key to the list.sort method). He also had a
    > little trouble grasping functions within other functions. Last but not
    > least, he had trouble grasping methods in class declarations, especially
    > the required self as the first argument (I'm sure he wasn't the first).


    First of all, let me say that I think "functions as first class data" is
    helpful, but not crucial, to programming in Python, and there are many
    people who simply don't need the lesson. Especially someone like an
    engineer (in the classical sense), who isn't building versatile software
    packages, won't need to resort to functional programming much. For
    straightforward tasks, like sorting lists with a custom ordering,
    functional progamming merely a convenience, and can be done without.

    So I'm -1 on syntactic changes to the language to support a pedagogical
    use that's not crucially important.


    Now, as for the more general question--How do you teach functional
    concepts?--because some people do need to know it. I suspect it's one of
    those things where there are two possibilities and not much in between.
    Either

    1. The person gets it right away.

    or

    2. The person doesn't get it right away.

    In the latter case, trying to teach it conceptually is probably
    hopeless. Best thing to do is teach functional usage for certain use
    cases. For instance, teach someone to define a function returning a key,
    and have them use "key=myfunc" in list.sort--and not worry about why it
    works. If they keep at it, eventually one of two things will happen.
    Either,

    2a. The person will have an "A ha! I get it now!" moment, and will
    finally understand the concept.

    or

    2b. The person will never get it.


    Carl Banks
    Carl Banks, Sep 22, 2007
    #12
  13. Cristian

    Sean Tierney Guest

    On 9/21/07, Sean Tierney <> wrote:
    > Just tell him that "functions are like all other variables and can
    > therefore be passed by other functions or returned by other functions.
    > "
    >
    > If your friend understands variables and functions and he can't make
    > the "leap" (and assuming you're right, of course) then your friend
    > doesn't [might not] understand variables and functions [and he might need patience b/c this stuff is hard and not everyone is as smart as everyone else].
    >
    > Happy Friday.
    >
    > Sean [moderately overweight, self-admitted (very) slow learner.]
    >
    > On 9/21/07, Cristian <> wrote:
    > > On Sep 21, 3:44 pm, Ron Adam <> wrote:
    > >
    > > > I think key may be to discuss names and name binding with your friend. How
    > > > a name is not the object it self, like a variable is in other languages.
    > > > For example show him how an object can have more than one name. And discus
    > > > how names can be bound to nearly anything, including classes and functions.

    > >
    > > I could discuss name binding but it would be great if Python said this
    > > itself. After all, you can even bind a module with the foo = bar
    > > syntax by using __import__ function. If function definitions followed
    > > the same pattern, I think a beginner would subconsciously (maybe even
    > > consciously) realize that function names are just like everything
    > > else. Actually, this would be helpful for many people. If you come
    > > from a language like Java you're used to thinking of attributes and
    > > methods as living in different namespaces. I think a new syntax will
    > > encourage seasoned programmers think in a more Pythonic way.
    > >
    > > Python has done a very good job in easing people into programming. My
    > > friend doesn't come to me very often because the syntax is clear and
    > > simple and the builtin datatypes allow you to do so much. My goal is
    > > that I would never have to explain to him about name binding; that
    > > he'd pick it up by learning the language on his own. He's learned
    > > lists, dictionaries and even some OOP without me. I don't think name
    > > binding would be a stretch.
    > >
    > > > You could also discus factory functions with him. Once he gets that a
    > > > function can return another function, then it won't be so much of a leap
    > > > for a function to take a function as an argument.

    > >
    > > I think this isn't the most intuitive way of approaching first order
    > > functions. It's true that if a function can return another function
    > > then a function must be first order (i.e., it's just like any other
    > > variable), but that seems almost backwards to me. I think it would
    > > make more sense to have beginners _know_ that functions are like all

    >
    > > other variables and can therefore be passed by other functions or
    > > returned by other functions. That I think would be better accomplished
    > > if they define functions the same way you would define other variables
    > > that you know can be passed and returned.
    > >
    > >
    > > --
    > > http://mail.python.org/mailman/listinfo/python-list
    > >

    >
    >
    > --
    > Sean Tierney
    >



    --
    Sean Tierney
    Sean Tierney, Sep 22, 2007
    #13
  14. Cristian

    Cristian Guest

    On Sep 21, 4:27 pm, "J. Cliff Dyer" <> wrote:
    > Cristian wrote:
    > > On Sep 21, 3:44 pm, Ron Adam <> wrote:

    >
    > >> I think key may be to discuss names and name binding with your friend. How
    > >> a name is not the object it self, like a variable is in other languages.
    > >> For example show him how an object can have more than one name. And discus
    > >> how names can be bound to nearly anything, including classes and functions.

    >
    > > I could discuss name binding but it would be great if Python said this
    > > itself. After all, you can even bind a module with the foo = bar
    > > syntax by using __import__ function. If function definitions followed
    > > the same pattern, I think a beginner would subconsciously (maybe even
    > > consciously) realize that function names are just like everything
    > > else. Actually, this would be helpful for many people. If you come
    > > from a language like Java you're used to thinking of attributes and
    > > methods as living in different namespaces. I think a new syntax will
    > > encourage seasoned programmers think in a more Pythonic way.

    >
    > However, you still have to solve the problem of using a single-line
    > construct (x = y) with a multi-line definition. That is the essential
    > difference that def is designed to solve. The __import__ trick works
    > because import is also a single line construct.
    >
    > The only proposal given in this thread is using consistent indentation
    > within the parentheses, but parentheses are already explicitly designed
    > to let you ignore the whitespace rules. To suddenly create a situation
    > in which you have significant whitespace on the right side of an
    > assignment statement, and *within parentheses* will break too much code,
    > and make the solution unnecessarily ugly. Multi-line lambdas have been
    > rejected because of this very problem, so unless you have a clean
    > solution, I think your proposal falls into the category of "would be
    > nice, but not in Python."
    >
    > Cheers,
    > Cliff


    http://www.artima.com/weblogs/viewpost.jsp?thread=147358

    You, Guido, and I all agree that anonymous functions in expressions
    are ugly. There's no argument there. I wouldn't expect any self
    respecting programmer to do such a thing even if it was available to
    them (in Python that is).

    I suppose my question is, taking into account the potential of ugly
    code that could be created, and the fact that it's technically
    feasible, would it still be worth adding anonymous functions to
    explicitly show the first order nature of functions and show that
    functions are in the same namespace as all other variables?

    I suppose a solution could be to allow the my_function = function(foo,
    bar): ... syntax but throw a syntax error if the function isn't being
    bound to a variable, but that would cause other problems. From that
    syntax you would assume that it's possible to create an anonymous
    function wherever a variable is expected. That's not very intuitive
    either.
    Cristian, Sep 22, 2007
    #14
  15. Cristian a écrit :
    (snip)
    > To me, the biggest setback for new programmers is the different syntax
    > Python has for creating functions. Instead of the common (and easy to
    > grasp) syntax of foo = bar


    It's actually a mostly *un*common syntax when it comes to functions. The
    only "mainstream" language I know allowing such a syntax is javascript.

    Now given python's parsing rules, I wonder how this could be implemented...

    > Python has the def foo(): syntax. So, when
    > a new programmer is first introduced to functions they are immediately
    > confronted with the notion that functions are "different".


    Which is the case in most non functional languages.

    > After all,
    > they have their own special syntax. This seems to only further the
    > separation newbies make between "data" and "functions" or "stuff" and
    > "actions". Now, the vast majority of us learned this dichotomy when we
    > first began to program, so we are ingrained to assume and even expect
    > a different syntax for function declaration, but in a program like
    > Python there doesn't seem to be any other reason to have it.


    Technically, I'd say "patsing rules". From a more conceptual POV, Python
    was meant to be the missing link between shell scripts and C - and some
    design choices clearly (IMHO) came from the desire to look familiar
    enough to C programmers. Even if Python ended up with some (restricted)
    support for functional programming, it's still has it's roots in
    procedural programming.

    > Furthermore, I think it actually inhibits the learning of the
    > uninitiated. We can, of course, keep the current syntax as sugar.
    >
    > To someone who's learning to program wouldn't a syntax like the
    > further give them all they need and also reinforces the idea that
    > functions are data just like everything else?


    Python's functions are *objects* like anything else. And objects are
    more than data. My 2 cents: show your friend that Python's functions are
    objects, and that other objects can be callable too...

    > my_function = function(foo, bar): pass
    > an_instance_method = function(self, foo): pass
    > a_method_declaration = method(self, foo): pass
    >
    > The last one is mostly my pet peeve of having Python "magically"
    > create methods out of (what is essentially) a function declaration.


    There's not much magic in this. What's stored as an attribute of the
    class *is* a function. It's only wrapped in a method object when looked
    up. And FWIW, it's the function object itself that takes care of this,
    thanks to the descriptor protocol (all relevant doc is on python.org).

    > When I first learned it, it felt wrong but you had to press through it
    > because there was really no other way of declaring methods.


    Truth is that you do *not* "declare" methods in Python.
    Bruno Desthuilliers, Sep 22, 2007
    #15
  16. Cristian

    Cristian Guest

    On Sep 21, 4:47 pm, "Sean Tierney" <> wrote:
    > Just tell him that "functions are like all other variables and can
    > therefore be passed by other functions or returned by other functions.
    > "
    >




    I could """Just tell him that "functions are like all other variables
    and can
    therefore be passed by other functions or returned by other functions.
    " """ but wouldn't it be great if Python did this for me? It seems to
    me that the ability for Python to explicitly state that functions-are-
    like-other-variables is there so why not expose it?

    > If your friend understands variables and functions and he can't make
    > the "leap" (and assuming you're right, of course) then your friend
    > doesn't understand variables and functions.


    To say that you understand variables and functions is language
    specific. You can't translate your knowledge of variables and
    functions from Python to Java and vice-versa. They are treated
    completely different. Perhaps you can translate your Python
    understanding of functions and variables to Javascript but not to C.
    Cristian, Sep 22, 2007
    #16
  17. Kay Schluehr a écrit :
    (snip)
    >
    > I checked out Io once and I disliked it. I expected Io's prototype OO
    > being just a more flexible variant of class based OO but Io couples a
    > prototype very closely to its offspring. When A produces B and A.f is
    > modified after production of B also B.f is modified. A controls the
    > state of B during the whole lifetime of B. I think parents shall not
    > do this, not in real life and also not in programming language
    > semantics.


    I may totally miss the point, but how is this different from:

    class A(object):
    def dothis(self):
    print "A.dothis(%s)" % self

    class B(A):
    pass

    b = B()

    b.dothis()

    def dothat(self):
    print "function dothat(%s)" % self

    A.dothis = dothat
    b.dothis()
    Bruno Desthuilliers, Sep 22, 2007
    #17
  18. Kay Schluehr a écrit :
    > On 22 Sep., 23:17, Erik Max Francis <> wrote:
    >
    >
    >>The attribute and method (not made distinct in Io; they're called
    >>"slots") is much the same as with Python; the current instance is
    >>checked for the object, then its parents, then _its_ parents, and so on.

    >
    >
    > Repeating the same point as Marc doesn't mean that I have to repeat my
    > reply as well. Doesn't it?
    >

    Then please don't answer my own repeating of the same point !-)
    Bruno Desthuilliers, Sep 22, 2007
    #18
  19. Cristian a écrit :
    > On Sep 21, 4:47 pm, "Sean Tierney" <> wrote:
    >
    >>Just tell him that "functions are like all other variables and can
    >>therefore be passed by other functions or returned by other functions.
    >>"
    >>

    >
    >
    >
    >
    > I could """Just tell him that "functions are like all other variables
    > and can
    > therefore be passed by other functions or returned by other functions.
    > " """ but wouldn't it be great if Python did this for me? It seems to
    > me that the ability for Python to explicitly state that functions-are-
    > like-other-variables is there so why not expose it?


    Ok, then what about classes ? They also are objects-like-any-other,
    after all. So should we have this syntax too ?

    MyClass = class(ParentClass):
    __init__ = function (self, name):
    self.name = name

    ?-)
    Bruno Desthuilliers, Sep 22, 2007
    #19
  20. Cristian

    Ron Adam Guest

    Cristian wrote:
    > On Sep 21, 3:44 pm, Ron Adam <> wrote:
    >
    >> I think key may be to discuss names and name binding with your friend. How
    >> a name is not the object it self, like a variable is in other languages.
    >> For example show him how an object can have more than one name. And discus
    >> how names can be bound to nearly anything, including classes and functions.

    >
    > I could discuss name binding but it would be great if Python said this
    > itself. After all, you can even bind a module with the foo = bar
    > syntax by using __import__ function. If function definitions followed
    > the same pattern, I think a beginner would subconsciously (maybe even
    > consciously) realize that function names are just like everything
    > else. Actually, this would be helpful for many people. If you come
    > from a language like Java you're used to thinking of attributes and
    > methods as living in different namespaces. I think a new syntax will
    > encourage seasoned programmers think in a more Pythonic way.


    I could see methods having their own keywords. Then functions defined in
    classes would be static methods without any extra work. But to do that
    would break a lot of already existing code as well as confuse a lot of
    current users.


    > Python has done a very good job in easing people into programming. My
    > friend doesn't come to me very often because the syntax is clear and
    > simple and the builtin datatypes allow you to do so much. My goal is
    > that I would never have to explain to him about name binding; that
    > he'd pick it up by learning the language on his own. He's learned
    > lists, dictionaries and even some OOP without me. I don't think name
    > binding would be a stretch.


    Chances are he'll run into a gotcha where an object has two names and sort
    it out that way. Which is why I suggested starting there. It will save
    him some grief if he hasn't run into it yet.


    >> You could also discus factory functions with him. Once he gets that a
    >> function can return another function, then it won't be so much of a leap
    >> for a function to take a function as an argument.

    >
    > I think this isn't the most intuitive way of approaching first order
    > functions.


    The Python tutorial does this by defining a function, then assigning it to
    another name and calling it from the new name.

    http://www.python.org/doc/current/tut/tut.html


    > It's true that if a function can return another function
    > then a function must be first order (i.e., it's just like any other
    > variable), but that seems almost backwards to me. I think it would
    > make more sense to have beginners _know_ that functions are like all
    > other variables and can therefore be passed by other functions or
    > returned by other functions. That I think would be better accomplished
    > if they define functions the same way you would define other variables
    > that you know can be passed and returned.


    I think it gets awkward fairly quick if you try and work out how to do
    this. There have been requests in the past to have functions assigned to
    names like other things.

    The nice thing about the current syntax is it more closely resembles what
    you would type at call time, so it is more self documenting.

    def sum(x, y):
    return x + Y

    total = sum(1, 2)


    I think changing that would be trading one type of clarity for another.


    Ron
    Ron Adam, Sep 22, 2007
    #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. Xiangliang Meng
    Replies:
    1
    Views:
    1,595
    Victor Bazarov
    Jun 21, 2004
  2. Casey Hawthorne
    Replies:
    4
    Views:
    1,002
    Jarek Zgoda
    Aug 4, 2006
  3. Hal Vaughan
    Replies:
    7
    Views:
    473
  4. Reporter
    Replies:
    3
    Views:
    476
    Mike Schilling
    May 12, 2007
  5. Replies:
    1
    Views:
    220
Loading...

Share This Page