Josiah Carlson wrote:
> I wasn't expressing my opinion, I was attempting to express as to where
> the discussion went and concluded. I honestly can't remember having an
> opinion on the subject, but I seem to have convinced Nick earlier that
> they shouldn't loop, and he (re-)convinced me that indeed, they
> shouldn't loop.
So you can be re-re-convinced if more use cases are found? ;-)
>>It needs some polish I think. ;-)
>
>
> Goodness, the horror! When implementation details start bleeding their
> way into actual language constructs (using a continue/break stack in
> order to control the flow of nested loops), that's a good clue that an
> idea has gone a bit too far.
>
> I would honestly prefer gotos, and I would prefer having no change to
> existing syntax to gaining gotos.
Well I happen to like stacks for somethings. They can be very useful and
efficient. But I agree that they have been horrible abused in all sorts
of ways. But that doesn't make them bad. In this case I think they
work well, but the implementation ccould be improved.
I see a correlation between breaks, continues, and exceptions. So it
makes since to me that they could use similar mechanisms to catch and
reraise them as needed.
But this seems awkward and it's even *uglier*!
try:
# some code in a loop.
except BreakException, Breakme:
pass
then later....
raise Breakme # breaks a loop now instead of then.
But these examples sort of point out an underlying concept in these
discussions. That it is useful to be able to postpone or delay code to
be executed at a later time. Thus the idioms, before-after, enter-exit,
and init-finalize. And here again, with try-finally, and breaks/continues.
_Ron
> It's kind of funny. Every month I spend in python-dev, I feel less
> inclined to want to change the Python language (except for the relative
> import I need to finish implementing). Not because it is a pain in the
> tookus (though it is), but because many times it is my immediate sense
> of aesthetics that causes me to desire change, and my future of code
> maintenance makes me think forward to understanding Python 2.3 in the
> context of Python 2.9 .
Changing it just for the sake of newness or "it's cool" or whatever
isn't good of course. But extending a language vs changing the way it
works, is worth while as long as it's done in a careful and consistent
manner. That's sort of why I'm against changing 'for', and for adding
the new loop/block. I see it as a loop with a higher level of
abstraction. A new tool to be used in new ways, but I want to keep my
old dependable tools too.
_Ron
The simplest computer language in the world is called MAIN, has only one
function called main(), which evaluates any arbitrary set of arguments
you give it. Programming is now an obsolete profession!
However we are now in desperate need of experts who can understand
exceedingly long arbitrary sets of arguments and what they will do when
they are evaluated by MAIN's main() function.
;-)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
