Rob Cliffe writes: > Did you see Guido's post when I raised a similar object to detecting > "zero iterations", where it would be unacceptable to slow down all > for-loops, so they would have to be compiled differently?
Yes. My confusion (as you'll see elsewhere) was about the AST, not the parser. > > Second, generally Python tries to avoid overloading keywords with > > multiple semantics. The potential for confusion and misunderstanding > > of "except" (which I've suggested myself and now dislike) is pretty > > large I think. > IMO this is a bit disingenuous: I'm not trying to mislead anybody, or try to imply there aren't cases where keywords have been repurposed. > "as" can be used with "import" and with context managers with > quite different semantics. I would disagree that the semantics are different. Context managers and imports have quite different semantics, but in both cases the "as" clause has name binding semantics, while the object bound is determined by the statement, not by the "as" clause. > "del" can be used to remove a variable binding, a sequence element, > a sequence slice or a dictionary key. The connection is more tenuous, but in each case an object loses a reference. I see your point of view, especially since the semantics of del on sequence elements and slices affects the "names" of other sequence elements, but I think the "reference destruction" semantics are "sufficiently" similar across the different uses of "del". > "not" can be used as Boolean negation or in the compound operator > "not in". Which is a negation. I don't see how anybody reading that could mistake the meaning. > Whereas the new use of "except" that Matthew is proposing is very > similar to its existing use (certainly conceptually, if not in the > implementation details). As a restricted goto, that is true. In fact, it's so similar that we may as well use the original! Is one level of indentation really worth it? What I see as different is that Matthew's proposal is for a purpose that is explicitly local to the loop statement, where except is explicitly nonlocal. Another way to put it is in this thread "except" is proposed as marking a goto target, where in a try "except" is almost a "come from" (although not with full INTERCAL compatility). I also wonder about try ... excepts nested in a for loop with excepts. That's probably no harder to deal with than nested loops with breaks at different levels (but that can be a bit confusing). > (To be clear: although I'm defending Matthew's proposal here, my > preferred option is still some new syntax.) "try" is enough to implement any of the use cases in the relatively rare cases it's needed. On the plus side, a "try" and its except clauses require a bit of code to set up. I don't know whether that's a major consideration, but one advantage of a new implementation for the purpose of implementing "labelled breaks" would be to have a lighter implementation. Whether it's worth it is above my pay grade. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DC77MEHTY4NMLUSIRS7JFKQA4FF6UNHX/ Code of Conduct: http://python.org/psf/codeofconduct/
