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 body
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
Nick Coghlan wrote:
Accordingly, I would like to suggest that 'with' revert to something
resembling the PEP 310 definition:
resource = EXPR
if hasattr(resource, "__enter__"):
VAR = resource.__enter__()
else:
VAR = None
try:
try:
BODY
except:
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 abo
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
Guido van Rossum wrote:
Why not have the block automatically be inserted into acquire's argument
list? It would probably get annoying to have to define inner functions
like that every time one simply wants to use arguments.
But the number of *uses* would be much larger than the number of
"block de
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 "user-de
Fredrik Lundh wrote:
In short, if doFoo is defined like:
def doFoo(func1, func2):
pass
You would be able to call it like:
doFoo(**):
def func1(a, b):
return a + b
def func2(c, d):
return c + d
That is, a suite can be used to define keyword arguments.
umm. isn't that just 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
Yo
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 proposal
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 rationale
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 stres
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
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 for-loop-
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
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
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 wo
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
On Sat, 12 Mar 2005, Josiah Carlson wrote:
I say it is magical. Why? The way you propose it, 'yield' becomes an
infix operator, with the name provided on the left being assigned a
value produced by something that isn't explicitly called, referenced, or
otherwise, by the right. In fact, I would s
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 creat
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),
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 discuss
22 matches
Mail list logo
