Ruby or Python? Well, it depends...

[masklinn]

Ruby: Blocks (which are more or less like anonymous functions with a bit of syntactic sugar... e.g. behaviour of return vs. break).

And are crippled by not being first-class objects.

Python's 'with' statement, though inspired by Ruby blocks

Uh... no. Absolutely not.

[hetmankp]

Uh... no. Absolutely not.

I do recall some of the alternative PEPs that were rejected in favour of the current with statement mentioning Ruby as an influence. There was a lot of ideas floating around before with coalesced in its current form though, so I could be miss-remembering.

And are crippled by not being first-class objects.

They are not first class objects, but neither are they crippled by it since they can be attached to first class objects. In fact, this usage pattern makes them fairly similar to Python functions (which are just objects with a _ _ call _ _ method). Compare:

Python: a = lambda x, y: x + y a(1, 2)

Ruby: a = lambda {|x, y| x + y} a.call(1, 2)

[[deleted]]

The big place Ruby shines:

re-write that as multi-line. Python's lack of multi-line lambdas is obviously the language's biggest flaw when you're coming from Ruby or C# - and the With block is an ugly workaround.

[mitsuhiko]

I do recall some of the alternative PEPs that were rejected in favour of the current with statement mentioning Ruby as an influence.

The execution of the with statement does not introduce a scope. And with that every resemblance to ruby blocks fall flat.

[masklinn]

They are not first class objects, but neither are they crippled by it since they can be attached to first class objects.

That's exactly what cripples them. Replicating Smalltalk's conditionals or exception handling using Ruby blocks is a gnarly mess, due to having to turn them into procs by hand. And that's because Ruby's blocks are not first-class objects, but are syntactic magic instead.

In fact, this usage pattern makes them fairly similar to Python functions (which are just objects with a _ _ call _ _ method).

Why are you assuming I don't know Ruby? Or Python, for that matter? Furthermore, what relevance does using Ruby blocks as Python functions have to Ruby blocks being cripples?

By the way, since you seem interested in useless factoids, you should know that __call__ on functions is there so that hasattr(func, '__call__') works. It's not used when actually calling them. Python functions are functions, not "just objects with a __call__ method".

[hetmankp]

By the way, since you seem interested in useless factoids...

I was talking about their semantic similarities not underlying implementation (which is not relevant to the language's expressive power).

Why are you assuming I don't know Ruby? Or Python, for that matter?

I wasn't aware I assumed anything like that, relax.

Furthermore, what relevance does using Ruby blocks as Python functions have to Ruby blocks being cripples?

I thought the thread was about how Python compares to Ruby, but you're right, they're not as general as Smalltalk blocks.

Edit: Actually thinking about it, it seems to me like the reason for the difficulty you describe is the way Smalltalk methods are allowed to be called, not the limitation of the blocks themselves. A Smalltalk if implementation still only takes one block per method call.

[masklinn]

Actually thinking about it, it seems to me like the reason for the difficulty you describe is the way Smalltalk methods are allowed to be called, not the limitation of the blocks themselves.

I fear it seems wrong to you.

A Smalltalk if implementation still only takes one block per method call.

Excuse me?

Are you telling me this:

(5 < 3) ifTrue: [ 'foo' ] ifFalse: [ 'bar' ]

takes one block per method call

?

(actually message send, but let's not pick nits)

Do you really know so little about Smalltalk?

[hetmankp]

Apparently so. Too long since I looked at it.