[Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

R. David Murray rdmurray at bitdance.com
Sun Oct 13 19:01:12 CEST 2013


+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 <pje at telecommunity.com> wrote:
> On Sun, Oct 13, 2013 at 10:05 AM, Antoine Pitrou <solipsis at 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 <ncoghlan at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com


More information about the Python-Dev mailing list