Cristian wrote:
> On Sep 21, 3:44 pm, Ron Adam <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
