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

PJ Eby pje at telecommunity.com
Sun Oct 13 18:00:25 CEST 2013

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".

More information about the Python-Dev mailing list