Asktav - Latest Comments in Ruby-style Blocks in Python

Re: Ruby-style Blocks in Python

tav — Sat, 17 Jan 2015 18:02:20 -0000

Nice work!

Re: Ruby-style Blocks in Python

Yawar Amin — Sat, 17 Jan 2015 16:50:29 -0000

I'm really late to this party but I've been working on something (lambdak) that provides multi-line (multi-statement) lambda functionality as a native Python module. Lmbdak can't do everything a normal function block can do but I believe I can translate the using examples you provided:

webapp.runner(given_(lambda config:
  setattr_(config, "time_zone", "UTC", lambda:
  setattr_(config, "log_level", "debug"))))

# Actually this can be done in just a single normal lambda thanks to the
# `if` expression. But just for the sake of argument....
employees.select(given_(lambda emp:
  fireEmployee(emp) if emp.salary > developer.salary
  else extendContract(emp)))

Admittedly it looks really ugly, but in day-to-day work you can use a few tricks to make it look a little nicer in your editor screen.

I think it has the distinct advantage of being fully functional (pun intended) right now, without any approval needed from BDFL.

Re: Ruby-style Blocks in Python

hiwaylon — Fri, 11 Nov 2011 16:20:12 -0000

Meh, that's like saying "I hate keyboards 'cause they lead to lots of characters." It's all about discipling yourself as a developer to avoid doing things poorly. Fault oneself not the language or bad practice of others.

Re: Ruby-style Blocks in Python

Henrique — Tue, 22 Feb 2011 23:11:02 -0000

I hate Ruby's blocks for the simple fact that it leads to repeated logic everywhere. Defining a function for anything more than a one-liner "is a good thing" in my book.

Re: Ruby-style Blocks in Python

Rajiv — Mon, 20 Sep 2010 20:22:45 -0000

Could you provide the PEP number for this proposal

Re: Ruby-style Blocks in Python

JT — Fri, 23 Apr 2010 18:01:35 -0000

How about using 'as' instead of 'do'? Similar to 'import some as thing'.

using webapp.runner as (config)

Re: Ruby-style Blocks in Python

Lennart Regebro — Fri, 23 Apr 2010 13:29:51 -0000

No! I have it now. "give"!

give function def(x):
blockblockblock

Re: Ruby-style Blocks in Python

Lennart Regebro — Fri, 23 Apr 2010 13:28:27 -0000

I prefer "using function def(x):" or possibly "on function def(x):" as syntax. But I agree, examples that can't easily be done as loops + generators are welcome. Suprisingly many uses of blocks can be done like that. See my Python vs Ruby blogpost: http://regebro.wordpress.co...

Re: Ruby-style Blocks in Python

Lennart Regebr — Fri, 23 Apr 2010 13:23:08 -0000

No. Yuck. Sorry. The block should be an anonymous function, and behave like an anonymous function. And that means return returns from the block. Python is not Ruby or lisp and should not be ruby or lisp.

Re: Ruby-style Blocks in Python

Lennart Regebro — Fri, 23 Apr 2010 13:17:33 -0000

I completely agree with overloading def. I've suggested that instead of lambda before, ie that lambda x: x + x should be spelled def(x): x+x, but this is better.

Re: Ruby-style Blocks in Python

Eric Larson — Fri, 23 Apr 2010 12:04:12 -0000

What were your concerns regarding exceptions? I would think it is the callers responsibility to catch them through either wrapping the entire block or from within the block.

While I honestly never really realized the potential of blocks in Ruby, I've been by smarter people than me that they are what make most of the interesting things in Ruby possible. If you can help provide some insight on what your concerns are regarding exceptions, I'm sure there are people that could help find a solution and work towards submitting a pep.

Re: Ruby-style Blocks in Python

John C — Fri, 23 Apr 2010 08:32:28 -0000

I don't think you're talking nonsense. When I read the article, I couldn't decide if the examples weren't sufficient to make the case, or the fact is that I've never seen the attraction of Ruby's blocks, but something didn't look or feel right. Using "do" in the proposed syntax is part of why it didn't seem right - and probably why it looks awkward in Ruby too.

Re: Ruby-style Blocks in Python

Jonathan Hartley — Fri, 23 Apr 2010 06:20:49 -0000

I don't know anything about anything, and I think I've only half understood this, but the conventional meaning of the word 'do' doesn't seem to match the intended use here. 'do' sounds like 'apply' - whereas when defining a lambda, we're doing the *opposite* of that. Creating a lambda is saying 'don't do this yet, but create it to do something with later'.

Instead of using 'do', why not overload 'def' ?

