Guido van Rossum wrote:
Fredrik, what does your intuition tell you?
having been busy with other stuff for nearly a week, and seeing that the PEP is
now at
version 1.22, my intuition tells me that it's time to read the PEP again before
I have any
opinion on anything ;-)
/F
[Greg Ewing]
Elegant as the idea behind PEP 340 is, I can't shake
the feeling that it's an abuse of generators. It seems
to go to a lot of trouble and complication so you
can write a generator and pretend it's a function
taking a block argument.
[Guido]
Maybe. You're not the first one
Guido van Rossum [EMAIL PROTECTED] writes:
[Greg Ewing]
Elegant as the idea behind PEP 340 is, I can't shake
the feeling that it's an abuse of generators. It seems
to go to a lot of trouble and complication so you
can write a generator and pretend it's a function
taking a block argument.
Brian Sabbey [EMAIL PROTECTED] writes:
It is possible to implement thunks without them creating their own
frame. They can reuse the frame of the surrounding function. So a new
frame does not need to be created when the thunk is called, and, much
like with a yield statement, the frame is not
On Thu, Apr 28, 2005, Brian Sabbey wrote:
It is possible to implement thunks without them creating their own frame.
They can reuse the frame of the surrounding function. So a new frame does
not need to be created when the thunk is called, and, much like with a
yield statement, the frame
Brian Sabbey:
It is possible to implement thunks without them creating their own
frame. They can reuse the frame of the surrounding function ...
The implementation just needs to take care
to save and restore members of the frame that get clobbered when the
thunk is running.
Michael Hudson:
[Michael Hudson]
I think the making-generators-more-sexy thing is nice, but I'm think
that's almost orthogonal.
Not entirely. I agree that continue EXPR calling next(EXPR) which
enables yield-expressions is entirely orthogonal.
But there are already two PEPs asking for passing exceptions
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
Guido van Rossum:
-- but it's more efficient, since calling yield doesn't create a frame.
Neither should a thunk.
The other problem with thunks is that once we think of them as the
anonymous functions they are, we're pretty much forced to say that a
return statement in a thunk returns from
On 4/29/05, Brian Sabbey [EMAIL PROTECTED] wrote:
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
On 29 apr 2005, at 20.10, Brian Sabbey wrote:
[...] The thunk and its surrounding function can share the same
code. The thunk gets compiled into the function the same way the
body of a for loop would.
This seems really, truly, nasty! Wouldn't this require you to check
the source code of the
Elegant as the idea behind PEP 340 is, I can't shake
the feeling that it's an abuse of generators. It seems
to go to a lot of trouble and complication so you
can write a generator and pretend it's a function
taking a block argument.
I'd like to reconsider a thunk implementation. It
would be a lot
Based on Guido's opinion that caller and callee should both be
marked, I have used keywords 'include' and 'chunk'. I therefore
call them Chunks and Includers.
Examples are based on
(1) The common case of a simple resource manager. e.g.
Greg Ewing [EMAIL PROTECTED] writes:
Are there any objective reasons to prefer a generator
implementation over a thunk implementation?
I, too, would like to see an answer to this question.
I'd like to see an answer in the PEP, too.
Cheers,
mwh
--
All obscurity will buy you is time enough
[Greg Ewing]
Elegant as the idea behind PEP 340 is, I can't shake
the feeling that it's an abuse of generators. It seems
to go to a lot of trouble and complication so you
can write a generator and pretend it's a function
taking a block argument.
Maybe. You're not the first one saying this
Guido van Rossum wrote:
The main advantage of thunks that I can see is that you can save the
thunk for later, like a callback for a button widget (the thunk then
becomes a closure).
Or pass it on to another function. This is something we
haven't considered -- what if one resource-acquision-
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
(BTW, I'm trying to update the PEP with a discussion of thunks.)
[Guido]
The main advantage of thunks that I can see is that you can save the
thunk for later, like a callback for a button widget (the thunk then
becomes a closure).
[Greg]
Or pass it on to another function. This is
Skip Montanaro wrote:
Guido or perhaps even (making for VAR optional in the for-loop syntax)
Guido with
Guido in synchronized(the_lock):
Guido BODY
This could be a new statement, so the problematic issue of implicit
try/finally in every for statement wouldn't be
Nick Coghlan wrote:
An alternative would be to replace the 'yield None' with a 'break' or
'continue', and create an object which supports the resource protocol
and NOT the iterator protocol. Something like:
def my_resource():
print Hi! # Do entrance code
continue # Go on with
On 4/21/05, Guido van Rossum [EMAIL PROTECTED] wrote:
for dummy in synchronized(the_lock):
BODY
or perhaps even (making for VAR optional in the for-loop syntax)
with
in synchronized(the_lock):
BODY
Then synchronized() could be written cleanly as follows:
def
Ka-Ping Yee wrote:
Can you explain what you meant by currying here? I know what
the word curry means, but i am having a hard time seeing how
it applies to your example.
It's currying in the sense that instead of one function
which takes all the args at once, you have a function
that takes some of
Brian Sabbey wrote:
I made an example implementation, and this wasn't an issue. It took
some code to stick the thunk into the argument list, but it was pretty
straightforward.
What does your implementation do with something like
f() + g():
...
? (A syntax error, I would hope.)
While no
[Greg Ewing]
My current thought is that it should look like this:
with_file(filename) as f:
do_something_with(f)
The success of this hinges on how many use cases can
be arranged so that the word 'as' makes sense in that
position.
[...]
This way, the syntax is just
expr
In case my point about the difference between thunks and other
callables (specifically decorators) slipped by, consider the
documentation for staticmethod, which takes a callable. All the
staticmethod documentation says about that callable's parameters is:
A static method does not
It strikes me that with something like this lexical declaration, we
could abuse decorators as per Carl Banks's recipe[1] to get the
equivalent of thunks:
abuse being the operative word.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
On 4/21/05, Guido van Rossum [EMAIL PROTECTED] wrote:
It strikes me that with something like this lexical declaration, we
could abuse decorators as per Carl Banks's recipe[1] to get the
equivalent of thunks:
abuse being the operative word.
Yup. I was just drawing the parallel between:
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
I've been thinking about this a lot, but haven't made much
progess. Here's a brain dump.
I've been thinking about integrating PEP 325 (Resource-Release Support
for Generators) into the for-loop code, so that you could replace
the_lock.acquire()
try:
BODY
finally:
On Thu, 21 Apr 2005, Guido van Rossum wrote:
Perhaps it could be even simpler:
[assignment_target '=']* expr ':' suite
This would just be an extension of the regular assignment statement.
It sounds like you are very close to simply translating
expression... function_call(args):
Guido van Rossum wrote:
I've been thinking about this a lot, but haven't made much
progess. Here's a brain dump.
I've been thinking about integrating PEP 325 (Resource-Release Support
for Generators) into the for-loop code, so that you could replace
[SNIP - using 'for' syntax to delineate
Guido van Rossum [EMAIL PROTECTED] wrote:
[Brett]
I think I agree with Samuele that it would be more pertinent to put all of
this
effort into trying to come up with some way to handle cleanup in a
generator.
I.e. PEP 325.
But (as I explained, and you agree) that still doesn't
On Apr 21, 2005, at 8:59 PM, Josiah Carlson wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
[Brett]
I think I agree with Samuele that it would be more pertinent to put
all of this
effort into trying to come up with some way to handle cleanup in a
generator.
I.e. PEP 325.
But (as I explained,
On Thu, Apr 21, 2005, Guido van Rossum wrote:
Perhaps the most important lesson we've learned in this thread is that
the 'with' keyword proposed in PEP 310 is redundant -- the syntax
could just be
[VAR '=']* EXPR ':'
BODY
IOW the regular assignment / expression statement
Guido or perhaps even (making for VAR optional in the for-loop syntax)
Guido with
Guido in synchronized(the_lock):
Guido BODY
This could be a new statement, so the problematic issue of implicit
try/finally in every for statement wouldn't be necessary. That
Ka-Ping Yee wrote:
It seems to me that, in general, Python likes to use keywords for
statements and operators for expressions.
Probably worth noting that 'for', 'in' and 'if' in generator
expressions and list comprehensions blur this distinction somewhat...
Steve
--
You can wordify anything
Guido van Rossum wrote:
[Brett]
I think I agree with Samuele that it would be more pertinent to put all of
this
effort into trying to come up with some way to handle cleanup in a generator.
I.e. PEP 325.
But (as I explained, and you agree) that still doesn't render PEP 310
Bob Ippolito wrote:
On Apr 21, 2005, at 8:59 PM, Josiah Carlson wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
[Brett]
I think I agree with Samuele that it would be more pertinent to put
all of this
effort into trying to come up with some way to handle cleanup in a
generator.
On Apr 22, 2005, at 12:28 AM, Brett C. wrote:
Bob Ippolito wrote:
On Apr 21, 2005, at 8:59 PM, Josiah Carlson wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
[Brett]
I think I agree with Samuele that it would be more pertinent to put
all of this
effort into trying to come up with some way to
On 4/19/05, Brian Sabbey [EMAIL PROTECTED] wrote:
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
On Apr 20, 2005, at 5:43 AM, Paul Moore wrote:
and the substitution of
@EXPR:
CODE
would become something like
def __block():
CODE
EXPR(__block)
The question of whether assignments within CODE are executed within a
new namespace, as this implies, or in the surrounding namespace,
remains
Aahz wrote:
On Tue, Apr 19, 2005, Shane Holloway (IEEE) wrote:
However, my opinion is that it does not read smoothly. This form
requires that I say what I'm doing with something before I know the
context of what that something is. For me, blocks are not about
shortening the code, but rather
[Shane Holloway]
When I
write classes, I tend to put the public methods at the top. Utility
methods used by those entry points are placed toward the bottom. In
this way, I read the context of what I'm doing first, and then the
details of the internal methods as I need to understand them.
Alex Martelli wrote:
def withfile(filename, mode='r'):
openfile = open(filename, mode)
try:
block(thefile=openfile)
finally:
openfile.close()
i.e., let the block take keyword arguments to tweak its namespace
I don't think I like that idea, because it means that from
the
Josiah Carlson wrote:
I once asked Any other
use cases for one of the most powerful features of Ruby, in Python? I
have yet to hear any sort of reasonable response.
Why am I getting no response to my question? Either it is because I am
being ignored, or no one has taken the time to translate one
Steven Bethard wrote:
Of course, even with the unpack list, you still have to know what kind
of arguments the function calls your block with. And because these
only appear within the code, e.g.
block(openfile)
you can't rely on easily accessible things like the function's
signature.
You can't
Shane Holloway (IEEE) wrote:
class After:
def readIt(self, filename):
withFile(filename):
self.readPartA(aFile)
self.readPartB(aFile)
self.readPartC(aFile)
In my opinion, this is much smoother to read. This particular example
Greg Ewing wrote:
Steven Bethard wrote:
Of course, even with the unpack list, you still have to know what kind
of arguments the function calls your block with. And because these
only appear within the code, e.g.
block(openfile)
you can't rely on easily accessible things like the
(I apologize that this is my first post. Please don't flame me into
oblivion or think I'm a quack!)
(Having met JJ I can assure he's not a quack. But don't let that stop
the flames. :-)
Have you guys considered the following syntax for anonymous blocks? I
think it's possible to parse given
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
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 would be
At 11:55 AM 04/19/2005 -0700, Guido van Rossum wrote:
I'd recommend this:
tri = self.subcalculation(The quick brown fox jumps over the lazy dog)
self.disentangle(0x40, tri, self.indent+1)
IMO this is clearer, and even shorter!
What was your opinion on where as a lambda replacement? i.e.
foo =
At 03:39 PM 04/19/2005 -0400, Phillip J. Eby wrote:
I suspect that you like the define-first approach because of your tendency
to ask questions first and read later.
Oops; I forgot to put the smiley on that. It was supposed to be a humorous
reference to a comment Guido made in private e-mail
On 4/19/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I'm still not sure how this is particularly solving a pressing problem
that isn't solved by putting the function definitions in front of the
Well.
As to what I've read in my short python experience, people wants to
change the language
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
On Tue, 2005-04-19 at 15:24, Guido van Rossum wrote:
*If* we're going to create syntax for anonymous blocks, I think the
primary use case ought to be cleanup operations to replace try/finally
blocks for locking and similar things. I'd love to have syntactical
support so I can write
Guido van Rossum wrote:
tri = self.subcalculation(The quick brown fox jumps over the lazy
dog)
self.disentangle(0x40, tri, self.indent+1)
IMO this is clearer, and even shorter!
But it clutters the namespace with objects you don't need. So the
complete equivalent would be more close to:
tri =
@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-defined-keyword.
How
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
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 decorators you'd be
Guido van Rossum wrote:
As I said before, I'm not sure why keeping get_foo etc. out of the
class namespace is such a big deal. In fact, I like having them there
(sometimes they can even be handy, e.g. you might be able to pass the
unbound get_foo method as a sort key).
Not to mention that it's
[Guido van Rossum]
@EXPR:
CODE
would become something like
def __block():
CODE
EXPR(__block)
I'm not yet sure whether to love or hate it. :-)
Is it preferable for CODE to execute in its own namespace (the above
being a literal translation of the given code), or for it to
RSMotD (random stupid musing of the day): so I wonder if the decorator
syntax couldn't be extended for this kind of thing.
@acquire(myLock):
code
code
code
Would it be useful for anything other than mutex-locking? And wouldn't
it be better to make a function of the block
On Tue, Apr 19, 2005 at 01:33:15PM -0700, 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
On 4/19/05, BJörn Lindqvist [EMAIL PROTECTED] wrote:
RSMotD (random stupid musing of the day): so I wonder if the decorator
syntax couldn't be extended for this kind of thing.
@acquire(myLock):
code
code
code
Would it be useful for anything other than mutex-locking?
*If* we're going to create syntax for anonymous blocks, I think the
primary use case ought to be cleanup operations to replace try/finally
blocks for locking and similar things. I'd love to have syntactical
support so I can write
I heartily agree! Especially when you have very similar try/finally
On 4/19/05, Alex Martelli [EMAIL PROTECTED] wrote:
Well, one obvious use might be, say:
@withfile('foo.bar', 'r'):
content = thefile.read()
but that would require the decorator and block to be able to interact
in some way, so that inside the block 'thefile' is defined suitably.
67 matches
Mail list logo
