Would Anonymous Functions Help in Learning Programming/Python?

[Cristian]

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?

 

[chris.monsanto]

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

 

[Cristian]

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.

 

[chris.monsanto]

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?

 

[Cristian]

On Sep 21, 2:48 pm, (e-mail address removed) wrote:

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.

 

[Ron Adam]

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]

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

 

[Cristian]

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.

 

[Donn Cave]

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, (e-mail address removed)

 

[J. Cliff Dyer]

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

 

[Sean Tierney]

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

 

[Carl Banks]

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

 

[Sean Tierney]

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.]

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.


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]

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.

 

[Bruno Desthuilliers]

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.

 

[Cristian]

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.

 

[Bruno Desthuilliers]

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]

Kay Schluehr a écrit :

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]

Cristian a écrit :

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

?-)

 

[Ron Adam]

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.

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