RetroSearch Browse

Sat Apr 14 14:55:14 EDT 2001 · http://mail.python.org/pipermail/python-list/2001-April/091129.html

"Miki Tebeka" <tebeka at lycosmail.com> wrote in message
news:9b9pge$a10 at news.or.intel.com...
    [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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-list/2001-April/091129.html below:

Named code blockes