Re: [Python-Dev] anonymous blocks

2005-05-04 Thread Fredrik Lundh
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 ;-) _

Re: [Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-29 Thread Simon Percivall
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

Re: [Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-29 Thread Jim Jewett
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

[Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-29 Thread Jim Jewett
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

Re: [Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-29 Thread Brian Sabbey
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

Re: [Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-29 Thread Guido van Rossum
[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

[Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-29 Thread Jim Jewett
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

Re: [Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-29 Thread Aahz
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

Re: [Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-29 Thread Michael Hudson
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

Re: [Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-29 Thread Michael Hudson
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

RE: [Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-29 Thread Robert Brewer
> [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

Re: [Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-28 Thread Guido van Rossum
(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

Re: [Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-28 Thread Brian Sabbey
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

Re: [Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-28 Thread Greg Ewing
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

Re: [Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-28 Thread Guido van Rossum
[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

Re: [Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-28 Thread Michael Hudson
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

[Python-Dev] anonymous blocks as scope-collapse: detailed proposal

2005-04-28 Thread Jim Jewett
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

Re: [Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-28 Thread Jim Fulton
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

[Python-Dev] Anonymous blocks: Thunks or iterators?

2005-04-28 Thread 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. I'd like to reconsider a thunk implementation. It would be a lot s

Re: [Python-Dev] anonymous blocks

2005-04-23 Thread Timothy Fitz
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

Re: [Python-Dev] anonymous blocks

2005-04-23 Thread Shane Hathaway
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

Re: [Python-Dev] anonymous blocks

2005-04-23 Thread Nick Coghlan
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:

Re: [Python-Dev] anonymous blocks

2005-04-22 Thread Nick Coghlan
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Greg Ewing
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Greg Ewing
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Greg Ewing
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Greg Ewing
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

Re: [Python-Dev] anonymous blocks (don't combine them with generator finalization)

2005-04-21 Thread Bob Ippolito
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

Re: [Python-Dev] anonymous blocks (don't combine them with generator finalization)

2005-04-21 Thread Brett C.
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Brett 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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Steven Bethard
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Skip Montanaro
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Aahz
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

Re: [Python-Dev] anonymous blocks (don't combine them with generator finalization)

2005-04-21 Thread Bob Ippolito
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

Re: [Python-Dev] anonymous blocks (don't combine them with generator finalization)

2005-04-21 Thread Josiah Carlson
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Samuele Pedroni
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Ka-Ping Yee
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Guido van Rossum
[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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Brett C.
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Guido van Rossum
[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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Ka-Ping Yee
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):

[Python-Dev] anonymous blocks

2005-04-21 Thread Guido van Rossum
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Brian Sabbey
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Steven Bethard
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Guido van Rossum
> 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/) _

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Steven Bethard
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Steven Bethard
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Guido van Rossum
> 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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Steven Bethard
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

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Guido van Rossum
[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 > >

Re: [Python-Dev] anonymous blocks

2005-04-21 Thread Guido van Rossum
> 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

Re: [Python-Dev] anonymous blocks

2005-04-20 Thread Steven Bethard
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

Re: [Python-Dev] anonymous blocks

2005-04-20 Thread Greg Ewing
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

Re: [Python-Dev] anonymous blocks

2005-04-20 Thread Greg Ewing
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

Re: [Python-Dev] anonymous blocks

2005-04-20 Thread Greg Ewing
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

Re: [Python-Dev] anonymous blocks

2005-04-20 Thread Greg Ewing
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

Re: [Python-Dev] anonymous blocks

2005-04-20 Thread Guido van Rossum
[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

Re: [Python-Dev] anonymous blocks

2005-04-20 Thread Shane Holloway (IEEE)
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

Re: [Python-Dev] anonymous blocks

2005-04-20 Thread Aahz
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

Re: [Python-Dev] anonymous blocks

2005-04-20 Thread James Y Knight
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.

Re: [Python-Dev] anonymous blocks

2005-04-20 Thread Michael Sparks
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 > >

Re: [Python-Dev] anonymous blocks

2005-04-20 Thread Paul Moore
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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Steven Bethard
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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Shane Holloway (IEEE)
*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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Josiah Carlson
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 >

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Alex Martelli
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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Michael Walter
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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Jack Diederich
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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Shannon -jj Behrens
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,

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Phillip J. Eby
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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread BJörn Lindqvist
> 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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Josiah Carlson
[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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Brian Sabbey
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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Tim Delaney
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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Glyph Lefkowitz
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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Guido van Rossum
> 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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Brian Sabbey
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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Guido van Rossum
> @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".

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Guido van Rossum
> > 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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Eric Nieuwland
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 =

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Barry Warsaw
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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Kevin J. Butler
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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Guido van Rossum
> 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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Brian Sabbey
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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Facundo Batista
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 *

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Phillip J. Eby
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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Phillip J. Eby
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 =

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Guido van Rossum
> 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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Brian Sabbey
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

Re: [Python-Dev] anonymous blocks

2005-04-19 Thread Guido van Rossum
> (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

[Python-Dev] anonymous blocks

2005-04-19 Thread Shannon -jj Behrens
(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