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 ;-)
_
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
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 co
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 f
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
[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 an
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 Hud
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 fr
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
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
> [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 th
(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 so
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
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-
generat
[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 thi
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 eno
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.
http://mail.python.org/pipermail/python-dev/2005-April
Greg Ewing wrote:
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. I
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 s
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 follo
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
Shane Hathaway wrote:
There's a lot of boilerplate code there. Using your suggestion, I could
write that something like this:
def transaction():
begin_transaction()
try:
continue
except:
abort_transaction()
raise
else:
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 ne
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 dou
Steven Bethard wrote:
line = None
@withfile("readme.txt")
def print_readme(fileobj):
lexical line
for line in fileobj:
print line
print "last line:" line
Since the name of the function isn't important,
that could be reduced to
@withfile("readme.txt")
def _(fileobj):
...
(Dis
Guido van Rossum wrote:
Perhaps it could be even simpler:
[assignment_target '=']* expr ':' suite
I don't like that so much. It looks like you're
assigning the result of expr to assignment_target,
and then doing something else.
This would just be an extension of the regular assignment stateme
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 o
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 han
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 c
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
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> 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 comp
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 state
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, a
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
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
unnecessary, because abu
On Thu, 21 Apr 2005, Guido van Rossum wrote:
> The use cases where the block actually returns a value are probably
> callbacks for things like sort() or map(); I have to admit that I'd
> rather keep lambda for these (and use named functions for longer
> blocks) than introduce an anonymous block syn
[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
unnecessary, because abusing the for-loo
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 deli
[Ping]
> It sounds like you are very close to simply translating
>
> expression... function_call(args):
> suite
>
> into
>
> expression... function_call(args)(suitefunc)
Actually, I'm abandinging this interpretation; see my separate (long) post.
--
--Guido van Rossum (home pag
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):
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:
the_l
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
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
> 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/)
_
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > 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 callabl
James Y Knight wrote:
> If it was possible to assign to a variable to a variable bound outside
> your function, but still in your lexical scope, I think it would fix
> this issue. That's always something I've thought should be possible,
> anyways. I propose to make it possible via a declaration sim
> 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 r
Guido van Rossum wrote:
> > So while:
> > fooble(arg)
> > is pretty nasty, documentation that tells me that 'arg' is a string is
> > probably enough to set me on the right track. But if the
> > documentation tells me that arg is a thunk/block, that's almost
> > certainly not enough to get me g
[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
>
>
> So while:
> fooble(arg)
> is pretty nasty, documentation that tells me that 'arg' is a string is
> probably enough to set me on the right track. But if the
> documentation tells me that arg is a thunk/block, that's almost
> certainly not enough to get me going. I also need to know how that
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 l
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
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
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 on
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
[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
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 c
On Tue, Apr 19, 2005, Shane Holloway (IEEE) wrote:
>
> I heartily agree! Especially when you have very similar try/finally
> code you use in many places, and wish to refactor it into a common area.
> If this is done, you are forced into a callback form like follows::
>
>
> def withFile(fi
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 open.
On Tuesday 19 Apr 2005 20: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
>
>
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
> > distingu
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 suitabl
*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
Michael Walter <[EMAIL PROTECTED]> wrote:
>
> 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
>
On Apr 19, 2005, at 15:57, BJörn Lindqvist 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? And wouldn't
Well, one
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
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 fun
I apologize for sparking such debate on this list instead of on
c.l.py. By the way, the only reason I brought this up was as a
replacement for lambdas in Py3K.
Guido, in response to your much earlier comment about supporting "{}"
for normal defs as a matter of consistency within my proposal, yes,
At 01:00 PM 04/19/2005 -0700, Guido van Rossum wrote:
> Interestingly, this syntax also works to do decoration, though it's not a
> syntax that was ever proposed for that. e.g.:
>
> foo = classmethod(foo) where:
> def foo(cls,x,y,z):
> # etc.
This requires you to write foo three time
> 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
[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
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:
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 poss
Guido van Rossum wrote:
But what exactly are you trying to accomplish here? I think that
putting the defs *before* the call (and giving the anonymous blocks
temporary local names) actually makes the code clearer:
I'm afraid that 'block1', 'block2', and 'doFoo' aren't really making
anything clear f
> 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 b
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
> @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".
> > IMO this is clearer, and even shorter!
> But it clutters the namespace with objects you don't need.
Why do people care about cluttering namespaces so much? I thought
thats' what namespaces were for -- to put stuff you want to remember
for a bit. A function's local namespace in particular seems
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 =
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
>
> bl
From: Guido van Rossum <[EMAIL PROTECTED]>
...
This reflects a style pattern that I've come to appreciate more
recently: when breaking a call with a long argument list to fit on
your screen, instead of trying to find the optimal break points in the
argument list, take one or two of the longest arg
> What was your opinion on "where" as a lambda replacement? i.e.
>
> foo = bar(callback1, callback2) where:
> def callback1(x):
> print "hello, "
> def callback2(x):
> print "world!"
I don't recall seeing this proposed, but I might have -- I thought of
pretty much exa
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
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 *
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 abo
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 =
> 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
>
> Y
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
> (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 gi
(I apologize that this is my first post. Please don't flame me into
oblivion or think I'm a quack!)
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
91 matches
Mail list logo