Def with a name currently defines a named function. Def in the context shown above, with no name, ought to define an anyonymous lambda.

Am I talking nonsense?

Best regards,

Jonathan

Re: Ruby-style Blocks in Python

Name — Tue, 14 Jul 2009 06:27:14 -0000

Sorry to hear that. I'm not familiar with the intrinsics of the PEP process, but maybe there is a chance of publishing what you have so far, and open the door for others to work on it. Maybe someone else has a solution.

Re: Ruby-style Blocks in Python

tav — Mon, 13 Jul 2009 12:31:49 -0000

Thanks man -- unfortunately I got stuck in terms of figuring out how to make exceptions raised inside blocks be Pythonic...

Without solving that, not much use in putting together a PEP =(

Re: Ruby-style Blocks in Python

Name — Mon, 13 Jul 2009 05:17:26 -0000

Dude, this is cool as shit, I love it! Without reading all the 50 comments, is there any progress on this, like a PEP?!

Re: Ruby-style Blocks in Python

Verte — Thu, 19 Mar 2009 04:52:32 -0000

How about 'let' or 'let .. in' ? we could even have letrec.

Re: Ruby-style Blocks in Python

Eric — Wed, 11 Mar 2009 14:12:19 -0000

Good idea, I would love this addition. Here is a good example of a ruby lib that uses blocks to construct a dsl:

http://www.pluginaweek.org/...

Re: Ruby-style Blocks in Python

Adam Olsen — Wed, 11 Mar 2009 01:57:00 -0000

I disagree on your last point. The biggest reason to use functions is to ease understanding. Most programs could be inlined into a single massive function, but the mental effort to understand it would increase by many times, effectively distracting you from the real work that's going on.

Unit testing, although nice, falls out of this "unitizing". It's not the original motivation.

(Although that may also harm performance, compilers could be written to recognize all the duplication and merge common bits. Functions are quite entrenched in common styles though, so there's little motivation to do this today.)

Re: Ruby-style Blocks in Python

MRAB — Tue, 10 Mar 2009 18:35:46 -0000

A "split lambda" perhaps?

records = employee.select(lambda employee):
return do_something(employee) if cond(employee) else None

Re: Ruby-style Blocks in Python

Alia Khouri — Tue, 10 Mar 2009 01:56:10 -0000

Well you wouldn't need the imports in the version below... and yes the assumption is that you can skip the @contextmanager line.

Re: Ruby-style Blocks in Python

Jan — Mon, 09 Mar 2009 15:48:36 -0000

So... the only difference is that you can skip the @contextmanager line? (You need the imports anyway in either version)

Re: Ruby-style Blocks in Python

Demur Rumed — Mon, 09 Mar 2009 15:16:31 -0000

@employee.select
def records():

Re: Ruby-style Blocks in Python

Alia Khouri — Mon, 09 Mar 2009 13:41:45 -0000

There is probably no need to introduce ruby-like blocks to python where iteration comes naturally with list
comprehensions and generators. But for the simple case of entering a block of code as one does with @contextmanager I suppose it would be nice to make a generator with a single yield statement a contextmanager by default such that:

>>> def g():
... print "a"
... yield
... print "b"
...
>>> with g():
... print "c"
...
a
c
b

would be equivalent to

>>> from __future__ import with_statement
>>> from contextlib import contextmanager
>>> @contextmanager

... def g():
... print "a"
... yield
... print "b"
...
>>> with g():

... print "c"
...
a
c
b

Re: Ruby-style Blocks in Python

Steven D'APrano — Mon, 09 Mar 2009 13:35:32 -0000

Hugo, a function (anonymous or named) isn't "just a syntactic element" like while, if etc. It's a compound element taking arguments, with a defined entry point and a defined return value. A function is, or at least should be, coupled loosely to other functions while syntactic elements are coupled very strongly to other elements.

An analogy might be that functions are molecules while single elements are atoms. The semantics of the atom "if x > y: x += y" depends on the other atoms around it, while ideally the function sin() is always the trigonometric sine no matter what other functions are around it. So you should be able to test sin() in isolation, which you can't do with the if block.

(Besides, you can perform limited, ad hoc testing of individual elements simply by sprinkling asserts after each element. Not a good solution, but it is something.)

The whole purpose of functions (procedures or sub-routines) is to lessen the coupling between parts of code, to partially isolate chunks of code for ease of re-use and testing. If a code block is tightly coupled like a while or if, then it is a step backwards towards spaghetti code; and if it is loosely coupled, like a function, then there's no benefit to that looseness if you can't test it or re-use it.