Confessions of a Python fanboy

[Masklinn]

On 31 Jul 2009, at 11:54 , Iain King wrote:
> On Jul 31, 8:28 am, Steven D'Aprano <st... at REMOVE-THIS-
> cybersource.com.au> wrote:
>> On Thu, 30 Jul 2009 18:06:31 -0500, Robert Kern wrote:
>>> On 2009-07-30 16:44, r wrote:
>>>> On Jul 30, 4:29 pm, Emmanuel Surleau<emmanuel.surl... at gmail.com>  
>>>> wrote:
>>>>>> 1.) No need to use "()" to call a function with no arguments.  
>>>>>> Python
>>>>>> -->  "obj.m2().m3()" --ugly
>>>>>>    Ruby -->  "obj.m1.m2.m3"  -- sweeet!
>>>>>> Man, i must admit i really like this, and your code will look  
>>>>>> so much
>>>>>> cleaner.
>>>>> It has benefits - code does look better. It has also significant  
>>>>> cons
>>>>> - it is ambiguous.
>>>>> For instance:
>>
>>>>> a = b
>>
>>>>> Is b a variable or a method called without parameter?
>>
>>>> Hello Emanuel,
>>>> Again, who so ever names a method with such a non-descriptive  
>>>> name will
>>>> get whats coming to him. And if you did for some reason use such a
>>>> cryptic name as "b", do yourself (and everyone else) a favor and  
>>>> follow
>>>> it with "()" to denote the method call. Remember when something is
>>>> optional that means you have an option to use it OR not use it.
>>
>>> I believe his point is that it is ambiguous to the compiler, not  
>>> humans
>>> reading the code. Python functions and methods are first class  
>>> objects.
>>> They can be passed around. If they were auto-called, then you  
>>> could not
>>> do this.
>>
>> Oh my, "r" is still around is he??? And now he's singing the  
>> praises of
>> Ruby, the language which he treated as the Devil's Spawn when he  
>> first
>> arrived. That's hilarious.
>>
>> But back on topic... "r" has missed the point. It's not that a=b is  
>> hard
>> to understand because b is a poor name. The example could have been:
>>
>> def factory_function():
>>     magic = time.time()  # or whatever
>>     def inner():
>>         return magic
>>     return inner
>>
>> my_function = factory_function
>>
>> It's still ambiguous. Does the programmer intend my_function to  
>> become
>> factory_function itself, or the output of factory_function?
>
> Not only that - does 'return inner' return the function inner or the
> result of function inner?
>
> How does ruby pass a function as an object?
Ruby doesn't have functions as such. It has methods and blocks (which  
would be anonymous functions). `def` always creates methods.

To get a (bound) method object, you simply call `method` on an  
instance e.g. `foo.method(:bar)` is equivalent to `foo.bar` in Python  
(it returns a bound method object without calling it).

Blocks are usually created as part of the calls: `foo.bar  
{do_something}` the part between braces (braces included) is a block,  
which will be passed to the method `bar`. Sadly, Ruby's blocks are  
magical syntax (doesn't mean they have to be, in Smalltalk there's  
nothing magical about blocks for instance) so you can't just do `foo =  
{do_something}`, you have to turn them into `Proc` objects with the  
`proc` constructor (or `lambda`, it's equivalent and looks better so  
I'll use that): `foo = lambda {do_something}`. If you use the magical  
syntax previously shown, Ruby handles the turning of a block into an  
actual `Proc` instance.

And since Ruby doesn't have a `()` operator, it uses a method instead  
(`#call`), so you simply do `foo.call` to execute the proc and get its  
value.

All in all, much like Smalltalk, Ruby tends not to favor raw functions  
the way Python does, so a direct translation of the Python code  
doesn't make much sense.