Would Anonymous Functions Help in Learning Programming/Python?

Cristian super.sgt.pepper at gmail.com
Sat Sep 22 00:36:32 CEST 2007

On Sep 21, 3:22 pm, chris.monsa... at gmail.com wrote:
> On Sep 21, 6:07 pm, Cristian <super.sgt.pep... at gmail.com> wrote:
> > On Sep 21, 2:48 pm, chris.monsa... at gmail.com 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.

More information about the Python-list mailing list