I would like to get some feedback on a proposal to introduce
smalltalk/ruby-like code blocks to python. Code blocks are, among other
things, a clean way to solve the acquire/release problem [1][2]. This
proposal also touches on some of the problems PEP 288 [3] deals with.
The best discussion
On Fri, 11 Mar 2005, Josiah Carlson wrote:
My first reaction to the proposal was ick. Why? Because every time
I've seen a mechanism for modifying the internals of generators
constructed using yield, the syntax has been awful; in my opinion
(whether my opinion means anything is another matter),
On Sat, 12 Mar 2005, Steven Bethard wrote:
The goals behind this seem a lot like the goals of PEP 288[1]. I
remember discussions suggesting code like:
def gen():
a, b, c=3 = yield 1
yield a + b*c
g = gen()
print g.next() # prints 1
print g.next(1, 2) # prints 7
But as you can see, this
On Sat, 12 Mar 2005, Steven Bethard wrote:
Brian Sabbey [EMAIL PROTECTED] wrote:
I agree that this is a confusing way to use generators. But it is the
expected way to use code blocks as found in other languages. It would
take some getting used to that 'for' can be used this way, but I think
On Sat, 12 Mar 2005, Josiah Carlson wrote:
I stand by my clever hack statement, and I will agree to disagree with
you on it, like I agree to disagree with you about both the necessity of
passing arbitrary values back into a generator (I think it is poor
style, and too much brain overhead to
On Sun, 13 Mar 2005, Greg Ewing wrote:
Brian Sabbey wrote:
I prefer re-using the 'for' loop for this purpose because it allows the
problem to be solved in a general way by re-using a structure with which
most users are already familiar, and uses generators, which are easier to
use in this case
On Mon, 14 Mar 2005, Greg Ewing wrote:
Brian Sabbey wrote:
The problem with creating a new mechanism is that sometimes you will want
to loop. For example, reading a bunch of items from a shared resource,
modifying them, and sending them back. A new, non-looping mechanism will
not be adequate
be guaranteed to run under all conditions, I think it
would be useful if it could be arranged so that
for x in somegenerator():
...
raise Blather
...
would caused any finallies that the generator was suspended
inside to be executed. Then the semantics would be the
same as if the
Samuele Pedroni wrote:
OTOH a suite-based syntax for thunks can likely not work as a substitute of
lambda for cases like:
f(lambda: ..., ...)
where the function is the first argument, and then there are further
arguments.
I do not see why you say suite-based thunks cannot be used in the case in
Samuele Pedroni wrote:
My point is that a suite-based syntax
can only be a half substitute for lambda and anyway requiring a suite
seems overkill and unnatural for the just 1 expression case, for example
predicates. IOW a suite-based syntax is not a lambda killer in itself, I
would not try to
Jim Jewett wrote:
It may be time to PEP (or re-PEP), if only to clarify what people are
actually asking for.
I will PEPify this, unless someone does not think I am the correct person
to do so. The PEP is probably a better place to try to address questions
you raise, as well as give the
Shannon -jj Behrens wrote:
Have you guys considered the following syntax for anonymous blocks? I
think it's possible to parse given Python's existing syntax:
items.doFoo(
def (a, b) {
return a + b
},
def (c, d) {
return c + d
}
)
There was a
Guido van Rossum wrote:
See the thread pre-PEP: Suite-Based Keywords (shamless plug)
(an earlier, similar proposal is here:
http://groups.google.co.uk/groups?selm=mailman.403.1105274631.22381.python-list
%40python.org ).
In short, if doFoo is defined like:
def doFoo(func1, func2):
pass
You
Guido van Rossum wrote:
@acquire(myLock):
code
code
code
It would certainly solve the problem of which keyword to use! :-) And
I think the syntax isn't even ambiguous -- the trailing colon
distinguishes this from the function decorator syntax. I guess it
would morph '@xxx' into
Fredrik Lundh wrote:
Brian Sabbey wrote:
If suites were commonly used as above to define properties, event handlers
and other callbacks, then I think most people would be able to comprehend
what the first example above is doing much more quickly than the second.
wonderful logic, there. good
Greg Ewing wrote:
I also have a thought concerning whether the block
argument to the function should come first or last or
whatever. My solution is that the function should take
exactly *one* argument, which is the block. Any other
arguments are dealt with by currying. In other words,
with_file
Guido van Rossum wrote:
Even without a block-statement, these two changes make yield look a
lot like invoking a thunk -- but it's more efficient, since calling
yield doesn't create a frame.
I like PEP 340 a lot, probably as much or more than any thunk ideas I've
seen. But I want to defend thunks
Jim Jewett wrote:
The only members that need special attention are (f_code, f_lasti)
and possibly (f_blockstack, f_iblock).
You don't even need to take care of f_code. The thunk and its surrounding
function can share the same code. The thunk gets compiled into the
function the same way the
18 matches
Mail list logo
