On Sun, Oct 13, 2013 at 10:05 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > And for the record, it's not *my* objection; several other core > developers have said -1 too: Ezio, Serhiy, Giampaolo, etc.
FWIW, I'm -1 also; the thread quickly convinced me that this is a horrible idea, at least with the current name. The feature itself I consider +0, maybe +0.5 if a good but short name can be found. I kind of like "abort_on()" as an accurate description of what it actually does, but it most certainly does not *ignore* exceptions, and it's going to create problems as soon as anybody adds more than one statement to the block, and then reads their code back without *really* thinking about it. Not to mention how it's going to bite people who copy and modify code snippets containing it. On Sun, Oct 13, 2013 at 11:11 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > It's just as broken as the try/except equivalent. I consider that a > feature, not a bug. (Note: the following rant is about the *name*, not the context manager itself.) Misleadingness and lack of readability is not a feature, it's a bug. For example, even though I've been coding in Python since 1997, and even participated in the original design process for "with", I *still* misread the "with ignore:" block as ignoring the exceptions until I *really* thought about it. Wait, no, I misread it *entirely*, until somebody *else* pointed it out. ;-) And this is *despite* knowing on a gut level that *actually* ignoring all the errors in a block *isn't possible in Python*. I would not give most people much chance of noticing they made this mistake, and even less chance of finding the problem afterwards. This is like the infamous Stroop test, where you have a word like "brown" only it's printed in blue ink and you have to say "blue" to get the answer right. If you've never taken a Stroop test, by the way, it's *really* hard. It almost literally makes your brain *hurt* to disregard the text and say the ink color instead, because your brain automatically reads the word before you can stop it, so you are straining to stop yourself from saying it so you can then try to *think* what color you're supposed to say, and then your brain reads the word *again*, and... well, it's really quite unpleasant is what it is. Anyway, this feature, with its current name, is just the same: you have to override your instinctive response to understand what it *really* does, in any but the one-liner case. And you have to do it *every time you read it in code*. Only, because it'll mostly be used in the one-line case, you'll get used to it being correct, until one day you make a change without thinking, and create a bug that lies dormant for an extended period. Plus, as soon as people see it being used, they'll think, "oh cool", and use it in their code, not even knowing or thinking that it does something they don't want, because they will never read the docs in the first place. (As Guido says, people learn languages by example.) So call it "catching". Call it "catch_and_exit_on". Even "passing" or "skipping" would be better. And maybe "abort_on" or "abort_without_raising" would be better still, as they describe what will *really* happen. But calling it "ignore" isn't "fits your brain", it's "abuses your brain in a cruelly misleading manner". _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
