Named code blockes
Miki Tebeka
Preobebly missed it somewhere.
Is there a discussion/sugesstion about enabling named code blockes (like
lisp, perl ...) in Python?
Thanks.
Bye.
----------------------------------------------------------------------------
--
Smile, damn it, smile.
lambda msg:
'name' : 'Miki Tebeka',
'email' : 'teb...@lycosmail.com',
'homepage' : 'www.tebeka.freeservers.com',
'quote' : "I don't suffer from insanity, I enjoy every minute of it."
}[msg]
Aahz Maruch
Miki Tebeka <teb...@lycosmail.com> wrote:
>
>Is there a discussion/sugesstion about enabling named code blockes (like
>lisp, perl ...) in Python?
What's a named code block?
--
--- Aahz <*> (Copyright 2001 by aa...@pobox.com)
Androgynous poly kinky vanilla queer het Pythonista http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6
Why is this newsgroup different from all other newsgroups?
Fredrik Lundh
> >Is there a discussion/sugesstion about enabling named code blockes (like
> >lisp, perl ...) in Python?
>
> What's a named code block?
anonymous statement suites, not just anonymous expressions
like today's lambdas.
(imo, nested scopes are pretty useless without real blocks)
Cheers /F
Aahz Maruch
Fredrik Lundh <fre...@effbot.org> wrote:
>Aahz Maruch wrote:
>> attribution lost:
>>>
>>>Is there a discussion/sugesstion about enabling named code blockes (like
>>>lisp, perl ...) in Python?
>>
>> What's a named code block?
>
>anonymous statement suites, not just anonymous expressions
>like today's lambdas.
Um, so that's actually an *un*named code block, right?
Alex Martelli
news:FVnB6.6958$4N4.1...@newsc.telia.net...
> Aahz Maruch wrote:
> > >Is there a discussion/sugesstion about enabling named code blockes
(like
> > >lisp, perl ...) in Python?
> >
> > What's a named code block?
>
> anonymous statement suites, not just anonymous expressions
> like today's lambdas.
Ah, UN-named code blocks, then, right?
Is it so 'costly' to give these statement suites a name? I
generally find that turning a lambda into a (named) local
function makes my code clearer in all but the most trivial
cases -- if that applies to expressions, it should a fortiori
apply to suites.
> (imo, nested scopes are pretty useless without real blocks)
I'm not so hot about nested scopes, but, anyway, we DO have
'real' blocks -- surely, giving them a name doesn't take
their reality away, does it?-)
Alex
Miki Tebeka
Obviously I wasn't clear. :-(
The problem I want to address is that continue and break always refer to the
innermost loop they're in. However, it may be desirable to name the loop and
then continue/break explictly this loop. (A know bug is that sometime a new
loop is added in the middle and then the break statement breaks the new loop
and not the old one).
I'd like to see something like (I'm sure you find a nicer syntax than this,
and a better example :-):
import re
def process_file():
lines = []
while1: # name code block
while (1):
for line in open('somefile').readlines():
if (re.match('EOF', line): # end of file marker, don't continue
break while1 # break outer while loop
lines.append(line)
return filter(lambda x: re.match('>', line)
Alex Martelli
news:9b95ib$s...@news.or.intel.com...
> Hello All,
>
> Obviously I wasn't clear. :-(
>
> The problem I want to address is that continue and break always refer to
the
> innermost loop they're in. However, it may be desirable to name the loop
and
> then continue/break explictly this loop. (A know bug is that sometime a
new
Yes. Java does that, as did, if I recall correctly, old PL/I. I agree with
you
that it's a good feature to have (although calling it "named code blocks"
may be incorrect, and your specific example is pretty mysterious to me --
the purpose of the outer 'while1' escapes me). Actually, named-continue
I see as definitely dispensable, but named-break would be useful.
In Python, you can code around this problem in various ways (besides
the classic ideas based on using state-flags to let the inner loop tell the
outer one it must terminate). try/except is a very powerful building
block for all sorts of "get out of this nested construct" call, for example;
it also works across function calls, even recursive ones (its very power
and generality can make it less immediately clear than a more local
named-break would be, of course).
Alex
Miki Tebeka
Obviously I wasn't clear. :-(
The problem I want to address is that continue and break always refer to the
innermost loop they're in. However, it may be desirable to name the loop and
then continue/break explictly this loop. (A know bug is that sometime a new
loop is added in the middle and then the break statement breaks the new loop
and not the old one).
I'd like to see something like (I'm sure you find a nicer syntax than this,
and a better example :-):
import re
def process_file():
lines = []
while1: # name code block
while (1):
for line in open('somefile').readlines():
if (re.match('EOF', line): # end of file marker, don't continue
break while1 # break outer while loop
lines.append(line)
return filter(lambda x: re.match('>', line)
Miki Tebeka
>...
> and your specific example is pretty mysterious to me --
> the purpose of the outer 'while1' escapes me
Just for the sake of example, didn't find anything smarter.
> Actually, named-continue I see as definitely dispensable
> , but named-break would be useful.
Why? As I see it, if you want named break you'll want named continue.
> In Python, you can code around this problem in various ways (besides
> the classic ideas based on using state-flags to let the inner loop tell
the
> outer one it must terminate). try/except is a very powerful building
> block for all sorts of "get out of this nested construct" call, for
example;
> it also works across function calls, even recursive ones (its very power
> and generality can make it less immediately clear than a more local
> named-break would be, of course).
If these are code-around then we agree that there is a problem there.
I agree with these technique, however try/except have a relatively high
performance impact comparing to a simple implementation of named-break which
will be a goto in c.
Aahz Maruch
Miki Tebeka <teb...@lycosmail.com> wrote:
>
>If these are code-around then we agree that there is a problem there.
>I agree with these technique, however try/except have a relatively high
>performance impact comparing to a simple implementation of named-break
>which will be a goto in c.
I can almost guarantee that if there is ever an implementation of named
code blocks, it will be done with exceptions. After all, the Python for
loop uses exceptions (IndexError).
Steven D. Majewski
On Sat, 14 Apr 2001, Miki Tebeka wrote:
>Alex:
> > In Python, you can code around this problem in various ways (besides
> > the classic ideas based on using state-flags to let the inner loop tell
> the
> > outer one it must terminate). try/except is a very powerful building
> > block for all sorts of "get out of this nested construct" call, for
> example;
> > it also works across function calls, even recursive ones (its very power
> > and generality can make it less immediately clear than a more local
> > named-break would be, of course).
> If these are code-around then we agree that there is a problem there.
> I agree with these technique, however try/except have a relatively high
> performance impact comparing to a simple implementation of named-break which
> will be a goto in c.
Most of the impact is when you take the exception, and usually,
leaving the loop IS the exceptional condition.
In fact, setting up the exception is exactly the same code as
setting up a loop:
case SETUP_LOOP:
case SETUP_EXCEPT:
case SETUP_FINALLY:
PyFrame_BlockSetup(f, opcode, INSTR_OFFSET() + oparg,
STACK_LEVEL());
continue;
I wouldn't call it a code-around though -- that just one of the
typical things exceptions were designed for in a structured goto-less
language. In a more optimized compiled language, there's no reason
reason that a local exception can't be compiled into the machine
language equivalent of a goto, just like while loops are.
Python's compiler doesn't do much optimization, and it's dynamic
types for everything including exceptions would make it take a bit
more effort than for a statically typed language.
-- Steve Majewski
Alex Martelli
news:mailman.987267203...@python.org...
>
>
> On Sat, 14 Apr 2001, Miki Tebeka wrote:
>
> >Alex:
> > > In Python, you can code around this problem in various ways (besides
> I wouldn't call it a code-around though -- that just one of the
I would. If one can break out of one level of loop with the break
statement, why would exceptions be the 'designed' way to break
out of two or three levels? It's not that rare a need. It's not an
issue of optimization for me, but of clear and explicit expression
of design intent.
Alex
Alex Martelli
[snip]
> > Actually, named-continue I see as definitely dispensable
> > , but named-break would be useful.
> Why? As I see it, if you want named break you'll want named continue.
As I see it, a 'named break' does ONE thing (break out of N
levels of loops) while a 'named continue' does TWO -- break
out of N-1 levels of loops AND go to the next iteration of the
loop N levels out. I see no need for one statement that does
two things. Actually, 'continue' itself is something I use very
rarely. 'break' is crucial -- the Python way to express a Knuth
"N times and 1/2" loop -- 'continue' is not. Much less a named
kind.
> > In Python, you can code around this problem in various ways (besides
[snip]
> If these are code-around then we agree that there is a problem there.
We do (specifically, that a named-break would be an enhancement
to Python, letting an important design idea be expressed directly
and explicitly), but not on the reasons.
> I agree with these technique, however try/except have a relatively high
> performance impact comparing to a simple implementation of named-break
which
> will be a goto in c.
Performance issues are trivial here. Any Python 'for' statement is
terminated by an exception -- that IS its defined semantics (it
goes on iterating until the sequence object it iterates on raises
an IndexError!). And yet, it's often faster than the equivalent
'while'; even if it isn't, if you care for micro-optimizations to this
obsessive level, then Python is the wrong language for that part
of your code. So, how bad can it possibly be, for performance,
if the way to terminate N nested loops is by 1 exception?!
That's not the point. The point is clarity and simplicity. Being
able to say what you mean, rather than 'code around it'.
Say I have a list of lists of lists and need to check if any of
the atomic items satisfies a condition. As a function it's easy:
def threeLevelNestedCheck(list_of_lists_of_lists, condition):
for list_of_lists in list_of_lists_of_lists:
for list in list_of_lists:
for item in list:
if condition(item): return 1
return 0
because the 'return' breaks out of as many nested loops as
needed. But coding it inline becomes:
try:
for list_of_lists in list_of_lists_of_lists:
for list in list_of_lists:
for item in list:
if condition(item): raise None
except None:
found_it = 1
else:
found_it = 0
and that is NOT as clear, direct, explicit and immediate (in
fact, it would no doubt be advisable to move this to a local
function, just for clarity -- to be able to use 'return' as a
break from multiple nested loops!).
Performance is not all that different in the two cases, I
think (I should check, but I feel lazy right now). Clarity
and simplicity is the name of the game (well, the TWO
names -- clarity, simplicity, and explicitness... wait...).
Alex
Steven D. Majewski
On Sat, 14 Apr 2001, Alex Martelli wrote:
> I would. If one can break out of one level of loop with the break
> statement, why would exceptions be the 'designed' way to break
> out of two or three levels? It's not that rare a need. It's not an
> issue of optimization for me, but of clear and explicit expression
> of design intent.
I agree it's an issue of clear and explicit expression.
We just have a difference of opinion over whether labeled blocks
and multiple level breaks deliver on that clear and explicit expression.
I would actually find GOTO's *MORE* clear and explicit provided
everyone had the discipline to use them in a restricted and structured
manner. (ala. Knuth, Structured Programming with Goto)
Typically, a named block has the name label at the top -- which is
not usually where the control is flowing to, and you have to hunt
and peek around to find the next executable statement. What's clear
and explicit about that ?
A restricted use of GOTO is more (IMHO) clear.
try/except blocks come in somewhere in between Goto and named
blocks for readability. Not a bad compromise if you don't want
to rely on disciplined use of goto. The target is pretty clear.
( But maybe you're thinking of a different syntax for Python
than I can imagine from other lang. I've seen. If you show
me a clear example, I'll reconsider. )
-- Steve Majewski
Carlos Ribeiro
>( But maybe you're thinking of a different syntax for Python
> than I can imagine from other lang. I've seen. If you show
> me a clear example, I'll reconsider. )
I've came up with a example. The actual code does nothing useful (it's
non-sense :-), but it serves to show one possible syntax:
for i in list1 as Loop1:
for j in list2 as Loop2:
if j in list1:
continue Loop1
for k[j] in list3 as Loop3:
if k[j] in list1:
break Loop1
The label is specified by the "as label" construct right after the loop
statement. Both break and continue could take an optional parameter to
specify the loop to which they do refer.
The word "as" is already used in the import statement. In this case, it
would specify a label for the break and continue statements. "as" doest not
need to me made a reserved word, because it can appear only in a well
defined context. Optionally, the word "label" could also be used:
for i in list1 label Loop1:
(...)
Two things called my attention while writing the simple example above:
- *In my example*, the "continue Loop1" statement will have exactly the
same effect as a "break" statement. In fact, in many cases the effect will
be the same. If you don't have any extra logic after the inner loop, both
"break" and "continue label" will be equivalent.
- There are some similarities between these labeled break/continue
constructs and continuations. One possible implementation for this kind of
construct would be the use of one type continuations. The Stackless people
could clarify this a little bit better for me.
Carlos Ribeiro
Alex Martelli
> Typically, a named block has the name label at the top -- which is
> not usually where the control is flowing to, and you have to hunt
Right: it's where the control is _breaking away from_ (for a break;
it IS, in fact, "where it's flowing to" for a continue). Note that this
is even more obvious for the make-it-a-function alternative: return
clearly shows what (function) you are EXITING from, but NEVER
'where the control is flowing to' -- it flows to wherever it needs to,
that's not the point -- the point is terminating a conceptual unit
(and a named loop is as much as a conceptual unit as a function:
if it's code needs to occur exactly once, having it lexically inline
at the single point of occurrence is a plus!).
> and peek around to find the next executable statement. What's clear
> and explicit about that ?
A good part is in the name.
break eggs_search
You don't need context to see that this is terminating the 'search
for eggs' named conceptual unit. "what happens next" ("where
the control is flowing to") is obviously "whatever's next after
searching for eggs", just as if this was a function named that way
with a return statement here == indeed, the lexical situation in
terms of "let me look for where this goes now" is easier than for
function calls, where it's generally anything but clear at a first
glance that a certain function is called from just one place, and
where that place is.
> A restricted use of GOTO is more (IMHO) clear.
MHO differs. I don't want to think of this-then-that-then-the-
other control flow in a VHLL, I want to think of named building
blocks and their nesting and entering and exiting.
> try/except blocks come in somewhere in between Goto and named
> blocks for readability. Not a bad compromise if you don't want
> to rely on disciplined use of goto. The target is pretty clear.
It's lexically constrained, but lacks a name, which is a strong
conceptual help (the name of the exception you raise can help,
but that should be the reason for exiting, not WHAT you are
exiting).
> ( But maybe you're thinking of a different syntax for Python
> than I can imagine from other lang. I've seen. If you show
> me a clear example, I'll reconsider. )
Nope, I had in mind the same kind of syntax seen in other
languages, sugary issues apart (it's minor from my POV whether
naming a loop involves using 'as', a colon, or whatever) -- being
able to name a block and to mention that name in a break.
Alex
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com