Would Anonymous Functions Help in Learning Programming/Python?

chris.monsanto at gmail.com chris.monsanto at gmail.com
Fri Sep 21 17:48:02 EDT 2007


On Sep 21, 5:37 pm, Cristian <super.sgt.pep... at gmail.com> 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




More information about the Python-list mailing list