+1 to the below. I don't have a strong opinion about the feature itself. The number of times I can imagine using it in code is pretty close to zero, but might not actually turn out to *be* zero, you never know.
But the name hurts my brain for the reasons PJ explains :) --David PS: I think you are overreacting, Nick. After all, you did yourself once argue Guido into submission.... :) On Sun, 13 Oct 2013 12:00:25 -0400, PJ Eby <p...@telecommunity.com> wrote: > 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/rdmurray%40bitdance.com _______________________________________________ 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
