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

[Eric Snow]

On Oct 16, 2013 5:35 AM, "Victor Stinner" <victor.stinner at gmail.com> wrote:
>
> 2013/10/16 Raymond Hettinger <raymond.hettinger at gmail.com>:
> > FWIW, here's a little history:
>
> Thank you! It helped me to understand the story.
>
> > * In February, I presented ignore() in the keynote for the U.S. Pycon.
> >   Again, the feedback was positive.
>
> I missed this edition of Pycon US. How did you feedback on the keynote?
>
> > To each participant, it may not seem like bike-shedding, but there
> > were almost a hundred emails in this thread just to kick around six
lines
> > of code that were checked-in seven months ago:
>
> Sorry but you cannot summarize this thread to this only point (the
> name). Many other topics were discussed:
>
> * process: most votes were negative on the tracker, Nick didn't
> mention that he blesssed this function
> * surprising behaviour when the block contains more than 1 instruction
> * documentation issue
> * should we add new functions in Python just to remove 2 lines of code?
> * possibility of storing the catched exception
> * etc.
>
> If you disagree with the principle of discussing new features, you
> missed probably an important part of the Python community. The process
> is not perfect, don't hesisate to suggest enhancement :-)
>
> The discussion only started recently (after the function was added)
> because it started on python-dev which is more visible than the bug
> tracker.
>
> --
>
> Antoine also asked me recently to revert a commit (new malloc API)
> because it was not discussed enough (so you are not the only one to be
> harassed by Antoine :-)). I tried to describe my choices on
> python-dev, but it was hard to follow the flow of emails, so I wrote a
> PEP (PEP 445). The PEP was quickly accepted, the code is back, BUT the
> API is now *much* better, and the PEP is a good documentation
> explaining all technicals choices. (There were many alternatives to
> the proposed API, the PEP now lists all of them.) I can now say that
> my first API was no well designed, and the PEP helped me to improve
> it.
>
> It is frustrating to have to revert a commit, it should not happen. My
> patch was available since many weeks (months), but Antoine was right:
> it was not discussed enough. I don't know yet how to get more review
> on the bug tracker, sometimes even emails to python-dev are not
> enough. It depends on the motivation and availability of each
> developer :-)

You make several good points, Victor.  However, in this case the change is
a new function and a small, innocuous one at that.  That is not enough
justification alone, as Antoine pointed out, but the module's maintainer
made a decision on this.

When a module's maintainer makes a decision on a relatively insignificant
addition to the module, I'd expect little resistance or even comment (the
original commit was months ago).  That's why I'm surprised by the reaction
to this change.  It just seems like the whole thing is being blown way out
of proportion to the detriment of other interesting problems. Sure, things
could have been done differently.  But in this case it's not that big a
deal.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131016/0d56a0e8/attachment.html>